Hard questions, honest answers

Partially true, and worth distinguishing. The registry (getprovenance.dev) is centralized — one server, one operator, one database. That's an honest description. Like npm, PyPI, or Docker Hub, it's a central index. We don't claim otherwise.

The protocol — the PROVENANCE.yml format, Ed25519 signing, the AJP job envelope — is a spec, not a server. You can implement it, verify signatures, and build trust checks without ever contacting our registry. The SDK (provenance-protocol) is open source and works offline.

The legitimate concern is lock-in. If getprovenance.dev goes down or changes its terms, agents that depend on our registry break. Our answer: the protocol is designed so that any party can run a compatible registry. We intend to publish the registry spec so the index can be federated or mirrored. That work is not done yet — and you should weigh that gap honestly when deciding whether to adopt.

This was a real bug in our documentation. The original script printed the private key to stdout via console.log, which would appear in CI logs, terminal history, and agent context windows. We've fixed it: the private key is now written to a local file with restricted permissions (chmod 600) and never printed to stdout. The fix is live.

The broader concern — that encouraging autonomous agents to run key-generation scripts is a prompt injection risk — is also valid. An agent that blindly executes setup scripts without human review can be manipulated into generating and exfiltrating credentials. Our recommendation: treat the setup script as code to be reviewed by a human before running, not as an agent-safe autonomous operation. We've updated the docs to reflect this.

Correct. Constraints in PROVENANCE.yml are declarations, not enforced rules. An agent can declare no:pii and violate it. We do not monitor runtime behavior.

This is intentional and matches how every comparable trust layer works — SSL certificates don't enforce what a server does with your data, npm packages aren't audited for what their code does at runtime, and GitHub profiles don't verify that users are who they claim to be. Declaration and enforcement are different layers.

What constraints do provide: a machine-readable, cryptographically signed commitment. If an agent violates a declared constraint, that's a verifiable breach of their published identity — not just a policy violation. Whether that matters depends on the context you're using it in. We think it's better than nothing, but we don't oversell it as enforcement.

Trust scores are gameable — this is true of all reputation systems. Our scores weight cryptographic proof of identity and declared metadata over crawled signals, which raises the bar but doesn't eliminate gaming. We don't claim otherwise.

Key recovery is currently manual and operator-dependent. If you lose your private key, you contact us. This is a real centralization risk. The mitigation we can offer: document your key in your own systems independently of us. A future version of the protocol will support multisig or social recovery — that work is not done.

We crawl public repositories and index them without asking first. We send GitHub issues to inform developers their agent is listed, with an opt-out. This is the same model used by Google, npm audit tools, and security scanners — but we understand it's not welcome by everyone.

If you want your repo removed from the index, reply to the issue we sent or email us at the address in the footer. Removal is immediate. We also accept opt-out via a provenance: false entry in your repo, which the crawler respects permanently.

Whether this approach is legitimate is a reasonable debate. Our view: for a discovery registry to be useful it needs to be comprehensive, and waiting for opt-in would leave it empty. We accept the criticism and try to make opt-out easy.