AI agent governance: what IAM, DLP and gateways miss

TL;DR: IAM, DLP and API gateways each cover part of the stack, but none can govern AI agents because agents are non-deterministic, invoke tools outside HTTP, and can be swapped or tampered with after authorization, according to Jozu. The control problem is not more perimeter inspection, but a governance layer that verifies the running artifact, tool calls and audit evidence at execution time.

Editorial analysis by NHI Mgmt Group, based on content published by Jozu: “AI Agent Governance vs IAM vs DLP vs API Gateways: What Each One Actually Covers”.

Key questions

Q: What breaks when organisations try to govern GenAI with classic DLP alone?

A: Classic DLP usually watches files and email, not live prompts and model responses.

Q: Why do AI agents create risk even when they stay within approved permissions?

A: AI agents can be authorised correctly and still produce harmful outcomes because permission is not the same as intent or behavioural appropriateness.

Q: How can organisations tell whether AI agent governance is actually working?

A: Look for evidence that agent access is ephemeral, traceable, and constrained at the action level.

Practitioner guidance

• Separate identity issuance from agent governance Keep IAM responsible for human and service credentials, but define a distinct control set for agent artefacts, tool permissions and runtime approvals.
• Inventory every agent execution path Map which actions happen through HTTP, which happen over MCP or stdio, and which never touch a gateway so the governance gap is visible.
• Require verified artefact provenance Approve only signed, traceable agent builds and reject runtime execution when the artefact cannot be matched to the approved registry.

Bottom line: Existing identity, data and gateway controls do not govern AI agents end to end because they cannot see the full runtime decision path.

Explore further

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