Here's a question I've been asking security teams for the past year: when your AI agent takes an action, what actually checked that the action was safe?
The honest answer, in most organizations, is nothing. Identity and access management (IAM) confirmed the agent held a valid role. Data loss prevention (DLP) watched the network boundary for recognizable sensitive data. Both controls did their jobs. Neither one looked at what the agent was actually doing.
That gap isn't theoretical. Attackers have already exploited it in production. A malicious MCP server on npm used valid credentials to quietly exfiltrate data. A public GitHub issue tricked GitHub Copilot into following instructions its operators never wrote. In both cases, identity and DLP controls were present, working as designed, and blind to the attack.
I want to be clear up front: this isn't an argument against IAM or DLP. Both are necessary. They're just insufficient for AI agent security, and the reasons why tell you a lot about what the missing layer needs to look like.
Why IAM falls short for AI agents
Role-based access control (RBAC), the backbone of most IAM programs, assumes each identity holds a specific, consistent role. A person in the finance role does finance things. That assumption made role boundaries a sensible security control for decades.
AI agents break the assumption on day one, because agents are useful precisely for crossing roles. An agent completes in hours what would take human teams weeks of handoffs. The role that was a reasonable boundary for one person becomes far too broad the moment a non-human identity inherits it.
The problems compound from there.
A role grants access regardless of the artifact behind it. IAM checks the role. It doesn't check the model, the prompt, or the MCP toolchain running under that role. AI supply chain tampering happens between authorization and execution, so the credential stays valid even after the artifact changes. This is exactly how malicious MCP servers have exfiltrated data with credentials that were, technically, legitimate.
A valid role is no defense against prompt injection. A credentialed agent will follow instructions an attacker hides in retrieved content, a tool description, or an MCP response. The identity provider sees nothing wrong, because nothing about the role changed. The agent is still who it says it is. It's just no longer doing what you asked.
RBAC forces a bad tradeoff between over-broad roles and approval fatigue. You can't scope an open-ended agent task to a role in advance. Grant a broad role and you've created standing privilege wider than any single task needs. Grant a narrow role with per-request human approval and the reviewer clicks yes reflexively within a week, because the agent asks constantly. Neither option is a control. One is exposure and the other is theater.
Roles lose authority across delegation chains. When an agent calls a tool that calls a sub-agent that calls an MCP server, the role gets inherited down the chain and the record of who acted on whose behalf degrades at every hop. By the third hop, "authorized" doesn't mean much.
Where DLP fails for AI agents
Data loss prevention has a parallel problem. DLP catches recognizable sensitive data crossing a monitored boundary. That's a real and useful function. But agents routinely need to send email and move data across that boundary as part of their job, and DLP has no way to tell a safe action from an unsafe one.
Three DLP gaps matter most for agentic AI:
DLP misses actions entirely. Deleting records, reconfiguring a system, issuing a transaction, or spending money through a tool call are not data-egress events. DLP never sees them. Yet these are exactly the actions that make agents both valuable and dangerous.
DLP matches patterns, and agents rewrite content. An agent can summarize, translate, or re-encode sensitive material until it no longer matches anything a DLP rule recognizes. It can embed a credential in the body of an outbound API call that reads as ordinary traffic. Pattern matching was built for data that stays in one shape. Agents exist to change the shape of data.
DLP inspection points often aren't in the agent's path. Agent-to-tool and agent-to-MCP traffic frequently never crosses the chokepoint where DLP inspects. At the edge, on disconnected networks, or in air-gapped environments, that chokepoint may not exist at all.
AI agent security: the missing enforcement layer
If IAM answers "who is acting" and DLP answers "what data crossed the boundary," the missing layer answers two different questions: was the artifact behind this identity actually approved, and is this specific action within policy?
That's what we built Jozu to do, and it works alongside your existing IAM and DLP stack rather than replacing either.
Before an agent or model runs, Jozu Hub verifies the artifact is what it claims to be. Every model, agent, skill, and MCP server gets signed and scanned across nine AI-specific vulnerability classes, and distribution is gated on signature, scan results, license, and provenance. A role then grants access only to verified artifacts. This is the signing and provenance control the NSA's Artificial Intelligence Security Center has been recommending since 2024.
While the agent runs, Jozu Agent Guard enforces policy at the semantic layer. Micro-VM isolation limits the blast radius of a hijacked agent. Tool usage policy constrains what it can do and which data it can reach, re-evaluated at every invocation in a delegation chain rather than trusting an inherited role. The routine decisions get made deterministically in policy, so human approval is reserved for the infrequent high-risk actions where a human's attention actually means something. The Jozu AI Gateway inspects prompts, completions, and tool arguments by meaning, not pattern, which is how you catch the sensitive content an agent has already rewritten.
And afterward, one cryptographically chained audit log ties each action to the artifact that produced it and the approval that authorized it. When an incident happens, or a regulator asks, you have the record.
Governing AI agents without a cloud dependency
We built Jozu from the start to run where a cloud control plane can't reach: on-premises, at the edge, and in disconnected, degraded, intermittent, and limited-bandwidth conditions. Agent Guard enforces policy locally in the runtime with no phone-home dependency, and audit logs sync when connectivity returns. The whole system installs into a private Kubernetes cluster the customer owns. No data touches Jozu.
Policies are plain YAML with CEL syntax, and they layer from general to specific: a small set of organization-wide rules, then department policies, then mission or team policies. A later layer can only add constraints, never relax earlier ones. In practice the best pattern is to keep the top layer small and put the tightest controls closest to the people who understand the work.
For federal teams: Jozu is awardable on the DoD Tradewinds and Platform One marketplaces and deploys into a customer's already-accredited IL5/IL6 enclave.
Frequently asked questions
Can IAM secure AI agents?
IAM can authenticate an agent and grant it a role, but it cannot verify that the model, prompt, or MCP toolchain behind the credential matches what was approved, and it cannot constrain what a credentialed agent does with its access. IAM remains necessary for agent identity. It needs a runtime enforcement layer alongside it.
Does DLP work for AI agents?
Only partially. DLP detects known sensitive data patterns crossing monitored boundaries. It misses agent actions like tool calls and transactions, misses content the agent has rewritten or re-encoded, and often isn't positioned in the agent-to-tool traffic path at all.
What replaces IAM and DLP for agentic AI?
Nothing replaces them. AI agent security adds two controls they were never designed to provide: AI supply chain verification that the running artifact is the approved artifact, and runtime policy enforcement over the agent's actual tool calls, data access, and spending.
The bottom line
The frameworks are converging on the same conclusion. NSA guidance calls for signed artifacts, provenance tracking, and trusted execution environments for AI workloads. NIST's adversarial machine learning taxonomy catalogs threats that originate in the AI supply chain and are invisible to identity and data-egress controls. The OWASP Top 10 for Agentic Applications names identity and privilege abuse, tool misuse, goal hijacking, and agentic supply chain compromise as core risks.
None of those are things your IAM or DLP tools were built to see. Keep both. Then add the layer that verifies what's actually running and governs what it actually does.
Jozu is the AI Assurance Platform for enterprises, regulated industries, and governments deploying models, agents, and MCP servers. Learn more at jozu.com.