← Latest reporting

An agent passport must not expand authority through delegation

ServiceNow’s planned AI Passport makes signed scope a runtime concern. Buyers should test the intersection of permissions, not only the credential’s authenticity.

Policy, Standards and GovernanceAI Capability Frontier
Conceptual AI illustration of three nested torn-paper hand silhouettes with successively shorter reaches, representing narrowing delegation rather than tested security.
Conceptual illustration generated with AI under editorial direction; it does not depict a real event.

What happened

ServiceNow announced AI Passport on 15 October as a runtime authority credential for agents and MCP servers, with availability expected in Q4 2026.

Why it matters

An identifiable agent can still request an unauthorised downstream action. Delegation needs a testable rule for what each actor may pass on and when that authority stops.

Signed authority is a proposal to test

ServiceNow’s 15 October announcement describes AI Passport as a cryptographically signed credential that agents consult at runtime. The company says it supports scoped delegation, revocation and enforcement across multi-agent workflows, with NVIDIA as a design and launch partner. AI Passport is expected in the fourth quarter of 2026. The release’s separate Operational Resilience offering is available now; that does not make every announced capability generally available.

These are vendor descriptions, not an independently reproduced security result. The release says the approach uses open specifications, but it does not itself supply the complete implementation and conformance evidence needed to establish how every third-party enforcement point behaves. The immediate buyer decision is what a pilot must prove before an agent is allowed to delegate consequential work.

Require the intersection, not the largest permission set

Our proposed acceptance rule is simple: a downstream action should be allowed only where the caller’s delegated scope, the receiving agent’s permitted scope and the resource’s current policy all allow it. This is a recommended contract for the test, not a claim that ServiceNow implements a particular mathematical policy or that its product has failed one.

The independent architectural baseline is NIST SP 800-207. It distinguishes authentication from authorisation and focuses protection on resources rather than network location or ownership. That guidance is not an agent-passport specification and does not certify the announced product. It explains why knowing who issued a credential and deciding whether this resource action is allowed remain different questions.

For a bounded pilot, define one low-consequence workflow with a named resource owner. Give the first agent permission to read one approved collection, and give a downstream helper a broader capability in its ordinary configuration. Ask whether the first agent can borrow that broader capability by delegation. The test should fail closed under the proposed contract. Record the actual decision at the resource boundary, rather than accepting the agent’s explanation of what it was allowed to do.

Then reverse the arrangement. A broadly authorised caller should not make a deliberately restricted helper more powerful merely by naming it. The desired result is the permitted overlap, with an inspectable reason for denial elsewhere. Choose harmless synthetic test objects and do not exercise these cases against live employee or customer records.

Revocation needs an observable stopping point

Revocation adds a time question. In a controlled environment, remove authority after work is queued, while a helper holds a cached credential, and between a read and a proposed write. Specify which actions must stop and which already-completed actions require remediation. A successful denial on a fresh login is insufficient evidence about an old session or queued downstream operation.

Keep an authorisation trace containing the initiating principal, delegate chain, credential and policy versions, resource action, decision and relevant timestamps. Ask how the system behaves when an issuer, verifier or policy service is unavailable. Decide the safe response with the resource owner before testing; do not infer it from a signed token or a kill-switch label.

These are operational recommendations, not performance findings. The announcement does not demonstrate universal connector coverage, revocation latency or prevention of every out-of-scope action. A launch partner is not an independent replication, and generic zero-trust guidance cannot fill those evidence gaps.

The earlier identity-through-the-delivery-path question provides context. This new acceptance gate is more specific: can each delegation preserve or reduce effective authority, and can an observer show precisely where an attempted expansion was denied? Until a pilot answers that, treat the passport as a promising authority mechanism to evaluate, not a completed assurance case. Define who can accept the residual risk when a required test remains incomplete.