The Agent Passport

When an AI agent does something on your behalf — books a hotel room, files a claim, sends an email to a customer, moves money between accounts — there is no document that travels with it describing what it is.

The agent has an identity inside whatever system it's acting in. It probably has credentials at runtime. Somewhere, in some operator's database, there is a row that describes it. But there is no signed, portable, verifiable record of what this agent is — what model it runs on, what tools it can use, what it's authorized to do, who configured it, who's responsible for it — that can be examined later, shared with a counterparty, or reviewed by an auditor. The agent acts, the action is recorded somewhere, and the question of what kind of thing performed the action gets answered in whatever ad-hoc way the situation demands.

This is unusual. Most consequential things that move through the world carry verifiable records of what they are. Pharmaceuticals carry track-and-trace data under regulations like the US Drug Supply Chain Security Act. Manufactured goods in the EU are being issued Digital Product Passports for clothes, batteries, electronics, and a growing list of categories. Software that runs in serious environments is increasingly required to ship with a Software Bill of Materials. We have decades of accumulated practice building provenance systems for non-human things. We've solved this problem three times in three industries. AI agents are the fourth instance, and the fourth instance is currently being treated as a new problem.

It isn't. Or rather: most of it isn't.

Three precedents

Each of the existing provenance systems was built in response to a specific failure, and each one settled on a similar architectural shape — issue a verifiable record once, attach it to the thing in question, let any downstream party check it without trusting the issuer.

SBOM (Software Bill of Materials) emerged from the realization that software built from hundreds of open-source components is impossible to secure if no one knows what's in it. The Log4Shell vulnerability in 2021 made the case in a way nothing else had — companies could not answer the question "are we using Log4j?" for weeks after the vulnerability was disclosed. The SBOM is the answer to that question, made portable. It lists the components, their versions, their origins. It travels with the software. It gets checked by anyone who needs to know whether a given component is present.

DSCSA (Drug Supply Chain Security Act) is the US response to counterfeit pharmaceuticals. Every prescription drug package now carries a serialized identifier, and as the package moves through the supply chain, each handoff is recorded as a signed transaction. A pharmacist receiving a bottle can verify that it came from the manufacturer through a legitimate distribution path, not from a parallel market with a forged label. The credential is the serial number plus the transaction history; the verifier is the next link in the chain.

DPP (Digital Product Passport) is the EU's emerging requirement for physical goods. A garment, a battery, an appliance — each will eventually carry a digital record describing what it is, where its materials came from, who made it under what conditions, what it contains, how to recycle it. The record is accessible via a scan, verifiable independently of the brand making the claim, and persistent across the product's life. DPP is the most ambitious of the three because it tries to cover the full lifecycle, not just authentication at a single point.

These systems differ in scope, but they share a structural shape: signed credentials, portable records, verification without trusting the issuer. That shape is reusable. It's also, in the verifiable credentials and decentralized identifier standards that DPP is being built on top of, increasingly standardized.

The AI agent provenance problem is the fourth instance of this shape. Most of what an Agent Passport needs to be has already been figured out.

What an Agent Passport needs to contain

Most of it, but not all of it. The fields below are what I'd argue an Agent Passport has to carry to do its job. None of these are exotic; most have direct analogs in one of the three precedent systems.

Identity and lineage. Who built this agent, when, from what base model and version. The agent's name and unique identifier. The model card or equivalent reference for the underlying model. This is the SBOM-equivalent — the list of components, made specific to AI systems.

Configuration. What tools is the agent authorized to use, what data sources can it access, what kinds of actions can it take, in what environments. This is the part that distinguishes an agent from the model it runs on. A model is a capability; an agent is a configured deployment of that capability, and the configuration is most of what determines what the agent can actually do.

Constraints. What is the agent explicitly forbidden from doing. Spending limits, data classes it can't touch, actions it can't take without human approval. This is the inverse of configuration, and it matters separately because in regulated contexts the constraints are often the part that gets audited.

Operator. Who is responsible for this agent. Which legal entity, which named contact, which escalation path when the agent does something wrong. This is the field most easily overlooked in a technical schema and most important in a real-world failure. Every other provenance system has a clear answer to "who do I call when this is wrong"; agent systems mostly don't yet.

Audit posture. What level of logging does this agent produce, what's retained, who has access. This isn't the audit log itself — that's a separate layer. It's the agent's declared logging behavior, so a counterparty can know what evidence will exist if something goes wrong.

Trust signals. Has the agent been evaluated, by whom, against what standards, when. This is the field most under construction. We don't yet have an agreed equivalent to "FDA-approved" or "ISO 27001-certified" for AI agents. We will eventually. The passport needs a place to put those signals when they exist, and to be honest about their absence when they don't.

Six fields. Not exhaustive — a real specification will have more — but these are the minimum a passport needs to carry for the credential to be useful for anything beyond authentication at the moment of action.

Where the AI version has to be different

The precedent systems are useful but incomplete, and three differences in particular make AI agent provenance harder than what came before.

Agents are more mutable than physical goods. A bottle of medication shipped under DSCSA is the same bottle when it reaches the pharmacy. A garment under DPP doesn't change its composition between the factory and the store. An AI agent, by contrast, can be updated continuously — the model can be swapped, the tools can be extended, the permissions can be revised, the prompt can be rewritten. The passport has to be a living document, versioned over time, with each material change re-signed. SBOM has a partial analog here (software gets patched, SBOMs get updated), but AI agent change rates are likely to be substantially higher than software release cycles.

Agents are composable in ways physical goods aren't. A pharmaceutical doesn't call another pharmaceutical mid-treatment. An agent can call another agent. When agent A invokes agent B to complete part of a task, the provenance of the resulting action involves both — A's authorization, B's identity, and the chain of delegation between them. The passport needs to support not just individual agent identity but composed-action identity, which is a problem the existing precedents have barely had to consider.

Trust signals for AI are still being defined. The pharmaceutical industry knows what a Phase III trial is. The software industry knows what a SOC 2 audit is. The AI industry does not yet agree on what "this agent has been evaluated for safety" means, or what "this agent is appropriate for use in regulated contexts" means. The frameworks — NIST AI RMF, the EU AI Act, various internal evaluations — exist, but they aren't yet a shared vocabulary in the way drug approval or security certification are. The passport has to be designed to carry these signals as they emerge, without prematurely committing to which vocabulary wins.

None of these differences invalidate the precedents. They just mean the AI version of the architecture has to be richer in specific places.

Who issues the passport

There's a question that the technical design can't answer, and it will end up mattering more than the schema.

Every provenance system has an issuer the verifier trusts. Pharmaceuticals have the manufacturer plus the regulator. DPP has the producer plus standards bodies like GS1 plus, eventually, EU enforcement. SBOMs are mostly issued by the software vendor, with growing pressure for third-party verification. The issuer question determines the system's politics: who has authority, who bears liability, what happens when the issuer is the same party whose claims are being questioned.

For AI agents, the candidates are:

The model provider could issue passports for agents built on their models. This makes the most sense for the base-model fields but breaks down for the configuration and constraint fields, which the model provider doesn't see.

The agent platform — the system that hosts and runs the agent — could issue, because the platform sees the full configuration. But the platform also has a commercial interest in not surfacing problems with the agents running on it.

The deploying enterprise could issue, because they configured the agent for their use. But then the passport is a self-attestation, which limits its value across organizational boundaries.

A third-party auditor could issue, modeled on the way security certifications work. This is the most independent option but adds friction and cost.

A regulator could mandate the schema and require self-attestation under penalty of misrepresentation, as DSCSA does for pharmaceutical transactions.

Most likely, the answer is some combination, varying by field. The model provider attests to the model lineage. The platform attests to the configuration. The operator attests to the constraints and the responsible party. A third party attests to trust signals when those exist. The passport becomes a composed credential with multiple signers, each accountable for the fields they signed.

This is unsettled. It is the part of agent provenance that will be fought over for the next few years, and the fight will determine more about how the system works in practice than any technical decision.

The window

The agent provenance work is going to happen. The question is whether it happens as a coordinated effort that learns from the three precedents, or as a fragmented set of vendor-specific approaches that the industry then spends years reconciling.

The first path is much better than the second, for everyone except the vendors who would prefer their version to win. The window for the coordinated path is open right now, while standards bodies are still figuring out their positions and the major AI platforms haven't yet locked in proprietary approaches. W3C Verifiable Credentials, the OpenID Foundation's OID4VC work, and the broader decentralized identifier ecosystem give the industry a foundation that already exists. NIST AI RMF gives a vocabulary for some of the trust signals. The pieces are in place. What's missing is a specific schema for agent passports and a critical mass of issuers and verifiers committed to using it.

This is one of the three under-built layers I named in an earlier essay. The other two — audit and cross-boundary verifiability — are each their own piece. But of the three, provenance is the one with the most existing precedent, the most reusable infrastructure, and the shortest distance between where we are and what could be built. It is also the foundation the other two layers need. You cannot audit what you cannot identify. You cannot verify across boundaries without a portable record of what's crossing.

The passport comes first.