AI agent security: what IAM and DLP are missing

TL;DR: IAM and DLP can confirm an AI agent is authorised and inspect data movement, but Jozu argues they still miss whether the underlying model, prompt, or MCP toolchain is approved and whether a specific action is safe. The missing control is runtime enforcement over the agent’s actual behaviour, not just its identity or payload.

Editorial analysis by NHI Mgmt Group, based on content published by Jozu: “Why IAM and DLP Can’t Secure AI Agents”.

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.

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

A: AI agents can act, not just generate.

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.

Practitioner guidance

• 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.

Bottom line: 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.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →