Why IAM and DLP fall short for AI agent security

At a glance

What this is: This analysis argues that IAM and DLP are necessary but insufficient for AI agent security because they do not verify the approved artifact behind the identity or govern the agent’s actual actions at runtime.

Why it matters: It matters because IAM teams, PAM teams, and AI governance leads need controls that constrain tool use, delegation chains, and action-level policy for autonomous or semi-autonomous systems.

Context

The governance gap is not that AI agents lack identities. The problem is that existing identity and data controls assume the identity can be trusted once it is authenticated and the data can be judged by content patterns alone. That assumption breaks when an agent can choose tools, reshape data, and execute actions across multiple systems.

In this model, the security question moves from who authenticated to what was actually approved and whether the resulting action stayed within policy. The article frames that gap through AI agent identity, MCP toolchains, and runtime enforcement rather than through a classic human IAM workflow.

The practical issue for security teams is that role assignment and boundary inspection do not reveal whether the agent is still operating within the intended task. Treat AI agent authorisation as a separate governance problem from ordinary access grant logic.

Key questions

Q: What breaks when conventional IAM is used to control autonomous AI agents?

A: Conventional IAM breaks when it assumes a mostly human access model with slow approval cycles and static entitlement patterns. Autonomous agents can request, use, and propagate access too quickly for manual governance, which leaves gaps in scoping, monitoring, and revocation. The failure shows up as unmanaged delegated access and identities that exceed their intended authority.

Q: Why do AI agents create a different risk model than chatbots?

A: AI agents can act, not just generate. Once they can browse, retrieve, call tools, and complete tasks, the main risk shifts from unsafe output to unsafe action. That expands the attack surface from prompts to workflows, credentials, and downstream systems, which is why traditional model-only controls are no longer enough.

Q: How should teams detect abuse when an agent rewrites content before sending it out?

A: They should inspect prompts, completions, and tool arguments by meaning rather than relying only on pattern matching. Re-encoding or summarization can defeat pattern-based DLP while preserving the harmful intent. The right test is whether the action is allowed, not whether the payload still matches a known signature.

Q: What is the difference between identity verification and runtime authority for AI agents?

A: Identity verification establishes that the agent is legitimate and has an approved caller. Runtime authority determines whether a specific action should happen now, given the current task, content, and destination. For AI agents, the second question is often more important because intent can drift after authentication.

Technical breakdown

Why RBAC breaks down for AI agents

Role-based access control assumes a relatively stable actor whose work fits a bounded job function. AI agents do not behave that way because they are designed to cross functions, invoke tools, and complete multi-step work on demand. That means the role can remain valid while the operational intent behind it changes mid-task. The result is a mismatch between static authorisation and dynamic execution. In practice, the role becomes too broad to be safe or too narrow to be useful, and either way the control no longer describes the real decision the system is making.

Practical implication: Define access around task scope and per-action policy, not around a broad inherited role.

How supply chain tampering bypasses identity checks

Identity systems usually validate the credential, not the artifact that uses it. For AI agents, that distinction matters because the model, prompt, tool definition, or MCP server can change after authorization while the credential remains intact. This is why supply chain tampering is so effective against agentic systems: the identity provider still sees a legitimate principal, but the behavior now comes from a modified runtime component. The attack sits between authorization and execution, so conventional IAM has no visibility into the change. The control failure is not weak authentication. It is that trust was granted to an artifact that was never revalidated at runtime. See the Agentic AI Identity Guide.

Practical implication: Verify the model, prompt, and toolchain before execution and recheck them when the chain changes.

Why DLP misses the risky action

DLP is built to detect sensitive data crossing a monitored boundary, usually by pattern. AI agents create two problems for that model. First, many harmful actions are not data exfiltration at all, such as deleting records, placing transactions, or changing system state. Second, agents can rewrite or re-encode content so it no longer matches a known pattern, while still carrying the same risk. That means DLP can work exactly as designed and still miss the event that matters. In agentic workflows, the protected object is often the action itself, not the payload leaving the network. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Add semantic policy enforcement on tool calls and state-changing actions instead of relying on boundary inspection alone.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI agent into a legitimate-looking execution path for data theft, unauthorized action, or downstream system abuse.

1. Initial access begins when the attacker places malicious instructions or a compromised MCP server into the agent’s working path while the agent still appears properly authorised.
2. Credentialed execution continues because the agent inherits a valid role, so the system accepts the request even though the underlying toolchain or prompt has been altered.
3. Escalation occurs when the agent follows injected instructions or forwarded tool actions that expand beyond the original task boundary and reach data or systems the operator never intended to expose.
4. Impact lands when the agent exfiltrates data, changes state, or performs unauthorized transactions while IAM and DLP remain blind to the semantic abuse.

Breaches seen in the wild

• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
• 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.

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

RBAC is not a sufficient control model for AI agents: role-based access assumes stable job boundaries, but agents are valuable precisely because they cross those boundaries dynamically. That creates a structural mismatch between static permission grants and runtime task execution. The implication is that identity governance for agents must move from broad role assignment to action-scoped authority.

Artifact trust is now part of identity trust: an AI agent can remain the same authenticated principal while the model, prompt, or MCP server behind it changes. That means the security question is no longer only who holds the credential, but whether the executed artifact is still the one that was approved. The implication is that approval has to cover the running component, not just the account.

Semantic policy is the missing control plane: DLP sees patterns, not intent, and IAM sees identity, not action meaning. AI agents can therefore stay inside both controls while still doing the wrong thing. The implication is that enterprises need enforcement over tool calls, delegation chains, and state-changing actions, not just over content movement.

Vendor access without action verification is a governance blind spot: the article’s core gap is not that access is absent, but that access is granted without checking whether the resulting action is safe. That assumption was designed for systems where identity and behavior stay coupled, and it fails when an agent can rewrite the path between request and execution. The implication is that AI governance must treat execution-time judgment as part of access control.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• 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.
• Read next: AI Agent Authorisation Guide

What this signals

Access reviews were built for actors whose privileges persist long enough to be reviewed. AI agents collapse that assumption by acquiring and using access inside a task window, so governance has to move to issuance time and runtime policy rather than end-of-cycle certification.

Semantic access control: the control point shifts from whether a request is authenticated to whether the action is allowed by meaning. That matters because 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.

Organisations that treat AI agents as ordinary IAM principals will keep missing the behavior layer. The stronger operating model is to bind identity, verified artifact, and task-scoped policy into one decision loop, then preserve a cryptographic audit trail for every delegated hop.

For practitioners

• Separate identity approval from action approval Require a distinct policy decision for what the agent is allowed to do at runtime, not just for which role it can hold.
• Verify the artifact behind the credential Check that the model, prompt, skill, or MCP server running under the identity matches the approved version before execution begins.
• Constrain tool usage by task scope Limit which tools, datasets, and side effects an agent can reach in each session, especially when the work crosses multiple systems.
• Inspect semantic behavior, not just payloads Use runtime policy to evaluate prompts, completions, and tool arguments by meaning so rewritten content does not bypass content filters.
• Log delegation chains end to end Preserve attribution across agent, tool, and sub-agent hops so responders can reconstruct which component made each decision.

Key takeaways

• AI agent security is not solved by authenticating the principal alone, because the approved artifact and the executed action can diverge after access is granted.
• The article’s evidence shows that identity and DLP can both function correctly and still miss malicious behavior when the agent uses valid credentials through a compromised tool path.
• Runtime policy, artifact verification, and semantic inspection are the controls that change the outcome when agents can cross roles, reshape data, and act through MCP chains.

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Agentic AI Identity Guide · Agentic AI Security Guide · AI Agent Observability, Audit and Incident Response Guide

Key terms

• Action-Scoped Authorization: Action-scoped authorization means deciding permission at the moment a specific tool call or operation is attempted. For autonomous or agentic behaviour, this is more reliable than static identity-scoped access because the risk is tied to the current request, context, and intended side effect.
• Artifact Trust: Artifact trust is the decision to accept a component based on who published it, which version is running, and whether it has changed. It covers models, packages, servers, and other build artifacts. The control is necessary, but it does not by itself limit what the component can do at runtime.
• Semantic policy enforcement: Policy decisions based on the meaning of an action or message rather than only on patterns, signatures, or fixed strings. This matters for AI agents because rewritten content, delegated actions, and tool calls can bypass pattern-based controls while still carrying the same business risk.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or AI governance programme, it is worth exploring.