Two IAM vendors shipped agent identity in three weeks and a regulator opened an inquiry. Meanwhile most production agents still share one API key in an n8n credential store. Here is the gap, and the retrofit order.
Last Updated: October 11, 2026
Okta and SailPoint both shipped agent identity control planes in the last three weeks, and the UK ICO opened a call for evidence on agentic AI in the same window. None of it helps if your agent has no identity to govern. In most real builds it doesn't: one API key lives in an n8n credential or an MCP server config, and every downstream system sees the same caller regardless of which agent, which step, or which human triggered the run. Fix the architecture in this order: inventory and ownership, per-agent credentials, a broker in the request path, then end-user delegation. Buying a control plane before step two gives you a dashboard of one identity.
Two vendor conferences and one regulator, inside three weeks
The product news is real and more specific than the category usually gets. Okta's Oktane 2026 announcement pack lists Agent SSO as GA now, bringing the Cross App Access (XAA) protocol into the platform and swapping long-lived API keys for short-lived, identity-governed tokens at no extra cost inside core Okta SSO. Agent Gateway — an Okta-secured broker that aggregates MCP servers, injects credentials and brokers every tool call — is listed GA in Q3 CY26, with a gateway-based kill switch and a visual Configuration Designer landing in Q4 CY26. Shadow agent discovery arrives in two flavours: through CrowdStrike Falcon Discover (early access now, GA Q4 CY26) and through Okta Verify on managed devices (EA Q4 CY26, GA Q1 CY27).
A fortnight later, SailPoint used Navigate to announce an expanded Agentic Fabric with inline runtime authorization, an agent kill switch, Agent Audit evidence export, and Entro-powered credential lineage, exposed secret discovery and prompt intent monitoring targeted at global availability in early Q4. On the same stage, SailPoint's CEO framed the problem in blunt operational terms rather than compliance terms.
the real issue now … is how do you secure all these identities?
— Mark McClain, CEO, SailPoint, SiliconANGLE, October 2026
Then the regulator. The ICO opened its agentic AI call for evidence on 8 October 2026, closing 20 November, with sections on data security, transparency, accountability, automated decision making and lawfulness of processing. Accountability questions in that list are the ones that bite builders: if an agent reads or writes personal data, somebody has to be able to say which agent, acting for whom, under what authority.
Treat the 79% and 2% as vendor-sponsored research measuring self-reported states, not audited reality. The direction is still right and matches what I see in builds: agents went to production far faster than the identity plumbing under them.
Okta and partners publish the Blueprint Alliance reference architecture, organised around four questions: where are my agents, what can they do, what are they doing, how do I respond.
Agent SSO GA with Cross App Access; Agent Gateway GA Q3 CY26; gateway-based kill switch and Configuration Designer slated Q4 CY26; ITDR with Permiso in EA Q4 CY26 for the US and Canada.
SailPoint Navigate: Agentic Fabric expansion, inline runtime authorization, agent kill switch, A-ISPM expected in Q4, Entro integration reported as still in limited internal testing with customer access targeted for November.
ICO agentic AI call for evidence opens; responses close 20 November 2026.
Your agent does not have an identity. It has a key.
Open any n8n instance running agentic workflows and trace one tool call to its destination. The AI Agent node reaches a tool. The tool node resolves a credential from n8n's encrypted credential store. The credential is a bearer token, an OAuth refresh token obtained once by a human, or a service account key. It is attached to the node, not to the agent, and the same credential is typically reused by every workflow in the project. Salesforce, Postgres or Slack see one caller. The agent's name, the workflow run ID, the step index and the end user who asked for the work exist only in n8n's own execution log, which no downstream system reads and no auditor accepts as authorisation evidence.
Okta's own description of the failure mode is the same one I see in client-facing builds: a developer drops a GitHub personal access token and a Slack token into an agent's config, and now there is an agent with standing access to source control and internal channels, with no way to separate the agent's actions from the human's. Self-hosted n8n adds a wrinkle: secrets often arrive as environment variables in a container, so the blast radius of the box is the blast radius of every integration.
There are exactly four places an agent identity can live. Knowing which one you are using determines what any IAM purchase can actually do for you.
| Where identity lives | What the downstream system sees | Who can revoke, how fast | Visible to an IAM control plane? |
|---|---|---|---|
| Orchestrator credential store (n8n credentials, Make connections, Zapier auth) | One shared principal for all workflows and agents in the project | Workflow owner, by deleting or rotating the credential and breaking every workflow using it | No, unless the orchestrator is itself onboarded as a governed app and each credential maps to a distinct downstream account |
MCP server config (headers, env vars, local .mcp.json) | Whatever static token the server was handed, often a long-lived PAT | Whoever owns the token at the provider; typically manual | Partially — endpoint discovery can find local MCP servers on managed devices, but not a server running in your own VPC |
| Tool or API (per-agent service account, scoped app, workload identity) | A distinct principal per agent, with its own scopes and audit trail | The resource owner, immediately, without touching other agents | Yes — this is what IGA and entitlement management were built to certify |
| End-user delegation (token exchange, on-behalf-of, Cross App Access) | The agent acting for a named user, within that user's entitlements | Revoke the user's grant or the agent's client; effective at next token refresh | Yes, and it is the only model that survives an access review of customer data |
Nearly every build I have worked on starts in rows one and two and has aspirations toward rows three and four. The vendor announcements are aimed almost entirely at rows three and four.
What the new control planes can see, and what they cannot
Okta is explicit that Agent Gateway does not replace your existing MCP or API gateway — it adds an identity and policy layer on top, with agents pointed at the gateway endpoint and no code changes required. That sentence contains the whole limitation. Policy applies to traffic that traverses the gateway. An n8n HTTP Request node firing at a vendor API with a vaulted key does not traverse it. Neither does a Python step in a Lambda, a cron job calling Stripe, or a self-hosted MCP server your data team stood up last quarter on an internal subnet.
The same applies to the kill switch. Okta's description is precise: for agents connected through Agent Gateway, deactivation makes the gateway reject every request carrying a token that agent already holds, without waiting for expiry or downstream cooperation. Correct — and the implied contrapositive is the part to plan around. A PAT that an agent obtained outside the gateway still works after you press the button, because the resource server was never asked.
Discovery has the same shape of boundary. Fleet-wide endpoint scanning through EDR and device trust finds agents and MCP servers on managed laptops, which genuinely closes the biggest shadow-AI hole in engineering orgs. It does not enumerate a Docker Compose stack on a cloud VM that nobody registered, which is exactly where a lot of production automation actually runs.
Buying the control plane before splitting the credential
The procurement conversation is easier than the refactor, so teams license agent governance first and discover that the platform faithfully reports one identity: the shared service account everything already uses. Certifications pass, dashboards are green, and the actual blast radius is unchanged. The control plane can only govern distinctions that exist at the resource.
A retrofit sequence for an existing n8n and MCP stack
You do not need to rebuild the orchestration layer. You need to change what the orchestration layer presents at the edge. This is the order that works, and it is deliberately boring at the start.
Retrofitting per-agent identity without a rewrite
Not workflows — agents. An agent is a model plus a harness plus an identity; if the third part is missing you have an unowned integration, not an agent. One row per agent, with owner, trigger source, tools reached and data classification touched.
One downstream principal per agent per system. In n8n that means one credential object per agent, named with the agent ID, and project-scoped sharing switched off for anything with write access. Expect this to be the slowest step; it is also the one that makes everything after it cheap.
Replace static keys with OAuth clients or workload identity wherever the provider supports it, and pull the rest from an external secret manager so rotation is a config change, not a workflow edit.
An agent gateway, an internal MCP proxy, or your API gateway with an auth plugin. Whatever you choose, the rule is that no tool call reaches a production system except through it. That rule is a networking and code-review decision, not a product feature.
The MCP authorization spec has servers advertise protected resource metadata and reject tokens not minted for them, rather than accepting whatever bearer string the client sends.
Only once steps 1–5 hold does delegated access mean anything. Token exchange or Cross App Access carries the initiating user into the downstream call so the resource enforces that user's entitlements, not the agent's superset.
Step five is where the protocol work has actually landed. The MCP authorization specification models the server as an OAuth 2.0 resource server: an unauthenticated request gets a 401 with a WWW-Authenticate header pointing at protected resource metadata (RFC 9728), the client discovers the authorization server, and tokens are bound to a canonical resource identifier using resource indicators (RFC 8707). Insufficient scope at runtime returns a 403 with the scopes the operation actually needs, so a client can step up rather than fail opaquely.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.internal.example/.well-known/oauth-protected-resource",
scope="invoices:read"If your MCP servers never emit that response — if they read a token from an env var and trust it — you have a transport, not an authorization boundary. That is the single highest-leverage change available to most teams right now, and it costs a day per server. We build orchestration this way by default on automation builds, because retrofitting it after fifty workflows exist is a quarter of work, not a day.
What none of this fixes: the agent acting fully in policy
Every product in this category narrows what a compromised agent can reach and shortens how long it keeps reach. None of them decide whether the agent should have done the thing. An agent with legitimate invoices:write scope, pointed at a poisoned document that instructs it to reroute a payment, is not an authorization failure. It is authorization working exactly as configured. Inline runtime authorization and prompt intent monitoring help at the margins by flagging calls that diverge from the original session intent, but detecting intent drift in a language model is a probabilistic control, and vendors should be asked for their false-negative behaviour before it is treated as a gate.
The same gap applies to the confused deputy pattern: agent A legitimately calls agent B, and B executes with its own broader privileges on behalf of a request it cannot attribute. Okta's Agent-to-Agent Connections exist precisely to keep a delegation record across those hops, which is the right structural answer, but the record only helps if both agents are inside the governed path.
Treating identity as a substitute for a human gate
Per-agent identity gives you attribution and fast revocation. It does not give you judgement. Teams read "runtime authorization" as permission to remove the approval step on irreversible actions — payments, contract issuance, production writes, outbound customer comms — because the agent is now governed.
What to buy, what to build, and what to defer
Buy the control plane when you already have distinct principals to govern and a request path you can force traffic through. At that point the value is real: certification of agent entitlements, exportable audit evidence, instant deactivation, and discovery of the agents your developers started without telling you. Okta's on-demand integration tooling — new governance connectors generated in as little as 48 hours against a catalogue of more than 8,000 integrations, versus the two to three months a manual connector took — is a genuine operational unlock if your long tail of SaaS is the reason governance stalled.
Build the parts that are specific to your stack: the per-agent credential mapping, the broker enforcement rule, the MCP resource-server behaviour, and the run metadata that links a tool call to an agent, a workflow execution and an initiating user. No vendor can infer those from outside. This is most of what our AI integration work actually consists of once the model selection conversation ends.
Defer the pieces that are still dated rather than delivered. Several of the most useful capabilities announced in the last three weeks carry Q4 CY26 or Q1 CY27 availability, and at least one integration described as reaching general availability in early Q4 was reported from the same event as being in limited internal testing with customer access targeted for November. Those are not scandals — shipping cadences slip — but do not sequence a compliance commitment behind a slide. Write your retrofit plan so that steps one through five hold with the tooling you already own, and let the control plane arrive into a stack that is ready to be governed. If you want a second pair of eyes on where your agents actually authenticate today, start here.
Frequently Asked Questions
What is AI agent identity governance, in practical terms?
It is the ability to answer four questions about every agent you run: which agents exist, what each can reach, what each actually did, and how fast you can cut it off. That requires a distinct downstream principal per agent, a named human owner, enforcement in the request path, and audit records the resource owner — not just your orchestrator — can produce.
Does Okta's Agent Gateway govern my n8n workflows?
Only the calls that route through it. Okta positions Agent Gateway as an identity and policy layer on top of your existing MCP or API gateway, with agents pointed at the gateway endpoint. An n8n node calling a vendor API directly with a stored credential bypasses it entirely. Forcing all tool traffic through one broker is a networking and code-review decision you have to make yourself.
Should every agent get its own service account?
Yes, per agent per system, as the first step. Shared accounts make revocation all-or-nothing and make attribution impossible. Start with plain service accounts even if scopes are initially identical, then tighten scopes and move to short-lived credentials. Expect account sprawl, so pair the split with ownership metadata and an expiry date from day one.
How should an agent act on behalf of a specific end user?
Through delegation, not impersonation. The agent presents its own identity plus a token that carries the initiating user, and the resource enforces that user's entitlements. Okta's Agent SSO brings the Cross App Access protocol into this role; token exchange patterns do the same thing standards-side. Do this last — delegation on top of a shared key just mislabels the same shared access.
Does the MCP specification solve agent identity on its own?
It solves the server side of the handshake. The MCP authorization spec treats the server as an OAuth 2.0 resource server, using protected resource metadata discovery via a 401 challenge and resource indicators so tokens are bound to a specific server. It does not tell you which agent is behind the client, how to provision one principal per agent, or how to certify entitlements. That remains your IAM and build work.
Does the ICO call for evidence create new obligations right now?
No. It is a consultation that opened on 8 October 2026 and closes on 20 November 2026, intended to shape guidance on applying data protection law to agentic AI. Existing UK GDPR duties already apply. The practical signal is the subject list — data security, accountability and automated decision making — which is hard to evidence without per-agent attribution.
What should I do first if agents are already in production?
Inventory agents and assign a human owner to each, then list every credential each one can resolve. Most teams find one or two credentials with far broader scope than any single workflow needs. Revoke or scope those down before buying anything. Until an action can be traced to a named agent and a named initiating human, keep an approval gate on anything irreversible.
Research digest
AI Research Briefing
Honest insights on AI agents, Small Language Models, and local RAG. No hype. Only when we have something worth sending.
- No hype, just measurable outcomes
- Read by 2,400+ engineers
- Unsubscribe anytime
