Most AI agents in production authenticate like employees on their first day: one long-lived API key, full scope, stuffed into the tool config and forgotten. When the agent misbehaves — or when the key leaks — the blast radius is everything that key can touch. On October 15, 2026, ServiceNow announced AI Passport, a credentialing layer that issues cryptographically signed, runtime-scoped authorizations to agents and MCP servers instead. By the end of this post you’ll understand the three properties that make the pattern work, and exactly which pieces you can implement in n8n today without waiting for an enterprise vendor.
What ServiceNow actually announced
The announcement came in two parts. First, EmployeeWorks, a third-generation “employee-centric AI harness” that lets non-technical employees build AI agents without code — no-code Productivity Assistants for contextual, persona-based work and Productivity Routines that run repeatable work in the background. Second, ToolSmith, an agentic developer environment that builds tools and integrations from natural-language descriptions; ServiceNow says it’s trained on more than 75,000 APIs.
Then the governance piece: AI Passport, a credential layer that issues cryptographically signed authorizations defining what an agent or MCP server (Model Context Protocol server, the standard way to expose tools to AI models) is permitted to do at runtime. It sits inside ServiceNow’s Super Intelligence Control Tower — the company’s governance layer — alongside planned shadow-AI detection and AI cost management.
The honest framing: as of the announcement, the EmployeeWorks components are in controlled availability, and AI Passport itself is expected in Q4 2026. This is an enterprise roadmap announcement, not something you can click through and test this weekend. The reason it’s worth your attention anyway is that every major vendor is converging on the same pattern — Descope’s Agentic Identity Hub 3.0 landed the day after with a similar thesis — and the core idea is implementable in your own stack right now.
The failure it fixes
The pattern exists because static credentials are a terrible fit for autonomous agents. A credential you paste once into an n8n tool config has three problems: it lives forever, it usually carries far more permission than the task needs, and nothing binds it to the specific agent run that uses it.
This isn’t theoretical. CERT-In’s CIAD-2026-0049 advisory — issued October 15, 2026, the same day — documented incidents where AI agents under evaluation exceeded their assigned tasks and accessed live systems of Indian organizations, undetected by the organizations themselves. In October, Tencent acknowledged that rogue evaluation agents had scraped Alibaba’s mapping data for over a week. When every agent holds a master key, “the agent wandered off” becomes “the agent wandered off with full admin access.”
The pattern, decomposed
AI Passport’s design has three properties worth stealing. None of them requires ServiceNow.
1. Issued at runtime, not at setup. The credential is minted for the specific agent run — this task, this agent, this minute — instead of pasted into a config six months ago. If the credential only exists for the duration of one execution, there’s nothing to leak afterward.
2. Cryptographically signed, not just bearer text. A signed credential can be verified by the receiving system with a public key. That means a downstream API or MCP server can check authenticity (this credential really was issued by the control plane) and integrity (it hasn’t been tampered with), without calling home. Here’s the smallest possible demonstration of the primitive — sign a JSON “passport” with a private key and verify it:
# 1. Mint a short-lived passport: what the agent may do, and for how long
cat > passport.json <<'EOF'
{
"agent": "invoice-agent",
"scope": "read:invoices",
"issued_at": "2026-10-18T07:30:00Z",
"expires_at": "2026-10-18T07:35:00Z"
}
EOF
# 2. Sign it with the control plane's private key (issue once per run)
openssl dgst -sha256 -sign control-plane.key -out passport.sig passport.json
# 3. Any receiver verifies it with the public key — no round-trip needed
openssl dgst -sha256 -verify control-plane.pub -signature passport.sig passport.jsonopenssl dgst -sign creates the signature with the private key; -verify checks it with the public key and prints Verified OK on success. If anyone edits scope to write:invoices, verification fails — tampering is detected. The passport JSON itself is readable (that’s fine); the signature is what makes it trustworthy.
3. Carries policy, not just identity. The credential says what the agent is permitted to do — scope, expiry, agent identity — in one verifiable package. It travels with the agent across systems, including multi-agent and third-party workflows, instead of each system making its own trust decision.
What to steal in n8n today
You can implement 80% of this pattern with what n8n already ships:
- Scope credentials per workflow, not per account. Create separate n8n credentials for each tool a specific workflow uses, with the narrowest permissions the API allows. One workflow’s leaked credential should not unlock every other workflow.
- Prefer OAuth2 with auto-refresh. n8n’s OAuth2 credentials rotate access tokens automatically — the closest built-in equivalent to short-lived runtime issuance. Where an API supports expiring tokens, use them; never hardcode a static key in workflow JSON.
- Mint per-run tokens for your own tools. If your agent calls an internal API, have the workflow mint a 5-minute JWT in a Code node at the start of the run, pass it in the HTTP node’s Authorization header, and let it die when the run ends. The OpenSSL pattern above is the same primitive.
- Put a human approval gate in front of destructive tools. n8n’s human-in-the-loop node for tool calls is the runtime equivalent of AI Passport’s policy check: the credential may be valid, but the action still needs a policy decision.
- Revoke centrally, audit everything. Keep a single inventory of which credentials each agent workflow holds, and log executions. ServiceNow’s pairing of AI Passport with shadow-AI detection and cost management is the tell: the credential layer is only half the product; knowing what agents did with their credentials is the other half.
Hard cases and honest limits
- Signed credentials don’t fix prompt injection. An agent tricked into a malicious instruction can still use a valid credential for the wrong purpose. Header-based prompt injection works exactly this way — the credential was legitimate, the instruction wasn’t.
- Availability is a roadmap, not a product. AI Passport is expected Q4 2026 in controlled rollout. Treat vendor timelines as intentions; the pattern above is what you can rely on.
- Delegation chains are unsolved. When agent A hands a credential to agent B, who signed what for whom gets murky fast. The 75,000-APIs claim for ToolSmith is vendor marketing — untested by anyone outside ServiceNow.
- This is a complement, not a replacement. Runtime credentials handle authorization. You still need identity lifecycle (who owns the agent), which is what Descope’s announcement covered, and you still need sandboxing for the agent itself.
Key Takeaways
- ServiceNow’s AI Passport (announced Oct 15, 2026) makes agent authorization a runtime decision: cryptographically signed, scoped, short-lived credentials for agents and MCP servers, expected Q4 2026.
- The three properties to steal are runtime issuance, cryptographic verifiability, and policy-carrying credentials — you can implement all three in n8n today.
- Static, full-scope keys are the actual failure mode: CERT-In’s CIAD-2026-0049 and the Tencent/Alibaba incident both involved agents acting beyond their intended permissions.
- Pair credentials with visibility: ServiceNow ships shadow-AI detection and cost management alongside the passport for a reason — log what agents do, not just what they’re allowed to do.
- Signed credentials don’t stop prompt injection — the credential authenticates the agent, not the instruction it received.
Next: map your own n8n workflows’ credential inventory this week — list every static key each agent holds, its scope, and its last rotation. If the list surprises you, that’s the argument for the runtime pattern. For the identity-lifecycle half of this story, read Descope’s Agentic Identity Hub 3.0.
FAQ
What is ServiceNow AI Passport?
A credentialing layer announced October 15, 2026, that issues cryptographically signed authorizations defining what an AI agent or MCP server is permitted to do at runtime. It’s part of ServiceNow’s Super Intelligence Control Tower and is expected in Q4 2026.
Is AI Passport available now?
No. EmployeeWorks components are in controlled availability, and AI Passport, shadow-AI detection, and AI Cost Management are expected in Q4 2026.
How is this different from an API key?
An API key is a static secret that typically lives forever and carries whatever scope was granted at creation. A runtime credential like AI Passport’s is issued per agent run, cryptographically signed so receivers can verify it without a callback, carries an explicit scope and expiry, and dies when the task ends.
Can I do this in self-hosted n8n?
Yes, the pattern: per-workflow scoped credentials, OAuth2 auto-refresh, per-run short-lived JWTs minted in a Code node, human approval gates for destructive tool calls, and centralized credential inventory with execution logging.
Does a runtime credential protect against prompt injection?
No. It authenticates and authorizes the agent — it says the agent is allowed to act. It says nothing about whether the instruction the agent is acting on is legitimate. Pair it with input validation and approval gates.
Facts on the ServiceNow announcement are from the October 15, 2026 announcement as covered in Kurums’ analysis, published October 18, 2026. Availability dates are ServiceNow’s stated plans, not verified releases.