AI Security Isn’t a Model Problem. It’s an Identity Egress Problem.
Why agentic systems break IAM, and what a delegation control plane must do instead
A workflow was decommissioned. It kept retrying in the background anyway. The tokens were still valid. No exploit was required. Authority outlived intent and the system kept acting.
That failure mode has a name: identity egress.
Not data crossing a boundary, but authority crossing it first, then making harm possible at machine speed.
Across four rooms in San Francisco, the message converged. At the AWS security symposium the stage line was “security first.” In the hallway, at agent governance meetups, and at the VentureBeat panel on “agency observability,” the diagnosis got more precise: agentic systems break identity continuity at machine speed, traditional IAM was built for humans, and most organizations are deploying autonomous systems without a delegation control plane.
Frederick Kautz put the boundary cleanly. This is the line that matters:
Workload identity is necessary, but not sufficient.
Workload identity authenticates a runtime principal and its execution context.
It does not govern whether it should act now, for this intent, through this toolchain, or how fast you can revoke it when context changes.
That missing layer is where breaches will live.
The uncomfortable pattern
Authority moves faster than policy can track it. Authority outlives the intent that justified it. Authority gets reused across contexts without controlled delegation.
Agentic systems compound this because execution is cheap, retries are persistent, and composition is constant.
Machine identities are already the dominant population inside enterprises. Agent ecosystems multiply the number of principals again: not just “agents,” but retrievers, vector stores, tool gateways, token brokers, workflow engines, and background processes that are operationally real even if nobody names them.
So the risk isn’t theoretical. It’s arithmetic.
If you carry one sentence into your next CISO staff meeting, make it this:
Most AI security incidents will not be model compromise. They will be authority escaping its intended boundary.
That is identity egress.
Identity egress vs data egress
Data egress is information crossing a boundary.
Identity egress is authority crossing a boundary.
Identity egress is upstream. Once authority escapes, harmful tool calls become possible even before any sensitive prompt or payload occurs. The agent cannot leak what it cannot reach. But when authority leaks first, the system becomes capable of harm before anyone notices.
This is why “we have IAM” stops being a sufficient answer.
Traditional IAM answers “who are you” with standing permissions for stable principals. Agentic systems create moving, multi-hop authority flows across a graph of actors: agents, tools, retrievers, memory, vector indexes, token services, workflow engines, and human work processes.
The hard questions shift:
Who delegated authority, and can we prove the graph context?
What intent and scope was authority bound to, and when does it die?
How fast can we revoke across every downstream hop?
Call the artifact what it is: the delegation graph. “Chain” is the mental model people reach for. In production it is a graph, with retries, fan-out, fan-in, and cross-domain hops, and stale credentials surviving in the corners. In practice, the ‘actors’ include not only agents, but retrieval systems, token services, workflow engines, and tool gateways. Governance fails at the edges between them.
The security problem is controlling authority flow through that graph.
⸻
Why the usual AI security controls miss the real primitive
Most AI security programs govern the chat surface. The hazard is the authority surface.
Prompt defenses govern text, not execution rights.
DLP governs payloads, not capabilities.
Observability explains failure after execution.
Static IAM encodes standing permissions, not intent-bound delegation.
These controls are not useless. They are simply pointed at the wrong primitive.
Identity egress is solved where authority is minted, delegated, enforced, and revoked, not where text is generated.
⸻
Ghost agents are authority that outlives intent
Ephemeral only means runtime is short-lived. It says nothing about authority lifecycle.
The ghost pattern is authority persisting after intent expires, or authority being replayed outside the context that justified it. In practice, the “ghost” is not always an agent. It can be a retriever job, a token refresher, a workflow engine retry loop, or a tool wrapper service that quietly holds authority longer than it should.
Ghosts appear when credentials are cached for convenience, retries keep running with stale authority, user identity is passed end-to-end through a workflow graph, service accounts become agent identities, or retrieval layers become ungoverned capability multipliers because they sit outside the IAM mental model.
The result is predictable: execution surfaces you cannot confidently revoke, cannot attribute cleanly, and cannot explain without storytelling.
⸻
How attackers weaponize identity egress
Boards don’t budget against vibes. They budget against kill chains.
Identity egress maps directly to credential abuse. Attackers do not need to “hack the model” if they can ride legitimate authority, especially when breakout time is faster than human response.
The agentic twist is delegation laundering: attackers trigger legitimate automation paths that request access “for business reasons.” Delegated authority then gets cached, inherited, replayed, or fanned out across the workflow graph. Persistence looks like normal tool usage, not malware.
Defenders hunt malware. Attackers ride your authority fabric.
⸻
MCP is a case study: connectivity ships before identity, SAFE-MCP is the response
MCP is the cleanest modern example of the pattern: connectivity standards reduce developer friction, then security arrives later as an integration tax. That is not MCP-specific. It is how ecosystems evolve.
When connectivity spreads faster than identity enforcement, you create internet-addressable execution surfaces that behave like tools but lack consistent gates. VentureBeat’s reporting on exposed MCP servers illustrates the consequence.
SAFE-MCP matters because it treats this as an ecosystem security problem, not a one-off configuration failure. The point is not “write a list.” The point is a shared technique catalog and mitigation language that can be operationalized: detections, tests, and controls that break kill chains at predictable links.
MCP expands the tool surface. SAFE-MCP is the attempt to standardize how we prevent that surface from becoming an authority leak.
⸻
Why SPIFFE keeps coming up and what it does not solve
SPIFFE exists because cloud-native systems needed workload identity that is not a static secret. It provides standardized workload IDs and short-lived credentials, typically used with mutual TLS (mTLS).
It keeps coming up because agentic systems create a workload explosion: ephemeral runtimes, tool gateways, memory services, sandbox steps, evaluators, shadow processes, retrievers, and token intermediaries.
SPIFFE-class identity is a substrate. It helps you authenticate workloads and rotate credentials. This is not a criticism of SPIFFE; it is a recognition that authentication and delegation are different control problems.
SPIFFE does not answer whether actor A should delegate to actor B for intent C across boundary D. It does not give you proof of the delegation graph, only authentication events. It does not guarantee you can revoke authority across downstream hops in seconds. It does not express business constraints as enforceable runtime policy.
Workload identity is necessary. Delegation governance is the missing layer.
⸻
Observability without enforcement is delayed forensics
The “agency observability” framing is the right escalation. If you cannot scope an incident with evidence, you must assume broad contamination. That turns every small failure into an existential one.
But observability is not safety. If you can only tell what happened after execution, you built reporting, not control.
Security requires deterministic boundaries around non-deterministic systems. In practice, that means policy enforcement at every authority handoff, not just at login. The minimum enforcement loop looks like this:
a policy decision point at each handoff
time-bounded credentials bound to intent and scope
real-time revocation across downstream hops
circuit breakers for abnormal delegation patterns
a tool gateway that can say no before execution
Policy engines like Cedar show up here because they decouple authorization from application logic. The policy language is not the win. The win is enforcing decisions at the handoff boundary, every time, across the graph.
⸻
Bounded autonomy is the only sane operating model
“Humans review everything” does not scale. Teams route around it.
The workable model is bounded autonomy: agents act inside explicit guardrails enforced at the authority boundary. Humans approve high-impact actions. Autonomy expands only when containment and fast revocation are proven.
This is how you keep speed benefits without surrendering control.
⸻
What to do next quarter
A CISO-readable plan that works across multi-agent, cross-boundary graphs:
Treat every non-human actor as a principal
Include retrievers, vector stores, token brokers, tool gateways, workflow engines, background retries. If you cannot enumerate the authority graph, you cannot govern it.
Move from standing permissions to intent-bound delegation
Pick one critical workflow. Replace standing credentials with short-lived authority minted for a specific intent envelope, scoped to specific actors and tools. Make it revocable at graph granularity.
Enforce at the boundary
Put a tool gateway in front of execution surfaces. If the gateway cannot block, you do not have a control system.
Instrument delegation graphs end-to-end
Not “who called what,” but who delegated, for which intent, through which actors, under which policy decision, and what executed.
Set and rehearse a revocation SLA
If you cannot kill delegated authority across downstream hops in minutes, you do not have governance. You have delayed forensics.
⸻
The thesis, tightened
AI security is not primarily about model compromise. It is about authority flow.
Identity tells you who a workload is. Security is deciding whether it should act now, for this intent, with this scope, through this toolchain, across these boundaries, and how fast you can stop it when wrong.
That is the delegation control plane Frederick Kautz was pointing at.
If authority cannot be minted, constrained, observed, and revoked as a first-class runtime object, you do not have an agentic system. You have automation with undefined blast radius.
For teams asking “what would this actually look like,” the appendix defines a minimal delegation control plane that can be implemented incrementally.
⸻
Fact check list
CyberArk 82:1 machine-to-human identity ratio is cited in CyberArk 2025 identity security landscape materials.
Microsoft “over 1 million custom agents… up 130% QoQ” is reported in Microsoft-related coverage; use the primary Microsoft wording if you can.
CrowdStrike “fastest breakout time 51 seconds” and “79% malware-free” are stated in CrowdStrike threat reporting; use the exact year and context language they use.
VentureBeat reports 1,862 exposed MCP servers with no authentication (Knostic scan).
Verizon DBIR 2025 continues to emphasize credential abuse as a major driver of breaches; if you want to quote a specific sentence, pin the exact executive-summary language.
Appendix: Delegation Control Plane, Minimally
This appendix defines the minimum viable delegation control plane required to govern authority flow in agentic systems. Not a full reference architecture. Not a product pitch. The smallest set of components that turns identity egress from an audit problem into a control problem.
If any of these components are missing or non-functional, authority flow cannot be reliably constrained, attributed, or revoked across a multi-actor graph.
1. Intent Envelope Schema
The intent envelope is the unit of governance.
It is a structured, machine-readable object that travels with delegated authority and answers one question: why is this authority allowed to exist right now.
At minimum, the intent envelope must encode:
originating principal (human or non-human)
declared intent (task or objective)
allowed scope (resources, data classes, actions)
allowed downstream actors and tools
time bounds and expiry
trust domain or boundary context
The intent envelope is not prompt text. It is not free-form metadata. It must be enforceable by policy and auditable after the fact.
If authority is not bound to an intent envelope, it is standing authority.
2. Token Minting Service
The token minting service issues short-lived, intent-bound authority.
It takes an intent envelope as input and produces a credential that:
is cryptographically bound to that envelope
is scoped to specific actors and destinations
expires quickly by default
cannot be reused outside the declared context
This service may integrate with SPIFFE, OIDC, or cloud IAM, but its distinguishing feature is intent binding, not authentication.
Authentication proves identity. Token minting proves permission for a specific purpose.
If credentials can be reused across intents, delegation governance has already failed.
3. Policy Decision Point (PDP)
The PDP evaluates whether a delegation request is allowed before authority moves.
Inputs include:
caller identity
target actor or tool
intent envelope
environmental context (time, risk, anomaly signals)
policy rules
Output is deterministic: permit or deny, with a reason.
The PDP must be external to agent logic. If authorization is embedded in prompts or application code, it cannot be trusted or audited.
Policy languages like Cedar are useful here, but the critical requirement is consistent evaluation at every authority handoff, not the syntax.
4. Tool Gateway (Enforcement Point)
The tool gateway is where delegation becomes real.
It sits in front of execution surfaces: tools, APIs, workflows, external services, and side-effecting actions. Every invocation must pass through it.
The gateway:
validates the token and intent envelope
consults the PDP
enforces allow or deny before execution
attaches execution context to telemetry
If a tool can be invoked without passing through the gateway, it is an unmanaged execution surface.
If the gateway cannot block, you do not have a control plane.
5. Evidence Store (Delegation Graph Telemetry)
The evidence store records delegation graph events, not just access logs.
It must capture:
who delegated authority
under which intent envelope
to which actor or tool
what policy decision was made
what action executed
what downstream delegations occurred
This is not for dashboards. This is for incident scoping, liability defense, and auditability.
Without delegation graph evidence, every incident forces you to assume worst-case blast radius.
6. Revocation Service
Revocation is the test that proves governance is real.
The revocation service must be able to:
invalidate tokens tied to an intent envelope
propagate revocation across downstream hops
terminate retries, background jobs, and queued work
operate at machine speed, not ticket speed
Revocation must work even when:
the original agent is gone
execution is mid-flight
authority has fanned out
If revocation cannot cross the graph, authority egress is permanent.
How the Pieces Fit Together
A principal declares intent.
An intent envelope is created.
The token minting service issues scoped authority bound to that envelope.
Every delegation and tool call hits the gateway.
The PDP evaluates each handoff.
All events are recorded in the evidence store.
If context changes, the revocation service kills authority across the graph.
This is the delegation control plane.
What This Replaces (and What It Doesn’t)
This does not replace:
IAM
SPIFFE
Zero Trust
Observability stacks
It sits above them.
IAM answers who you are.
SPIFFE authenticates workloads.
Zero Trust reduces implicit trust.
Observability explains what could or did happen.
The delegation control plane decides whether authority should exist at all, under what constraints, and for how long.
The litmus test
If authority cannot be minted, constrained, enforced, observed, and revoked as a first-class runtime object, you do not have an agentic system.
You have automation with undefined blast radius.
That is the difference between “security first” as a slogan and security first as an architecture.
