AI agent identity risk outpaces enterprise IAM controls at RSAC 2026

At a glance

What this is: This analysis argues that AI agent adoption is exposing a structural identity gap because existing IAM controls were built for human workflows, not autonomous software with tool access.

Why it matters: For IAM and NHI practitioners, the issue is that agentic systems inherit privileges, expand access paths, and move faster than manual governance can respond.

👉 Read Unosecur's analysis of AI agent identity risk at RSAC 2026

Context

AI agent identity is now a governance problem, not just an application design choice. When autonomous tools can query data, call APIs, and act across enterprise systems, the controlling question becomes whether identity, access, and runtime policy can keep pace with what those agents actually do.

The RSAC 2026 context in the source article shows a familiar pattern: new capability arrives faster than security ownership. That makes NHI governance central, because the same inventory, privilege, rotation, and offboarding gaps that affect service accounts also affect AI agents and their connected tools.

Key questions

Q: How should security teams govern AI agents that act like non-human identities?

A: Security teams should govern AI agents as non-human identities with ownership, lifecycle controls, and least-privilege boundaries. That means inventorying each agent, tying it to a business task, limiting the permissions it inherits, and revoking access when the task ends. Agent governance fails when teams treat agents as disposable application features instead of managed identities.

Q: What is the difference between JIT access and least privilege for AI agents?

A: Least privilege defines the minimum access an agent should have. JIT access controls when that access exists. For AI agents, both are necessary because persistent access widens exposure while overbroad permissions increase blast radius. The best practice is to combine narrow entitlements with automatic issuance and revocation for each task.

Q: Why do AI agents create a bigger IAM problem than normal service accounts?

A: AI agents create a bigger IAM problem because they are dynamic, context-driven, and able to call tools in ways that change over time. A service account usually performs a known set of actions, but an agent can pivot across repositories, APIs, and SaaS systems as its context changes. That makes governance depend on runtime visibility, not just static identity records.

Q: What is the difference between MCP governance and API security?

A: API security focuses on protecting endpoints and the data they expose. MCP governance focuses on the identity and authorization layer that lets an agent use those endpoints in the first place. In AI environments, that difference matters because the risk is not only the API itself, but the agent’s ability to chain multiple tool calls with inherited privileges.

Technical breakdown

Why Model Context Protocol changes the identity problem

Model Context Protocol, or MCP, is the runtime integration layer that lets an AI agent connect to tools, data sources, and enterprise systems. In practice, that means the agent is not just generating text, it is invoking privileged actions through authenticated connections. The security issue is that every MCP-backed tool call carries an access decision, even when no one consciously reviewed it. If the underlying identity is overprivileged, the agent inherits that blast radius immediately. If the environment cannot map which agent touched which resource, post-event analysis becomes guesswork. Practical implication: treat MCP connections as governed identity paths, not convenience integrations.

Practical implication: Inventory MCP-connected services and require explicit authorization, logging, and review for every agent-to-tool path.

Why unified identity fabrics matter for AI agents and NHIs

The article’s core architectural point is that access, visibility, and remediation all depend on a single identity layer. When humans, service accounts, API keys, and AI agents are managed in separate systems, no control plane has the full picture needed to enforce least privilege or to make runtime decisions. Fragmentation also breaks context, because anomaly detection cannot distinguish normal agent behavior from abuse without a baseline tied to identity and task scope. A unified identity fabric does not remove risk by itself, but it makes governance enforceable across clouds, SaaS, and on-prem environments. Practical implication: collapse identity oversight into one control model instead of stacking disconnected tools.

Practical implication: Build one identity inventory and policy model that spans human and non-human identities across all environments.

How just-in-time access differs from static permissions for agents

Just-in-time access is a provisioning pattern, not a full governance model. For AI agents, it matters because persistent credentials create long-lived exposure while task-scoped access reduces the time window in which misuse can occur. But JIT only works when the identity layer can issue, bind, and revoke access automatically at machine speed. Human approval queues do not scale to thousands of parallel agent actions. The deeper issue is that many environments still assign access by default through inherited permissions, which defeats the purpose of ephemeral access. Practical implication: pair JIT with task scoping, automated revocation, and runtime enforcement.

Practical implication: Use JIT for agents only when access can be issued and removed automatically without manual bottlenecks.

Threat narrative

Attacker objective: The objective is to exploit unmanaged agent access paths to reach data, systems, or credentials at machine speed without triggering effective identity controls.

1. Entry occurs when a developer tool, embedded SaaS agent, or custom MCP-connected workflow is granted access through an existing service account or API key.
2. Escalation follows when the agent inherits broader permissions than the task requires, allowing it to query repositories, databases, or internal APIs beyond intended scope.
3. Impact comes from ungoverned runtime actions that expose code, secrets, or infrastructure context before security teams can see or stop the activity.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity is becoming the newest layer of NHI sprawl. The source article shows that agentic systems are entering the enterprise through developer tools, SaaS features, and custom workflows faster than security teams can classify them. That is not a niche implementation issue, it is a governance shift that expands the non-human identity population and makes inventory, ownership, and access review non-optional. Practitioners should treat every agent as an identity object with lifecycle obligations.

Identity blast radius is now the controlling risk metric for agentic systems. When an agent inherits permissions from a service account, app integration, or SaaS platform, the real question is not whether the agent is clever, but how far it can move if misused. Overprivilege, weak scoping, and missing revocation controls turn small integration mistakes into broad exposure. The practical conclusion is straightforward: reduce blast radius before scaling agent adoption.

Model Context Protocol creates a runtime governance gap that most IAM stacks do not cover. MCP makes agent-to-tool connectivity functional, but it also creates a path where access decisions are executed continuously outside traditional human approval flows. That shifts the center of gravity from authentication alone to authorization, logging, and policy enforcement at the moment of action. Teams need to govern the integration layer, not just the agent account.

Separate control planes for humans, NHIs, and AI agents will keep producing blind spots. The article’s strongest architectural point is that fragmented tooling cannot supply the context needed for least privilege, anomaly detection, and automated remediation. Security teams should assume that split inventories and split policy engines will lag behind agent adoption. A single identity fabric is the only defensible operating model.

AI governance will converge with NHI governance faster than many programmes expect. The same lifecycle controls that matter for service accounts, API keys, and certificates now apply to autonomous software with tool access. That means onboarding, entitlement review, rotation, and offboarding are no longer separate programmes. Practitioners should align agent governance with existing NHI controls rather than building a parallel exception process.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Use 52 NHI Breaches Analysis to trace how overprivileged identities and slow revocation turn exposure into breach paths.

What this signals

Identity blast radius is the right programme-level lens for AI agents because the operational risk is no longer only discovery, it is how far an unmanaged identity can move once it exists. Teams that already struggle with service account ownership should expect agent governance to stress the same weak points in inventory, privilege review, and revocation.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations such as code, config files, and CI/CD tools, the governance problem is already larger than most teams estimate, according to Ultimate Guide to NHIs. AI agents will amplify that exposure unless identity programmes enforce one control model across human and non-human access paths.

The practical next step is to align AI agent oversight with established identity controls, then extend those controls to runtime behaviour. That means preparing policy, logging, and revocation workflows now, while also grounding the programme in external frameworks such as the NIST Cybersecurity Framework 2.0.

For practitioners

• Create a single inventory for agents and NHIs Map AI agents, service accounts, API keys, OAuth tokens, and certificates into one inventory with clear ownership and task scope. Without that baseline, you cannot enforce access review or detect unmanaged agent growth.
• Require runtime policy for every agent-to-tool connection Treat MCP-connected workflows, SaaS embeddings, and custom integrations as governed access paths. Log who or what connected, what data was touched, and what action was taken, then review those paths on a fixed schedule.
• Enforce task-scoped JIT access with automatic revocation Issue access only for the duration of a specific job, then revoke it immediately after completion. Use automation so the process does not depend on manual approvals that cannot keep up with machine-speed activity.
• Prioritise blast-radius reduction before scaling adoption Reduce inherited privileges, separate high-risk credentials, and block broad default access in developer tools and SaaS agents. The goal is to limit the damage from one compromised agent rather than trying to inspect everything after the fact.

Key takeaways

• AI agents are widening the NHI governance problem because they arrive through multiple entry points and inherit access by default.
• Identity fragmentation is the core issue, since access, visibility, and remediation all fail when humans, NHIs, and agents are managed separately.
• Practitioners should reduce blast radius, enforce runtime policy, and treat agent governance as an extension of NHI lifecycle control.

Key terms

• Non-Human Identity: A non-human identity is any machine, workload, service account, token, certificate, or autonomous agent that authenticates to systems and performs actions. In practice, it is an identity object that must be inventoried, scoped, monitored, and revoked just like a human account, but at machine speed and scale.
• Model Context Protocol: Model Context Protocol is the runtime integration layer that allows an AI agent to connect to tools, data sources, and enterprise services. It matters for security because it turns agent reasoning into real access, which means every connection creates an authorization and logging requirement, not just a technical integration.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised identity can cause based on its privileges, reach, and connected systems. For NHIs and AI agents, it is a practical measure of how much exposure exists when permissions are inherited, overbroad, or slow to revoke.
• Task-scoped Access: Task-scoped access limits permissions to a specific job, workflow, or time window instead of leaving them permanently available. For autonomous systems, it is one of the most effective ways to reduce standing exposure, but it only works when issuance and revocation are automated and tied to identity context.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Detailed examples of how AI coding tools, embedded SaaS agents, and custom workflows expand the NHI population.
• The article’s own walkthrough of how MCP-backed agent connections create implicit privilege decisions.
• Practical sequencing for discovery, runtime access control, and contextual remediation across mixed environments.
• The source discussion of why identity tooling gaps become visible first in access, then in visibility, then in response.

👉 Unosecur's full post covers the access, visibility, and remediation gap behind agentic identity risk.

Deepen your knowledge

AI agent identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous tools, this is the right place to start.