AI agent security exposures expose identity gaps across OWASP maps

At a glance

What this is: Permiso maps 35+ AI agent security exposures across 10 categories and shows that the most severe risks sit where agent identity, access, tools, and data intersect.

Why it matters: IAM, NHI, and security teams need to treat AI agents as governed identities because overprivilege, tool misuse, and missing auditability create direct paths to compromise and exfiltration.

By the numbers:

• 35+ distinct AI security exposures across 10 categories.
• 11 exposures are classified as Critical severity.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Permiso Security's analysis of AI agent security exposures and OWASP mappings

Context

AI agent security is a governance problem before it is a detection problem. Once an agent can assume roles, call tools, and move between systems without fixed human pacing, the old assumption that identity is a stable, reviewable thing starts to fail.

This post is about how AI agents extend identity security into a new operating model for IAM, NHI, PAM, and lifecycle governance. The article's core claim is that the exposure surface is not just bigger, it is structurally different because agent actions, permissions, and outputs are tightly coupled.

Permiso's mapping is useful because it translates a broad AI agent risk discussion into identity-level exposures that practitioners can actually govern. The starting point is not typical optional hardening; it is now becoming the baseline expectation for any production AI agent programme.

Key questions

Q: How should security teams govern AI agents that can assume cloud roles and call tools?

A: Treat each agent as a governed identity with its own execution role, tool scopes, and data reach. Apply least privilege, task-bound access, and immutable logging before the agent is allowed into production. If the agent can change its own permissions or call peer agents freely, the governance model is already too loose.

Q: Why do AI agents create more identity risk than ordinary automation?

A: AI agents can choose actions at runtime, chain tools, and interact with other agents, which means access can expand during execution instead of staying fixed. Ordinary automation usually follows a predictable script. That difference makes overprivilege, tool misuse, and audit gaps more dangerous in agentic environments.

Q: What do security teams get wrong about AI agent access control?

A: They often protect the application and ignore the agent's own identity. The result is broad execution roles, weak policy boundaries, and poor visibility into what the agent actually did. Access control has to follow the agent's runtime behaviour, not just the service it sits inside.

Q: Who should own AI agent governance in the enterprise?

A: Ownership should sit jointly with identity, cloud, and platform security teams, because agent governance spans entitlements, tool policy, monitoring, and audit evidence. If ownership is scattered, gaps appear between model configuration, infrastructure permissions, and compliance controls, which is where real abuse happens.

Technical breakdown

Identity misconfiguration in AI agents

AI agents inherit identity through execution roles, service credentials, trust policies, and delegated permissions. When those identities are over-privileged, cross-account enabled, or left standing without JIT, the agent can act far beyond its intended purpose. This is an identity control issue, not just a model safety issue, because the agent’s runtime actions are limited or expanded by the permissions it receives. In practice, discovery, entitlement scoping, and auditability all have to be applied to the agent as an identity subject rather than to the application around it.

Practical implication: inventory agent identities separately from workloads and review every execution role for standing privilege and cross-account reach.

Tool misuse and agent-to-agent control gaps

Agentic systems become risky when they can invoke tools, chain actions, or communicate with other agents without clear constraints. Tool misuse covers unrestricted execution, overreach, and self-modification paths where the agent can extend its own capability set during runtime. Agent-to-agent gaps matter because one agent’s permissions can become another agent’s escalation path, especially when trust boundaries are implicit. This is where identity governance meets orchestration design: if tool access is broad and policy enforcement is weak, the agent can transition from assistance to autonomous impact very quickly.

Practical implication: bind each tool to explicit scopes, deny self-modification by default, and require policy checks before inter-agent calls.

Auditability and governance for autonomous agent activity

Audit controls for AI agents need to prove who acted, what was requested, which tool executed, and whether the action stayed inside policy. Missing prompt logs, incomplete decision logs, and the ability to disable logs create an evidence gap that breaks both investigation and assurance. Governance weaknesses also appear when model choice, ownership, and change management are not tracked, because the operator cannot show which version made which decision. For identity teams, the lesson is that observability is part of access control when the actor is an agent.

Practical implication: require immutable logging for prompts, decisions, tool calls, and model changes before agents touch production data or infrastructure.

Threat narrative

Attacker objective: The attacker wants to abuse the agent's trusted identity to move laterally, steal data, or trigger destructive actions without relying on direct compromise of a human user.

1. Entry begins when an AI agent receives a legitimate execution role and tool access in cloud or SaaS infrastructure.
2. Escalation occurs when overprivileged permissions, unrestricted tool execution, or agent self-modification expand what the agent can do beyond the original task.
3. Impact follows through data exfiltration, lateral movement, or destructive action executed through the agent's own identity and access paths.

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 security is identity security extended to a new class of identity. The article is right to frame every exposure through identity context because agent risk is created by execution roles, trust policies, and tool permissions, not by the model alone. That means the same governance discipline that applies to machine identities now has to absorb autonomous runtime behaviour, with NHI governance becoming the control plane for agentic systems.

Standing privilege without JIT is the clearest named failure mode in agent deployments. The article's exposure map shows that persistent access, overprivileged roles, and unrestricted tool execution are where the highest-severity risks concentrate. The practical implication is that agent programmes inherit the same blast-radius problem as service accounts, only with faster action chains and broader side effects.

Agent-to-agent security is no longer a niche concern once agents can chain decisions across environments. If one agent can call another without explicit policy boundaries, the trust model collapses from account-level governance into runtime delegation risk. That is why cross-identity visibility, not isolated agent monitoring, becomes the field's central requirement.

Compliance failures in AI agent programmes are usually evidence failures first. Missing prompt logs, incomplete decision trails, and the ability to disable logs mean the organisation cannot prove what the agent did or whether it stayed within policy. That makes auditability a control objective in its own right, not an afterthought bolted onto detection.

Identity blast radius is now a better design lens than model capability. The article's own severity breakdown shows that the most dangerous categories are the ones that connect identity, data, tools, and autonomy. Practitioners should evaluate whether their current controls can contain a bad agent decision before it becomes a multi-system event.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• A separate finding shows that systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, underscoring how sharply access scope changes risk.
• For a governance baseline, see OWASP Agentic AI Top 10 for the control areas practitioners should map against agent tool and identity exposure.

What this signals

Identity blast radius is becoming the practical measure of AI agent readiness. With 70% of organisations already granting AI systems more access than human employees per the 2026 Infrastructure Identity Survey, the governance gap is no longer hypothetical. Teams should expect entitlement review, policy enforcement, and audit evidence to become part of agent deployment gates, not post-deployment cleanup.

A useful way to organise the programme is to treat agent identity, tool policy, and logging as one control surface rather than three separate projects. That framing aligns with the OWASP Agentic AI Top 10 and helps security leaders spot where runtime authority exceeds intended scope.

Standing access debt: This is the accumulation of persistent AI privileges that were granted for convenience and never re-scoped for actual runtime need. Once agents can act faster than review cycles, the debt shows up as delayed detection, overbroad reach, and weak accountability across identity and platform teams.

For practitioners

• Inventory agent identities as first-class subjects Map every AI agent to the execution role, credentials, tool permissions, and data stores it can reach. Separate that inventory from application inventories so entitlement reviews can focus on the agent's actual blast radius.
• Eliminate standing privilege from agent workflows Replace persistent access with just-in-time grants tied to specific tasks and bounded scopes. Review cross-account access, self-modification rights, and default tool reach as part of the same entitlement check.
• Bind tools and agent-to-agent calls to explicit policy Require policy evaluation before an agent can invoke a new tool, call a peer agent, or expand its own permissions. Treat each tool boundary as an access control decision, not a developer convenience.
• Make prompt, decision, and model logging immutable Capture the prompt, the decision path, the tool call, and the model version in logs that the agent cannot disable. Use those records for investigation, audit, and change tracking across production environments.

Key takeaways

• The central risk is not that AI agents exist, but that many are being granted identity and tool access far beyond the level given to human peers.
• The highest exposures cluster around overprivileged execution roles, unrestricted tool use, and weak auditability, which makes agent governance an identity problem first.
• Security teams should rework agent programmes around blast-radius control, immutable evidence, and explicit policy boundaries before production scale makes the gap harder to close.

Key terms

• Agent Identity: An agent identity is the set of credentials, roles, trust policies, and permissions assigned to an AI agent so it can act in systems. Unlike a human identity, it may execute at machine speed and chain actions across tools, making scope control and audit evidence critical.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it is misused or compromised. For AI agents, it depends on role scope, tool reach, data access, and whether the agent can call other agents or modify its own permissions.
• Standing Privilege: Standing privilege is persistent access that remains available until someone removes it. In agentic environments, persistent permissions are especially risky because they let an agent operate continuously with more authority than the task requires, increasing the chance of lateral movement or destructive action.
• Agent-to-Agent Security: Agent-to-agent security is the control of how one AI agent trusts, calls, and exchanges data with another. It covers policy boundaries, identity verification, and logging between agents so that delegation does not become an unmonitored path to broader access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Permiso Security: Permiso Expands AI Agent Security Coverage with 35+ Exposures Mapped to Both OWASP Top 10 Frameworks. Read the original.