AI Agent Passport Standards: What Enterprises Should Know

There are relevant standards and protocols to know: W3C Verifiable Credentials and Decentralized Identifiers, SPIFFE, Agent2Agent and the Model Context Protocol. They address different parts of identity, claim exchange, discovery and access. An enterprise evaluating an “AI agent passport” should ask which of these layers it implements and what additional assessment evidence the passport represents.

The reviewed specifications do not establish one universal passport that certifies an agent’s behavior across organizations. Our reading of the sources below supports a layered approach: identify the system, establish appropriate access, exchange claims and separately examine the evidence for the intended use. The status information here was checked on 9 October 2026.

Map each specification to a concrete requirement

Start with the enterprise question, then select the relevant technical document. This avoids buying a credential format when the actual gap is tool authorization, or treating an interoperability feature as an assessment result.

Enterprise requirement	Relevant source and status checked	What remains to decide
Exchange structured, tamper-evident claims	W3C Verifiable Credentials Data Model 2.0, Recommendation dated 15 May 2025	Which issuers and claims the recipient accepts
Represent a decentralized identifier and its verification methods	W3C DIDs 1.0, Recommendation dated 19 July 2022	Identifier method, governance and relationship to the deployed agent
Authenticate software workloads	SPIFFE specifications, a family of open-source workload identity standards	Trust domains, implementation choices and application permissions
Discover and interact with another agent	A2A specification v1.0.0, released protocol specification	Whether the advertised skills are suitable and sufficiently assessed
Authorize access to protected MCP servers over HTTP	MCP authorization specification, 2026-07-28, versioned protocol specification	Resource permissions and business approval rules
Track evolving agent identity practice	NIST NCCoE project update, published 29 September 2026	Which future implementation guidance applies to the enterprise

The table maps purposes, rather than ranking competing products. An architecture may use several of these approaches, a subset, or other suitable controls. Requiring every item without a clear use case can add complexity without resolving the actual assurance question.

Use credential standards to define how claims travel

W3C Verifiable Credentials Data Model 2.0 describes a format for issuer claims and an ecosystem involving issuers, holders and verifiers. It provides a foundation for exchanging tamper-evident information. Importantly, the specification separates verifying a credential from deciding whether its claims should be relied on. Authenticity does not establish the truth or suitability of every claim. See the W3C data model.

For an agent assurance record, the enterprise still needs a shared meaning for fields such as assessed version, permitted use, evidence reference and unresolved limitation. Two records can use compatible packaging while expressing different criteria for “approved.” Require the issuer to explain those criteria and the recipient to define its acceptance rules. If the record includes a rating, interpret the evidence behind the agent trust score rather than treating a shared format as a shared assessment method.

A standard format still needs an application profile

An application profile spells out how a particular community uses a general specification: required fields, permitted values, identity binding, status handling and validation rules. Ask for that profile and its version when a supplier claims passport interoperability. A demonstration should show that the receiving system interprets the material fields correctly, including exclusions and changed status.

Choose identity mechanisms for the right subject

The W3C DID specification defines identifiers, DID documents and verification relationships. A DID may refer to different kinds of subjects. Using one for an agent requires a decision about what it identifies: an organization, an agent service, a release or another entity. The identifier alone does not establish that those subjects are interchangeable.

SPIFFE focuses on identity for software workloads. Its specifications include short-lived identity documents that workloads can use to authenticate to other workloads. That can be relevant to the service running an agent, while the assessment may concern a particular configuration within that service.

Document the relationship among those identities. If one service hosts several agent configurations, service authentication may need a separate association with the assessed release. A procurement team should be able to ask which deployed system a record represents without reverse-engineering the hosting architecture.

Read A2A Agent Cards as discovery information

The A2A v1.0.0 specification defines an Agent Card describing an agent server’s identity, capabilities, skills and interaction requirements. It also specifies optional card signing. These mechanisms help clients discover agents and establish how to communicate with them.

For passport planning, distinguish an advertised capability from evidence that the capability met your security or business requirements. A card can help a client find an agent that offers invoice analysis. The enterprise still needs to decide whether that agent may receive its invoices and whether the proposed use has been assessed.

If an implementation links an Agent Card to a separate assurance record, ask how the association remains correct as versions change. Also ask what happens when the advertised service stays available but an assessment is superseded or the approved use becomes more restricted.

Treat MCP authorization as an access layer

The MCP authorization specification reviewed here defines authorization flows for HTTP-based transports. It draws on OAuth mechanisms and distinguishes protected servers, clients and authorization servers. The document also makes clear that its HTTP flow does not apply identically to other transports.

An enterprise passport requirement should therefore identify the deployed transport and authorization arrangement. “Supports MCP” does not explain which resources the client can reach, which user it acts for or which business actions require separate approval.

The cited version references both published RFCs and drafts, including an OAuth 2.1 draft. Preserve those version and status distinctions in technical reviews rather than labeling every dependency a finalized standard. For implementation work, confirm the supported protocol version and current security guidance directly with the relevant projects.

At the business layer, test whether the granted permissions fit the task. A technically valid access token can still authorize more activity than an enterprise intends to delegate. The AI agent credential checklist covers issuer trust, audience, validity and the separate resource authorization decision.

Track emerging work without overstating its status

NIST’s 29 September 2026 update reports feedback on its software and agentic AI identity concept paper and identifies a DevSecOps implementation use case. It describes evolving identity and authorization work, rather than announcing a universal agent passport certification scheme.

Apply the same status discipline to industry proposals. A publicly available vendor schema, community draft or product feature may be useful. Evaluate its governance, normative requirements, maintenance process and independent implementations before describing it as an established interoperability standard.

Keep a short dependency register with the document owner, version, maturity, implemented subset and unresolved issues. Revisit entries when an implementation changes or a new specification affects a requirement your enterprise actually relies on.

Test the proposed combination with one workflow

Consider a hypothetical procurement agent that asks a supplier’s agent to explain a delivery schedule. The supplier advertises its interaction details through an Agent Card. The enterprise authenticates the relevant services and permits access only to the order information needed for that request.

Separately, a shared assurance record says the supplier agent was assessed for answering schedule questions from specified records. It explicitly excludes changing an order. These are complementary facts: how to reach the service, how access is controlled and what the assessment examined.

Now the workflow expands to rescheduling deliveries. The service identity and communication protocol may remain unchanged. The previous assessment scope still needs review because the requested business action has changed. No credential packaging choice resolves that mismatch automatically.

Use this kind of exercise when testing passport requirements. Ask the receiving team to distinguish the correct service, release and permitted action, then introduce a scope change and a superseded assessment. Record which conclusions it can and cannot make from the information provided.

Ask suppliers for precise interoperability claims

Before accepting “standards-based agent passport” as a purchasing criterion, request:

1. The specification names, versions and implemented profiles.
2. The subject each identifier represents and its link to a deployed release.
3. The distinction between advertised capabilities and assessed behavior.
4. The issuer, criteria and evidence basis for assessment claims.
5. The receiving system’s handling of exclusions, status and supersession.
6. A demonstration using the recipient’s requirements and access boundaries.

AI Agent Certify uses Agent Passport for a reviewed, shareable view of bounded assurance information, linked to an Assurance Scorecard. That product concept does not imply implementation of every specification discussed here or recognition as a universal standard. The existing Passport guide explains its intended evidence and sharing boundaries.

To discuss what your enterprise needs to communicate about an assessed agent, Request a demo. Start with the recipient’s decision, then identify the record, identity and interoperability requirements that would make that decision reviewable.