The invisible explosion
Read on if your IAM program manages AI agents with the same policies as regular service accounts — the governance gap is wider than you think.
Consider a typical enterprise that has recently deployed several AI-powered assistants: a customer service agent, a code review bot, and an internal knowledge assistant. When security teams ask about the Non-Human Identity (NHI) inventory, they’re often pointed to the service account registry — meticulously documented, perhaps containing hundreds of entries.
The AI agents aren't in it.
In assessments, teams should look for patterns such as a patchwork of credentials: API keys embedded in configuration files, OAuth tokens with no expiration, service principals with permissions inherited from a developer’s account during initial testing. The customer service agent might have read access to the entire CRM. The code review bot can approve and merge pull requests. The knowledge assistant holds tokens to every internal API it was ever connected to during development.
This risk pattern is not hypothetical. Machine identities already vastly outnumber human ones. CyberArk’s 2025 Identity Security Landscape survey of 2,600 cybersecurity decision-makers reports a ratio of 82:1, and AI agents are a new, harder-to-govern subset on top of that. Public summaries of the SANS 2026 NHI Survey of over 500 security professionals put hard numbers on the acceleration: 76% of organizations report NHI growth, NHI populations have doubled or tripled inside many enterprises, and 74% deploy AI agents or automations that require credentials or access permissions. Gartner predicts that 40% of enterprise applications will integrate task-specific AI agents by the end of 2026, up from less than 5% at the time of the release. IAM programs haven’t caught up. Agents slip through the governance cracks, operating with credentials that were never inventoried and never reviewed.
The governance signal extends beyond agent identity. Gartner’s AI TRiSM prediction that through 2026 at least 80% of unauthorized AI transactions will stem from internal policy violations is broader than agent IAM, but it points the same way: many unauthorized AI transactions are likely to come from internal policy failures, oversharing, unacceptable use, or misguided AI behavior rather than classic external compromise. Forrester predicts that an agentic AI deployment will cause a public data breach by end of 2026. The SANS findings make that prediction plausible, not inevitable: weak credential rotation, unclear ownership, and immature runtime controls create the conditions in which an agentic-AI breach becomes more likely.
Why agents aren’t just another service account
Traditional NHI governance was designed for a predictable world. Service accounts run scheduled jobs. API keys authenticate known integrations. Machine certificates identify servers. These identities have clear ownership, stable permission requirements, and predictable lifecycles. Your CI/CD pipeline doesn’t suddenly decide to query the HR database because it seemed relevant.
AI agents break every one of these assumptions.
Autonomy changes everything. Traditional service accounts usually execute predefined workflows. Agents may interpret goals, select tools, and decide intermediate steps at runtime, including how to interact with untrusted context. When you give a customer service agent access to your order management system, you’re not authorizing a specific set of API calls. You’re authorizing whatever the agent determines is necessary to help customers. Today that’s order lookups. Tomorrow, the agent might reason that canceling an order, issuing a refund, or escalating to a supervisor’s queue is the right action.
Goal-directed behavior creates emergent permissions. Traditional authorization answers the question: “Is this identity allowed to call this API?” — Agentic authorization must answer: “Is this sequence of actions, emerging from the agent’s autonomous reasoning, within the bounds of what we intended to authorize?” A code review bot with repository read access seems harmless until it chains together legitimate capabilities to exfiltrate intellectual property to an external service it was also authorized to use for “code quality analysis”.
Dynamic tool access defies static policies. Plenty of agents have fixed, preconfigured tool registries — that part isn’t universal. But in MCP-style architectures, agents may reach tools through configured servers, and some deployments support dynamic discovery or runtime tool selection. In my post on MCP security, I described how Model Context Protocol (MCP) lets agents connect to external capabilities. Each enabled tool path can expand the effective privilege surface. Traditional IAM may still see OAuth grants, service principals, token issuance, and API calls. What it usually can’t tell you is why a tool was invoked, for which task, and under whose delegated authority — and that’s the gap that matters here.
Ephemeral lifecycles break audit trails. Agents may spin up in response to a user request, execute a multi-step workflow, and terminate. According to the Cloud Security Alliance’s Agentic AI Identity Management framework, this ephemerality requires Just-in-Time (JIT) provisioning and automatic credential expiration. But most organizations provision agent credentials at deployment time and never revisit them.
The OWASP Top 10 for Agentic Applications 2026 captures this problem as ASI03: Identity and Privilege Abuse. The description is telling: agents often inherit user or system identities with high-privilege credentials, session tokens, and delegated access. Those privileges get unintentionally reused, escalated, or passed across agents. In practice, an agent ends up sitting on top of multiple credentials, delegated sessions, tool permissions, and cached authorization context all at once — a pattern that maps closely to OWASP ASI03’s identity and privilege abuse risks.
The IAM blind spot in practice
This governance gap manifests in three common failure patterns that security professionals encounter repeatedly.
Hardcoded and over-scoped credentials
The fastest path to a working agent is giving it the same credentials the developer used during testing. In assessments, teams should look for production agents running with highly-privileged API keys, OAuth tokens from developer accounts, and service principals with subscription-wide permissions. The rationale is always the same: “We’ll scope it down later.”
Later never comes. The agent works, the team moves on, and the over-privileged credentials become part of the production architecture. Unlike a human user who might notice they have excessive access, the agent never complains. It simply has more capability than it needs, waiting to be exploited.
No ownership, no review cycles
Who owns the agent’s identity? The developer who created it? The team that operates it? The business unit that uses it? In most organizations, no one can answer this question clearly.
Traditional IAM programs include periodic access reviews where managers certify that their team members’ permissions are still appropriate. Service accounts get reviewed by the system owners who requested them. But agents fall into a governance void: they’re not human identities attached to a manager, and they’re not infrastructure identities attached to a system owner. They exist in a category that IAM programs don’t have a workflow for.
Without ownership, there’s no review. Without review, privilege accumulates.
Shadow agent proliferation
The barrier to deploying an AI agent has dropped dramatically. A developer can spin up an agent, connect it to internal systems using their own credentials, and have it running in production within hours. This is fantastic for innovation velocity. It’s terrible for identity governance.
These “shadow agents”, AI agents deployed outside formal IAM governance, typically using developer credentials or shared secrets, operate entirely outside IAM visibility. They don’t appear in identity inventories. Their credentials aren’t tracked. Their access isn’t reviewed. When security teams do discover them during assessments, they find credentials that violate every policy the organization has: shared secrets, no expiration, permissions far exceeding what the agent needs.
The problem compounds when shadow agents get promoted. An agent that started as a prototype, running on a developer’s laptop with the developer’s credentials, becomes a department resource, then an enterprise service. At each stage, the original credential arrangement persists because “it’s already working.”
How identity failures cascade across zones
In my post on threat modeling agentic AI, I described a five-zone lens for tracing how attacks propagate through agentic systems. Identity governance failures don’t stay contained to one zone. They create vulnerabilities that cascade across the entire architecture.
Zone 1 (Input Surfaces): Over-privileged agents can access more data sources than intended, expanding the attack surface for indirect prompt injection. If your agent has credentials to read emails, documents, and database records “just in case”, each of those becomes a potential injection vector.
Zone 2 (Planning and Reasoning): When agents inherit user identities, authorization is effectively delegated to the agent’s reasoning. Compromising that reasoning allows an attacker to operate with the full privileges of the user, similar to an insider attack.
Zone 3 (Tool Execution): This is where identity failures become directly exploitable. Every tool the agent invokes requires credentials. Hardcoded tokens, over-scoped permissions, and static credentials all concentrate risk at the tool execution layer. A single compromised agent becomes a gateway to every system it can authenticate to.
Zone 4 (Memory and State): Agents may cache credentials, tokens, or session information in memory. Memory poisoning attacks can target this cached identity context, attempting to manipulate what credentials the agent uses for subsequent operations.
Zone 5 (Inter-Agent Communication): In multi-agent architectures, identity can propagate across agent boundaries. If Agent A delegates a task to Agent B using its own credentials, any compromise of Agent A’s identity extends to Agent B’s actions. The OWASP Agentic guidance specifically warns about cross-agent delegation without proper scoping.
The architectural insight is that identity isn’t just about authentication at the perimeter. For agentic systems, identity governance affects security at every layer. A defense strategy focused only on input validation or output filtering is incomplete if the credential architecture remains over-privileged.
Defense-in-depth for agent credentials
Securing agent identities requires moving beyond the static credential models designed for traditional service accounts. The principles aren’t new, but applying them to autonomous, ephemeral, goal-directed systems demands new implementation patterns.
Short-lived credentials and just-in-time provisioning
The fundamental shift is from persistent credentials to ephemeral ones. Rather than provisioning an agent with a long-lived API key at deployment, the agent requests credentials when it needs them and those credentials expire shortly after use.
How far are most organizations from this? Public summaries of the SANS 2026 NHI Survey paint a bleak picture: 92% of organizations fail to rotate machine credentials even on a 90-day cycle, 59% rotate fewer than half their NHI credentials quarterly, and 15% don’t even know their rotation rate. If you can’t rotate a static credential every 90 days, you’re certainly not ready for ephemeral token architectures. But that’s exactly why starting this shift matters.
According to guidance from the Cloud Security Alliance on agentic IAM, identity systems should issue short-lived tokens that expire quickly, forcing revalidation at frequent intervals. If a credential is compromised, the blast radius is limited to the token’s validity window.
OAuth 2.0 Token Exchange and sender-constrained tokens like DPoP (Demonstrating Proof of Possession) are useful building blocks here, but they’re not magic. Token exchange lets you trade one security token for another, which fits delegation and impersonation patterns. DPoP binds a token’s use to proof of possession of a private key, which makes a stolen bearer token a lot less interesting to an attacker. To actually make tokens task-scoped and bound to a specific agent instance, your platform still has to do the unsexy work: issue per-task claims, use per-agent keys, protect those keys (secure key storage, workload attestation), and enforce policy at the resource server. None of that comes for free with the RFC.
In practice, a customer service agent might receive a token that allows read-only access to one customer’s order history for 15 minutes. When the interaction ends, so does the authorization. No persistent credential survives to be harvested. The hard part is operationalizing this at scale: traditional OAuth flows assume human users who can re-authenticate when tokens expire, while agents need automated renewal paths that don’t require a human in the loop and also don’t quietly create new persistent credentials.
Task-scoped permissions
Least privilege for agents means scoping permissions not just by identity, but by task. The same customer service agent should have different permissions when looking up an order versus when processing a refund versus when escalating to a supervisor.
This requires a shift from role-based access control (RBAC) to more dynamic authorization models. Policy-as-code frameworks like Open Policy Agent (OPA) can make authorization decisions based on structured, auditable runtime context: the requesting user, the agent instance, the declared task, the tool, the resource, data classification, approval state, and a signed delegation chain. What you do not want to do is base authorization on the model’s chain-of-thought. Reasoning traces are often unavailable, deliberately hidden, non-deterministic, or just unsafe to expose. Authorization decisions need to be deterministic and auditable, and “the model said it was fine” is neither.
The OWASP Agentic guidance introduces the “principle of least agency” — granting agents the minimum autonomy required to perform safe, bounded tasks. For identity, this translates to: grant the minimum credentials required for the specific action the agent is about to take, not the maximum credentials it might ever need.
Unique and verifiable agent identities
Replace shared credentials with unique, verifiable identities for each agent instance. This seems obvious but runs counter to how agents are often deployed: multiple instances sharing the same API key, or agents inheriting credentials from the user who invoked them.
Unique identities enable accountability. When an agent takes an action, you can trace it to a specific agent instance, not just “some agent using the customer-service key”. This is essential for forensics but also for behavioral monitoring: you can only detect anomalous agent behavior if you can distinguish one agent’s behavior from another’s.
SPIFFE (Secure Production Identity Framework For Everyone) is one strong workload-identity pattern for agent runtimes that live in modern infrastructure. In a SPIFFE/SPIRE-enabled environment, each agent workload can receive a short-lived, cryptographically verifiable identity document (SVID), which gets you out of the shared-static-secret business. Worth being honest about the scope: SPIFFE isn’t free or automatic. Your agent only gets an SVID if it’s deployed as a workload in a SPIFFE-enabled environment. But once you have it, combined with short-lived credentials, you end up with an architecture where every agent action is authenticated, authorized, and attributable.
Beyond credentials: behavioral identity
Even with perfect credential hygiene, a compromised agent using its legitimately issued, properly scoped credential is still a compromised agent. That’s why identity for agentic systems has to extend beyond authentication into continuous behavioral verification. Public reporting on the SANS 2026 survey shows that no single safeguard for AI-agent actions is used by more than about 40% of organizations, with nearly four in ten reporting human-in-the-loop approvals. This doesn’t necessarily mean the rest are unprotected—organizations typically rely on combinations of sandboxing, audit trails, scoped permissions, rate limits, and restricted tool access as compensating controls. But it does suggest that human approval is neither universally deployed nor scalable, which is why runtime behavioral monitoring and policy enforcement matter as an additional layer.
Behavioral identity treats the agent’s actions as part of its identity profile. An agent that typically makes 50 API calls per hour, accessing customer records during business hours, has a behavioral baseline. When that same agent suddenly makes 5,000 calls at 3 AM, accessing records it’s never touched before, the behavioral identity has changed even if the credential identity hasn’t.
This connects to the broader observability requirements for agentic systems. Every tool invocation, every reasoning step, every inter-agent communication should be logged with sufficient context to reconstruct the agent’s behavior after the fact. But behavioral identity goes further: it uses this observability data in real-time to continuously validate that the agent is still acting within expected parameters.
The technical implementation requires anomaly detection tuned to agent behavior patterns. Traditional user behavior analytics (UBA) assume human patterns: login times, geographic locations, typical applications. Agent behavior analytics must model different signals: reasoning chain length, tool selection patterns, data access sequences, and output characteristics.
Concrete anomalies to detect include: an agent that typically calls three tools per request suddenly chaining fifteen; an agent accessing credentials it has never used before; an agent whose reasoning traces include goal redirection language (“ignore previous instructions”); or an agent making outbound network calls to domains outside its normal operational pattern. When an agent starts defending beliefs it should never have learned, or accessing systems it has no task-based reason to use, the behavioral identity system should flag the deviation for investigation or automatic session termination.
I’ll cover the SOC-side of this — what to log, what to alert on, and incident response playbooks for goal hijacking, tool misuse, and memory poisoning — in depth in an upcoming post.
Where to start
If you’re wondering which controls to implement first, here’s a practical sequence based on effort and impact:
Week one: Inventory. You can’t govern what you don’t know exists. Scan for API keys in configuration management, pull your Google Workspace and Microsoft 365 consent logs for user-granted OAuth apps (AI productivity tools in particular — look for broad scopes and missing owners), and check cloud IAM for service principals created in the past year. The goal isn’t perfection — it’s visibility into what’s running.
Month one: Ownership assignment. For every agent you discover, assign an owner responsible for its identity lifecycle. This unblocks everything else: reviews, rotation, decommissioning. Without ownership, governance stalls.
Quarter one: Credential hygiene. Replace the worst offenders — hardcoded secrets, never-expiring tokens, over-privileged service principals. Implement short-lived credentials for new agent deployments even if you can’t retrofit existing ones immediately.
Quarter two and beyond: Task-scoped authorization and behavioral monitoring. These require more infrastructure investment but provide the deepest protection for agents handling sensitive operations.
Key takeaways
Inventory your agent identities now — including the ones your people signed themselves up for. If you don’t know which agents are running in your environment, with what credentials, talking to which systems, you have an unmanaged attack surface. Every third-party AI or OAuth app with delegated access into your Google Workspace or Microsoft 365 tenant is an application identity (an OAuth client, enterprise application, or consented integration) sitting inside your trust boundary, usually with scopes nobody reviewed and an owner nobody assigned. Treat it as NHI-adjacent at minimum: assign ownership, review scopes, monitor token use, and make revocation part of the lifecycle. Discovery comes before governance.
Treat agents as a distinct identity class. They’re not human users, and they’re not traditional service accounts. Your IAM program needs workflows specifically designed for autonomous, ephemeral, goal-directed identities.
Implement short-lived, task-scoped credentials. Replace persistent API keys with ephemeral tokens that expire quickly and are scoped to specific tasks. If an agent only needs read access to process one request, don’t give it a token that persists for days with write permissions.
Establish behavioral baselines. Credential-based authentication tells you who the agent is. Behavioral monitoring tells you whether it’s still acting as expected. Both are necessary for defense-in-depth.
Assign clear ownership. Every agent identity needs an owner responsible for access reviews, credential rotation, and decommissioning. If no one owns it, no one will govern it.
The governance gap isn’t a technical limitation. The patterns for securing agent identities exist. The gap is organizational: most enterprises haven’t yet recognized that agents require dedicated identity governance, distinct from both human IAM and traditional service account management. Closing that gap before the next major incident is the work ahead.
An unowned key is still a key. The lock can’t tell.