What is an agent passport? How to read and verify one

An agent passport is a shareable record describing an AI agent’s identity, assessed version, approved scope and relevant assurance information. In AI Agent Certify’s terminology, an Agent Passport presents an approved summary of a linked Assurance Scorecard, with limitations and status information that a recipient can interpret.

“Trusted Agent Passport” is also used in this site’s earlier material. The name should not be read as a government credential, universal standard or guarantee that an agent is always safe. Ask the issuer what its particular record means and how to check it.

For an enterprise buyer, the practical question is: does this record describe the system and use we are considering? This guide shows how to answer that question without confusing a shareable summary with the full assessment or an access permission.

Key takeaways

• Match the Passport to the exact agent configuration and your intended use.
• Check the issuer, underlying assessment, relevant dates and current status through an agreed channel.
• Keep publication status, operational restrictions and historical assessment findings separate.
• Request controlled access to further information when a material question remains unanswered.
• Confirm the implementation. A Passport concept does not by itself establish a live verification service or cryptographic credential.

Why share a Passport instead of the entire assessment

A buyer, partner or internal reviewer may need to understand what has been examined without receiving raw evaluation traces. Those traces can contain sensitive prompts, customer information or security findings. A short trust badge, meanwhile, can omit the context needed to make a decision.

An agent passport should provide the relevant approved facts and a route to the assessment behind them. This communication function fits the broader assurance discipline described in DSIT’s introduction to AI assurance, which includes communicating findings to appropriate audiences.

The record should make the scope boundary easy to see. An assessment of an internal read-only workflow cannot be silently extended to autonomous external actions just because the agent retains its name.

How the Passport relates to a Scorecard and credentials

The Assurance Scorecard is the assessment record in AI Agent Certify’s described workflow. It connects identity and scope with evaluation criteria, coverage, findings, evidence references and the human review decision. The Passport is a separately approved summary for sharing. The Scorecard overview explains that relationship.

Publication choices should not change the assessment itself. A shareable record can omit confidential details while still explaining a limitation that matters to its reader. Withholding the detail does not turn an unresolved requirement into a passed one.

Also distinguish the Passport from an access credential. A record about an agent’s assessment does not itself authorize the agent to read your documents, call your APIs or act for your users. Those permissions need their own controls. If a supplier combines these functions, ask it to explain which part communicates assurance and which part grants access. The AI agent credential checklist explains the identity and access checks that remain separate from an assurance record.

Read the fields that determine whether it applies

Start with the fields below before looking at badges or aggregate ratings. They are practical reading questions, rather than a claim that every issuer uses the same format.

Agent and version identity

Look for identifiers that distinguish the assessed system from another configuration with the same display name. Ask which model, instructions, tools and environment the identifier represents. A stable product name can conceal a substantial release change.

The supplier should be able to connect the record to the version proposed for your deployment. If it cannot, treat the match as unresolved rather than assuming that all releases are equivalent.

Approved operating scope

Read the permitted tasks, actions, users and environments, followed by the exclusions. Check whether human approval is required and whether any writable tools were outside the assessment.

NIST’s AI RMF Core calls for documenting intended context, application scope, knowledge limits and human oversight. These are useful reading priorities, although NIST does not prescribe the Passport format described here.

Assessment basis and limitations

Find the linked Scorecard or equivalent assessment reference. Identify which policies or frameworks were selected, their versions and the coverage actually claimed. A reference to a framework is not evidence that every requirement was examined.

Look for exclusions, unresolved findings and conditions attached to the outcome. A single overall rating cannot tell you whether an important tool was untested or whether a necessary human handoff remains unreliable.

Dates and review conditions

Distinguish the assessment date, issuance date and subsequent review dates. They represent different events. A newly published record may summarize older evidence.

Check any expiry date and the events that trigger reassessment. A change to permissions or intended use may require review before the calendar date arrives. If the record has been superseded, ask for the replacement and the relationship between them.

Status and the party responsible

Identify the issuer and the organization responsible for the agent. They may be different. Establish who can explain a status change or resolve a discrepancy.

An unexplained “active” label is insufficient. Ask whether it refers to publication, the underlying assessment or permission to operate. The distinction affects what you can reasonably conclude.

Verify the record in five steps

Verification should establish where the record came from, what it describes and whether it remains relevant to your decision. Use the issuer’s supported mechanism; do not assume a public endpoint exists.

1. Establish the source. Obtain the canonical record or an issuer-confirmed copy through a known channel. A logo or screenshot alone does not establish provenance.
2. Match the subject. Compare the agent and configuration identifiers with the system offered to you. Resolve differences in tool access, environment or release.
3. Check currency. Confirm relevant dates, supersession and any suspension, withdrawal or review notice through the supported channel.
4. Trace the basis. Find the assessment reference and understand how to request authorized access to additional information.
5. Compare the claim with your use. Read the scope, exclusions and operating conditions against the actions you intend to permit.

If the Passport uses a verifiable credential format, successful technical verification still has a limited meaning. The W3C Verifiable Credentials Data Model distinguishes verifying an authentic, current statement from establishing the truth of its claims. The recipient still needs to decide whether to rely on the issuer and whether the claim fits the intended use.

That distinction is relevant reading guidance, not a claim that AI Agent Certify implements W3C credentials, digital signatures or a public verification endpoint. Confirm the supported record and access method for the engagement. Our guide to AI agent passport standards maps credential formats, workload identity and interaction protocols to their different purposes.

Worked example An authentic record with a scope mismatch

Consider a hypothetical Passport for a service agent assessed to draft internal case summaries. Its scope requires human review and excludes external publication. The record identifies the configuration and links to its assessment.

A buyer wants the same agent to send those summaries directly to customers. Even if the Passport’s source and status are verified, the proposed workflow introduces a different audience and action. The record does not answer whether customer-directed disclosure and autonomous sending were assessed.

The useful next step is specific: ask for an assessment decision covering the external workflow and the configuration that enables it. The earlier Passport can remain a valid historical summary of the internal use. It should not be edited to imply that the expanded use was always included.

Now suppose the supplier changes only a typographical error in the public summary. That could justify a publication correction without requiring the underlying evaluation to be repeated. The reason for the change matters more than a status label alone.

Keep three kinds of status separate

Publication status describes whether the sharing record is eligible, published, suspended or withdrawn. Operational status describes restrictions or review requirements affecting current use. Historical assessment findings describe what the examination supported at the time.

These dimensions are related, but one should not silently replace another:

• A record may be withdrawn because its public content needs correction while the assessment remains intact.
• An agent may be restricted pending investigation without erasing an earlier Scorecard.
• A replacement assessment may support future use while the previous record remains part of the history.

Runtime monitoring can provide signals that prompt investigation. A signal is not automatically a failed assessment, and it does not necessarily justify publishing sensitive incident details. An authorized review should determine which state needs to change and why.

Preserve the sequence of decisions, relevant dates and links to replacement records. Recipients need to understand what changed and what action it requires from them.

Share enough context while protecting private evidence

Detailed prompts, traces, test data and reviewer discussions may require restricted access. Select shareable fields for the actual audience, with authority to approve the disclosure. Removing names from a trace may still leave sensitive operational information.

The W3C model’s data minimization guidance recommends limiting requested and disclosed information to what is needed for its purpose. Applied here as a design principle, that means communicating the scope and material limitations without routinely exporting the evidence store.

If a consequential question cannot be answered from the Passport, arrange an appropriate deeper review. Confidentiality is a reason to control access, not to imply that unavailable evidence proves a claim.

Frequently asked questions

Does a Passport certify legal compliance?

The AI Agent Certify Passport concept does not. It communicates bounded assurance information. Legal obligations and any formal certification claims need their own applicable basis and review.

Does a missing public record mean an agent failed?

No. Public sharing may be inappropriate, unavailable or restricted to an agreed audience. Ask whether an assessment exists and which information can be provided through an authorized channel.

Can we rely on an exported copy?

Use it as a record of what was shared, but establish whether it remains current. An old export may omit a later restriction or replacement. Agree how current status will be confirmed before relying on it for a consequential decision.

Bring a specific use case to the review

For a first review, bring the Passport, the proposed agent configuration and the tasks you plan to authorize. Work through identity, scope, assessment basis and current status. Resolve mismatches before treating the record as support for your deployment.

Request a demo to discuss AI Agent Certify’s intended Passport workflow and confirm supported sharing and verification arrangements. The Agent Passport overview and assessment guide explain how the shareable record connects to the work behind it.