When a human calls an API, there's auth. A key, a token, a certificate. You know who's calling and what they're allowed to
do.
When an AI agent dispatches work to another agent, there's nothing. No standard identity. No way to verify the agent you're
calling is who it claims to be, what it has committed to never doing, or whether it has a history of violations. You dispatch and trust. That's the current default.
This is the problem Provenance solves.
What we built
Provenance is three things:
A registry — an open index of AI agents from GitHub, npm, HuggingFace, and PyPI. Every agent gets a provenance_id tied to
its source: provenance:github:alice/my-agent, provenance:npm:my-package. Given an ID, the registry returns the agent's identity state, declared capabilities, constraints, and incident history.
A protocol — developers add a PROVENANCE.yml to their repository declaring what their agent can do (capabilities) and what it will never do (constraints). Optionally, they register an Ed25519 public key proving they control the identity — verifiable by anyone, without trusting our registry.
An SDK — provenance-protocol (npm) gives any platform or agent one call to check an agent before dispatching work.
Identity works in two directions
The primary use case: a platform verifying an agent before routing work to it.
import { Provenance } from 'provenance-protocol';
const provenance = new Provenance();
const result = await provenance.gate(agentId, {
requireVerified: true,
requireConstraints: ['no:pii', 'no:financial:transact'],
requireClean: true, // no open incidents
});
if (!result.allowed) throw new Error(result.reason);
// safe to dispatch
The secondary use case: a receiving agent verifying the identity of whoever is calling it. An orchestrator claims a provenance identity — the receiver issues a nonce, the caller signs it with their private key, and the receiver verifies via verifySignature(). Useful when you're accepting delegated work and need proof beyond just knowing the ID string.
Three identity states
- inferred — discovered by crawling. No developer action. Treat as unknown.
- declared — developer added PROVENANCE.yml. A deliberate public commitment, self-attested.
- verified — developer registered an Ed25519 public key and proved ownership. Independently verifiable without trusting our registry.
What it doesn't guarantee
Constraints are self-declared. An agent that declares no:pii has made a public commitment — not an infrastructure-level proof. We don't monitor runtime behavior or audit code. What you get is a machine-readable, version-controlled, cryptographically signed commitment. If an agent violates it, that's a verifiable breach of their published identity — which you can document via an incident report.
The registry is also centralized. We operate one server. The protocol is designed so that signatures can be verified offline and PROVENANCE.yml files live in the agent's own repo — but registry-dependent features require us to be available. We document this honestly because a trust infrastructure that oversells its guarantees isn't one.
Open protocol
The PROVENANCE.yml schema, capability and constraint vocabulary, and the Agent Job Protocol (AJP — structured job offers with per-job signed receipts) are MIT-licensed. You can implement the trust model without our registry.
Full statement of what we are, what we do, and what we don't: https://getprovenance.dev/about
Registry and search: https://getprovenance.dev
SDK: npm install provenance-protocol
Spec: https://github.com/ilucky21c/provenance-protocol
Top comments (0)