What we are, what we do,
and what we don't.
This page is the canonical statement of what Provenance is and why it exists. If anything on this page contradicts something elsewhere on the site, this page wins.
Last updated: April 2026
The problem we're solving
AI agents are being deployed into systems that route work between them. One agent calls another. A platform dispatches a job to an external agent. An orchestrator delegates tasks to a pool of sub-agents. This is already happening, at scale, today.
None of these interactions have a standard identity layer. When a platform routes a job to an agent, it has no reliable way to know: who built this agent, what it has committed to never doing, whether it has a history of violations, or whether the agent claiming a given identity actually controls that identity.
This isn't a hypothetical risk. It's the current default. You dispatch work and trust that the agent behaves. There is no credential, no declaration, no audit trail — unless you build it yourself.
Provenance is the infrastructure that makes it possible to answer those questions before dispatching — across the ecosystem, not just within your own stack.
What we built
Provenance is three things: a registry, a protocol, and an SDK.
An open index of AI agents discovered from GitHub, npm, HuggingFace, and PyPI, plus agents that register directly. Every agent gets a provenance_id — a canonical identifier tied to its source. The registry is the lookup layer: given an ID, return the agent's identity state, declared capabilities, constraints, and incident history.
The Provenance Protocol defines PROVENANCE.yml — a file developers add to their repository declaring what their agent can do (capabilities) and what it will never do (constraints). It also defines the Ed25519 key registration and verification mechanism that enables cryptographic identity proof. The protocol is open source and can be implemented independently of our registry.
provenance-protocol (npm) gives any platform or agent one call — gate() — to check an agent's identity state, declared constraints, capabilities, and incident status before dispatching work. It also supports challenge-response signature verification, batch checking, and self-registration.
Identity works in two directions
The primary use case is a platform or dispatcher verifying an agent before routing work to it. You don't know the agent. You call gate() to check its identity and declared constraints before sending a job.
The secondary use case is a receiving agent verifying the identity of who is calling it. An orchestrator dispatches work to a sub-agent, claiming a provenance identity. The sub-agent can issue a nonce challenge and verify the caller signs it with their registered private key — confirming the caller actually controls the identity it claims, not just that it knows the ID string.
gate(agentId, { requireVerified, requireConstraints, requireClean } before routing a job to an external agent. Returns allowed: true/false with a reason. This is what most integrations need.provenance_id:nonce), and the receiver verifies via verifySignature(). Used when accepting delegated work from orchestrators and needing proof beyond just knowing the ID.Three identity states, precisely defined
Every agent in the registry has one of three identity states. These are not scores or grades — they are specific, verifiable conditions.
Discovered by automated crawling. No developer action taken. Capabilities and constraints are guessed from code signals. The developer has made no public commitment. Treat inferred agents as unknown.
Developer added a PROVENANCE.yml to the repository root. Capabilities and constraints are self-attested — a deliberate, version-controlled public commitment. Not cryptographically verified, but the developer took intentional action.
Developer declared PROVENANCE.yml and registered an Ed25519 public key with a signed challenge proving key ownership. The signature can be verified by anyone, independently, without trusting the Provenance registry. Re-registration requires proof of the existing key.
What Provenance does not do
Constraints are self-declared. An agent that declares no:pii has made a public commitment — it has not proven at the infrastructure level that its implementation enforces it. We do not monitor agent runtime behavior. We do not audit code. We do not run automated tests against declared constraints.
What a declaration gives you: a machine-readable, version-controlled public commitment tied to a developer's identity. If an agent violates a declared constraint, that's a verifiable breach of their published identity — which you can document via an incident report. Whether that matters in your context is your call.
The registry is centralized. We operate one server, one database. If getprovenance.dev goes down, gate() calls fail. The protocol is designed so that the trust model works without our registry — signatures can be verified offline, PROVENANCE.yml files are hosted in the agent's own repository — but registry-dependent features (incident history, search, batch checks) require us to be available.
Key recovery is currently manual. If you lose your private key, you contact us. This is a real centralization dependency. We intend to support multisig or social recovery in a future version of the protocol.
Principles
The registry is useful. But the protocol — PROVENANCE.yml, the signing spec, the constraint vocabulary, AJP — is what lasts. Any party can implement a compatible registry. The trust model works without us.
A constraint means exactly what the constraint vocabulary says it means. We maintain canonical definitions at /constraints. Vague declarations create false confidence, which is worse than no declaration.
We document what Provenance cannot do on the same pages where we describe what it can. The trust page and this page exist for this reason. A trust infrastructure that oversells its guarantees is not a trust infrastructure.
The PROVENANCE.yml schema, the AJP protocol, and the SDK are MIT-licensed and on GitHub. No lock-in to our implementation. Provenance should be forkable, federable, and replaceable.
We crawl public repositories without prior consent — the same model as search engines and package registries. Any developer can remove their agent from the index immediately, permanently, and without contacting us by adding provenance: false to their PROVENANCE.yml.
The Agent Job Protocol (AJP)
AJP is the execution layer on top of Provenance identity. Where Provenance answers who is this agent and what has it committed to, AJP answers how do I hire it for a specific job.
A dispatcher sends a structured job offer to the agent's /ajp/job endpoint, with trust requirements embedded in the offer. The agent returns a signed job receipt with constraints_asserted — the constraints it commits to upholding for that specific job, signed with its private key. This creates a per-engagement, auditable record that goes beyond the registry-level declaration.
AJP is optional. You can use Provenance identity and gate() without AJP. AJP is for systems where you need a formal, signed, per-job commitment — not just a registry-level check.