TL;DR: Zero-trust AI governance treats models and autonomous agents as identities that must be verified at runtime, because packet filtering and keyword-based controls miss prompts, tool calls, and delegated actions, according to WitnessAI. The control problem is not visibility alone but proving who authorized each interaction before AI decisions create operational risk.
NHIMG editorial — based on content published by WitnessAI: zero-trust AI governance for AI systems, agents, and enterprise control
By the numbers:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
Questions worth separating out
Q: How should security teams govern AI agents that call APIs instead of using a UI?
A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login.
Q: Why do existing IAM and DLP controls fall short for AI usage?
A: Existing IAM and DLP controls often assume the risky action can be reviewed after the fact, but AI exposure happens during the session.
Q: What breaks when AI access is managed like normal application access?
A: Normal application access assumes stable ownership, predictable usage, and clear review cycles.
Practitioner guidance
- Define AI interactions as governable identity events Classify prompts, tool calls, model outputs, and agent actions as audit-worthy identity activity.
- Scope permissions by AI task and tool path Review which models, agents, and MCP-connected workflows can read, write, or execute across systems.
- Insert pre-execution checkpoints for high-risk actions Require approval or policy evaluation before AI systems can send data externally, modify records, or trigger downstream workflows.
What's in the full article
WitnessAI's full article covers the operational detail this post intentionally leaves for the source:
- How the platform classifies intent across prompts, responses, and tool calls in real enterprise traffic
- Examples of runtime policy decisions such as warn, redact, route, and block for different AI use cases
- The vendor's discussion of how audit trails support approvals, exceptions, and investigations across AI workflows
- Operational examples of how discovery, guardrails, and runtime enforcement are combined across employee and agent activity
👉 Read WitnessAI's analysis of zero-trust AI governance and runtime controls →
Zero-trust AI governance for agents: what IAM teams need now?
Explore further
Zero-trust AI governance is now an identity problem, not just a model-safety problem. The article makes clear that risk emerges at the interaction layer, where prompts, tool calls, and delegated actions carry authority. That means IAM and NHI teams have to govern AI as a runtime identity surface, not as a static application feature. The practical conclusion is that AI must inherit the same control discipline as other non-human identities, but with interaction-level evidence attached.
A few things that frame the scale:
- 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.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who is accountable when an AI system moves data outside policy?
A: Accountability should sit with the team that owns the AI workflow, the data it touches, and the credentials that enable it. If governance stops at authentication, ownership becomes blurred. Clear accountability means mapping the data path, the action scope, and the approving function before deployment.
👉 Read our full editorial: Zero-trust AI governance is the missing control layer for agents