AI agent security gaps are widening across enterprise identity controls

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WitnessAI's blog post: AI agent security is becoming an identity problem, with prompt injection, overprivileged APIs, weak token validation, and dependency risk all widening the attack surface.

Why it matters: It matters because IAM, PAM, and governance teams now have to control runtime decisions, delegated access, and downstream actions for AI agents, not just authenticate users or provision service accounts.

Context

AI agent security is the set of controls used to protect autonomous or semi-autonomous systems that make decisions, call tools, and interact with enterprise systems. The primary gap is not model output quality alone, but the way identity, access, and trust assumptions fail when agents can act across APIs and workflows.

WitnessAI argues that these systems widen the attack surface because they combine dynamic inputs, chained actions, and dependency sprawl. For IAM and governance teams, the issue is whether existing access controls can still define and enforce scope when action selection happens at runtime.

The article also treats agentic AI as an identity governance problem, not only an application security problem. That makes it relevant to NHI, AI agent authorisation, and runtime control design, especially where assistants can move from suggestion to execution without a human approval gate.

Key questions

Q: What breaks when AI pentesting agents are allowed to act without approval gates?

A: The main failure is blast-radius expansion. An agent that can discover a viable exploit path may also execute it, turning validation into unintended disruption or data exposure. Without approval gates, the organisation loses the boundary between finding risk and creating it, which is especially dangerous in production environments where testing and impact can converge quickly.

Q: Why do overprivileged API keys create more risk in agentic AI systems?

A: Because the key becomes the real enforcement point for everything the agent can do. If scope is too broad, one manipulated prompt can trigger actions across multiple systems, and the resulting damage depends on what the credential can reach rather than what the model intended.

Q: How do security teams know whether an AI agent control stack is actually working?

A: Look for three things: every agent has a traceable identity, permissions are narrow enough to explain in operational terms, and actions can be audited end to end. If any of those are missing, the control stack is incomplete even if the data layer uses advanced privacy techniques. Identity, scope, and logging should all line up.

Q: What is the difference between sandboxing AI agents and validating their runtime actions?

A: Sandboxing limits where an agent can operate, while runtime validation decides whether a specific action should be allowed to proceed. Both matter, but sandboxing contains the blast radius and validation stops the wrong action before it reaches production systems.

Technical breakdown

Why prompt injection changes the trust boundary for AI agents

Prompt injection works because AI agents consume untrusted content as if it were operationally relevant context. In agentic systems, that can influence not only a response but also a tool call, a workflow transition, or a downstream API action. Indirect prompt injection is more dangerous because the malicious instruction can arrive through documents, web pages, tickets, or other external data sources. The core technical problem is that the model and orchestration layer may not distinguish between legitimate task context and attacker-supplied instructions unless validation is explicit and separate from generation.

Practical implication: treat all external content as untrusted input before it can influence tool execution or delegated access.

How overprivileged APIs turn agent decisions into identity risk

AI agents often operate through API keys, tokens, and delegated permissions that were provisioned before runtime intent was known. If those permissions are broad, an attacker only needs to influence the agent once to trigger actions well beyond the original task. The risk is compounded when identity propagation is weak, because one compromised session can travel across multiple systems with insufficient scoping or validation. This is the point where AI security becomes NHI security: the credential, not the model, becomes the enforcement point for scope.

Practical implication: bind each agent action to narrowly scoped credentials and verify that token scope matches the task actually being executed.

Why runtime monitoring matters more than static testing for agentic AI

Static testing cannot fully describe how an AI agent behaves under changing prompts, memory, and tool availability. Runtime monitoring is therefore central because the security question is not only what the agent can do in theory, but what it actually does after context changes mid-session. Sandboxing, deterministic validation, and action logging reduce the chance that a compromised prompt becomes a live enterprise action. Without those controls, jailbreaks, memory poisoning, and dependency issues can cascade into unauthorized transactions, data leakage, or code execution.

Practical implication: instrument agent runtime behaviour, not just model prompts, and block any action that has not passed live validation.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent security now sits at the intersection of identity, workflow control, and runtime trust. The article shows that the real exposure is not just model misuse, but delegated access that can be exercised inside live enterprise processes. That shifts the problem from content moderation to identity governance for systems that can act without a human in the loop.

Access review processes assume privilege is stable long enough to be reviewed, but agentic behaviour breaks that assumption. When an agent can request, combine, and spend access within a single task, the governance artefact may never exist long enough to be certified. The implication is that practitioners must stop treating runtime access as static entitlement and start treating it as event-scoped authority.

Ephemeral credential trust debt is becoming the right way to describe this category of risk. Scoped tokens and temporary keys reduce exposure only if they are validated continuously and tied to the exact action boundary. The moment agents can chain actions across systems, short-lived access no longer guarantees short-lived impact, which makes issuance-time controls as important as revocation.

AI agent security cannot be solved by application guardrails alone because the supply chain now extends into identity decisions. Open-source frameworks, third-party APIs, and plugin ecosystems create control points that influence what an agent can access and when. That means the governance model has to cover dependencies, runtime permissions, and trust propagation together, not as separate security domains.

For IAM and PAM teams, the practical unit of control is moving from the account to the action. The article’s core lesson is that enterprise identity programmes must govern what an agent can do at the moment it acts, not just what it was allowed to possess at provisioning time. That is the operational boundary practitioners now have to defend.

From our research library:

• 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
• Read next: Agentic AI Identity Guide

What this signals

Agentic AI identity is forcing IAM teams to move from entitlement governance to action governance. Access controls designed for stable human or service identities do not fully describe systems that can select tools, sequence actions, and change context mid-session. The practical shift is to govern what the agent is allowed to do at execution time, not just what it can authenticate with.

69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey. That matters because runtime decisions and delegated access are now part of the identity perimeter, not just application behaviour.

Ephemeral credential trust debt: short-lived tokens reduce exposure windows only when they are continuously validated against the exact task boundary they were issued for. Once agents can chain actions across APIs, expiry alone does not prevent harmful execution inside the session.

For practitioners

• Define agent-specific access scopes Create separate scopes for each AI agent, workflow, and environment so that a single compromised prompt cannot inherit broad enterprise reach.
• Validate every external input before execution Treat documents, web content, tickets, and user prompts as untrusted until sanitised and checked for instructions that could alter tool use or downstream actions.
• Instrument runtime behaviour and action logs Record tool calls, token use, memory changes, and policy decisions so anomalous behaviour can be detected before it becomes a transaction or code execution.
• Isolate high-risk agents in sandboxed environments Prevent direct file-system, network, or production-system access unless the agent action has been explicitly validated in a constrained runtime boundary.
• Review third-party dependencies as trust inputs Track open-source frameworks, plugins, and external APIs as part of the identity surface because each dependency can widen what the agent can reach or influence.

Key takeaways

• AI agent security is now an identity governance issue because delegated runtime access can outlive the assumptions behind static approval models.
• The source article highlights prompt injection, overprivileged API keys, weak token validation, and dependency risk as the main exposure paths.
• Practitioners should move control points to issuance time, runtime validation, and action logging so that agent behaviour is constrained before it can affect production systems.

Key terms

• Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority, API access, file writes, workflow triggers, the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Runtime validation: A control practice that tests how an AI system behaves while it is connected to real tools and data, rather than only reviewing configuration or design documents. It matters because agentic systems can appear safe on paper and still fail when prompted, chained, or given access to connected services.
• Identity propagation: The preservation of origin and acting principal information as a request moves through multiple services. In MCP chains, this is what allows downstream systems to make a trustworthy authorization decision instead of relying on a stripped-down token with no task context.

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 building or maturing an IAM programme, it is worth exploring.