ServiceNow AI Passport: A UK Production Gate for Runtime Agent and MCP Authorisation
ServiceNow's new AI Passport gives every agent and MCP server a signed, policy-bound scope that is checked at runtime, with a kill switch. Here is the production gate UK platform teams should build before it lands in Q4 2026.
ServiceNow's new AI Passport gives every agent and MCP server a signed, policy-bound scope that is checked at runtime, with a kill switch. Here is the production gate UK platform teams should build before it lands in Q4 2026.
- ServiceNow announced AI Passport on 15 October 2026, expected in Q4 2026.
- Every agent and MCP server gets a signed passport defining what it may do, checked at runtime with a kill switch.
- Passports are on open specifications, so third-party agents and enforcement points can carry and verify them.
- Inventory agents and MCP servers into the CMDB with owners and business services first.
- Write scopes as specific verbs on specific records, kept in Git with the agent definition.
- Issue production passports only through CAB-approved change, and treat scope widening as a new change.
- Prove every agent is refused at runtime when it steps outside scope, not just by its prompt.
- Rehearse the kill switch and track AI cost per agent alongside scope.
What changed
On 15 October 2026 ServiceNow announced AI Passport, a new authority layer inside what it now calls the Super Intelligence Control Tower (the product previously marketed as AI Control Tower). The headline points from the announcement:
- Every AI agent, whether built on ServiceNow or by a third party, receives a cryptographically signed passport issued by the Control Tower, based on policy rules and workflow approvals.
- The passport defines what that agent, and the Model Context Protocol (MCP) servers it calls, are authorised to do at every step of a multi-agent workflow, checked at runtime.
- If an agent goes outside its scope it can be adjusted, restricted or stopped with a kill switch.
- AI Passport is built on open specifications, so other governance products, identity providers and enforcement points can issue and verify passports. NVIDIA is a design and launch partner.
- Alongside it: shadow AI detection, 400+ connectors for AI discovery, access mapping, continuous AI observability, and AI Cost Management inside IT Asset Management.
AI Passport, shadow AI detection and AI Cost Management are expected in Q4 2026. The Operational Resilience solution for financial services is available now.
Why UK platform teams should care now
Most UK estates I see have the same gap. Agent identity is solved at the front door (OAuth client, service account, maybe an AI Gateway allowlist), but nothing re-checks scope mid-workflow. Once an orchestrator hands off to a sub-agent, which hands off to an MCP tool, the original approval is assumed rather than verified.
That is exactly the gap regulators ask about. If you are in scope for the PRA and FCA operational resilience rules, you already have to show you can stay within impact tolerances for important business services. An agent that can quietly widen its own blast radius is a resilience problem, not just a security one.
AI Passport is not available yet, which is the point: use the next few weeks to get your scope model and CMDB ready so switching it on is a configuration change, not a programme.
The production gate
Gate 0: Inventory before identity
You cannot passport what you have not found.
- Export every registered agent, MCP server and AI tool from Control Tower and AI Gateway today.
- Reconcile against the CMDB. Each agent should map to a business service, an owner and a support group.
- When shadow AI detection arrives, treat its first run as a discovery exercise with a triage queue, not an alert storm.
Exit criterion: no agent in production without a CI, an accountable owner and a named business service.
Gate 1: Write scopes as verbs on records
A passport is only as good as the scope it carries. Avoid scopes like itsm_full or hr_read.
| Weak scope | Production scope |
|---|---|
| Can use ITSM | Can read incident where assignment group is in the agent's own groups |
| Can call the HR MCP server | Can call get_leave_balance only, no write tools |
| Can raise changes | Can create change_request of type Standard from approved templates only |
Keep the scope list in Git next to the agent definition, and review it in the same pull request as any prompt or tool change.
Gate 2: Tie issuance to approvals you already run
ServiceNow says passports are issued from policy rules and workflow approvals. Use that.
- Non-production passports: auto-issued from a policy, short-lived.
- Production passports: issued only after the agent's change record is approved at CAB, with the scope list attached as evidence.
- Scope widening is a new change, never an in-place edit.
Gate 3: Prove the deny path
Before go-live, run a negative test for every agent:
- Ask it to perform an action one step outside its scope (a write where it holds read, a table it was not given).
- Confirm the action is refused at runtime, not just by the prompt.
- Confirm the refusal lands in Control Tower observability with the agent identity, the workflow step and the requested action.
If the only thing stopping the agent is its system prompt, it has not passed.
Gate 4: Rehearse the kill switch
A kill switch nobody has pulled is a theory.
- Name who can pull it out of hours (major incident manager, not only the AI steward).
- Document the fallback: which manual or classic Flow Designer path takes over.
- Run it once in a lower environment per quarter and record the time to stop.
Gate 5: Third-party and MCP partners
Because passports are on open specs, you can ask vendors to carry them.
- Add passport support to AI supplier due diligence and contract schedules.
- For MCP servers you host, decide which enforcement point verifies the passport: the gateway, the server or both.
- Until a vendor supports it, keep them behind AI Gateway allowlists with the narrowest tool list.
Gate 6: Put cost on the same page
AI Cost Management in ITAM and the Control Tower value views mean spend can sit next to scope. Set a monthly budget per agent and alert when an agent's consumption jumps after a scope change. Cost spikes are often the first sign of a looping or over-scoped agent.
What I would not do yet
- Do not rip out existing AI Gateway or OAuth controls. AI Passport adds runtime scope; it does not replace authentication at the edge.
- Do not plan production dates around Q4 GA. Plan readiness, then confirm availability for your instance and release family.
- Do not let the rename distract the steering group. The engineering work is the same whatever the product is called.
Thirty-day checklist
- Agent and MCP inventory reconciled to CMDB.
- Scope list per agent in Git, reviewed with prompt and tool changes.
- CAB template updated so production scope is change evidence.
- One negative test and one kill-switch rehearsal per production agent.
- Supplier questionnaire updated for passport support.
Get these done and AI Passport becomes a switch you flip, not a project you start.
Runtime scope is the missing control in most agent estates. The value of AI Passport will depend almost entirely on how well you write scopes and whether you have tested the deny path, so start that work before the product ships.
