An agent hands work to another agent. Its permission should shrink with the assignment. The operational question is whether the receiving runtime checks that boundary before allowing an action—or merely records the credential accompanying it.
That distinction frames ServiceNow’s October 15 AI Passport announcement. For platform teams, the useful evaluation is less about possessing a signed scope than proving where that scope becomes a binding decision.
A signed passport moves authority checks into the workflow
ServiceNow describes AI Passport as a cryptographically signed runtime credential, issued through Super Intelligence Control Tower and grounded in CMDB context, GRC policies, and workflow approvals. It says delegated scope can narrow at each step, with verification and precision revocation.
The company names NVIDIA as a design and launch partner for enforcement using Open Agent Safety Platform, OpenShell, and Sentry. These remain vendor descriptions, rather than demonstrated customer outcomes. The release forecasts Q4 2026 availability; it does not confirm customer access on October 18.
The practical distinction is between conveying an authorization decision and ensuring that every recipient applies it. A pilot should make that transition visible.
The enforcement point decides whether the claim has force
NVIDIA’s OpenShell architecture documentation describes an agent sandbox separated from a trusted supervisor. The supervisor mediates network requests and supplies credentials where policy permits. This documents OpenShell’s controls, without establishing that Passport credentials have been integrated or tested.
The OpenShell security guide makes a consequential distinction: audit mode logs violations while forwarding traffic; enforce mode blocks requests that do not match rules. It also describes unlisted endpoints as blocked by default.
For a Passport evaluation, a recorded violation therefore cannot stand in for proof of prevention. Operators should ask which component made the decision, which policy it applied, and whether the action reached its destination. The reviewed documentation does not establish how Passport scope maps to OpenShell rules.
Existing MCP governance does not answer Passport deployment questions
ServiceNow’s AI Gateway documentation describes governance for MCP transactions, including external agent platforms, OAuth 2.1 identity controls, and usage and latency visibility. It lists product, plugin, and role prerequisites.
Those requirements belong to AI Gateway. The page does not establish Passport licensing, configuration dependencies, or supported enforcement points. Teams should request Passport-specific deployment documentation before estimating integration work or assuming an existing Gateway installation supplies the required controls.
What must an operator prove before a passport can stop an action?
Test enforcement, delegation, and revocation at each runtime before widening scope.
The following are editorial evaluation criteria, not reported product results. Start with a permitted action, then delegate a narrower task. Attempt an action outside the delegated boundary at each receiving runtime. Inspect both the denial and the destination to establish whether prevention occurred before execution.
Repeat with missing, invalid, stale, and revoked credentials. Interrupt access to the checking component. Require an explicit account of whether work stops, continues, or follows an exception path, and compare that behavior with the team’s intended policy.
The pilot should also distinguish a rejected credential from an unavailable verifier. Those conditions may require different operational responses, but neither should disappear into a generic success record. Ask operators to trace the resulting decision back to the delegated scope and its enforcement point.
Finally, reconcile the handoffs: who delegated, what authority remained, which runtime checked it, and what happened next. Measure the integration effort and decision delay during the pilot. Until those observations exist, a signed scope supports an authority claim; the receiving runtime’s behavior determines whether operators can rely on it.