Topic starter
25/10/2026 11:09 am
TL;DR: AI agent security still fails when approved access and approved behaviour diverge, Jozu says, because identity and DLP can both work while a compromised tool path carries out a harmful action. Runtime controls must judge the agent's action, not just its login 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: 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.
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.
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.
Glossary terms: Action-Scoped Authorization, Artifact Trust, Semantic policy enforcement, Delegation Chain
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:17 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Why IAM and DLP fall short for AI agent security
This post was modified 7 days ago by NHI Mgmt Group