TL;DR: AI agents extend familiar security problems into a new execution context: they reason, retrieve knowledge, call tools, and take actions that traditional controls cannot fully observe, according to Zenity. The governance gap is not that security must be reinvented, but that existing identity and runtime controls must be extended to cover agent behaviour, tool use, and auditability.
NHIMG editorial — based on content published by Zenity: Demystifying AI Agent Security
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern AI agents that can call enterprise tools?
A: Security teams should govern AI agents the same way they govern sensitive non-human identities, but with added runtime visibility.
Q: Why do AI agents create more risk than ordinary automation?
A: AI agents create more risk because they can reason, retrieve context, choose tools, and execute actions dynamically.
Q: What breaks when AI agent activity is not logged end to end?
A: End-to-end logging is what lets teams reconstruct trigger, retrieval, tool use, and action.
Practitioner guidance
- Inventory every agent trigger and tool path Document which prompts, webhooks, schedules, and inter-agent messages can start work, then list the tools each agent can call and the actions each tool can perform.
- Separate model safety from enterprise authorization Use model controls for unsafe content reduction, but rely on enterprise identity, entitlement, and policy controls for tool access and write permissions.
- Require activity-path audit logs Capture trigger, retrieval, tool invocation, and final action in one trace so responders can reconstruct how the agent reached a decision.
What's in the full article
Zenity's full blog post covers the operational detail this post intentionally leaves for the source:
- A clearer breakdown of the three agent deployment shapes and how each changes governance responsibility.
- Examples of build-time and runtime control patterns for SaaS-managed, home-grown, and device-based agents.
- A practical checklist for evaluating whether a control plane can see the full activity path.
- The article's own comparison of model-based, I/O-based, and agent-centric security approaches.
👉 Read Zenity’s analysis of AI agent security and governance →
AI agent security and governance: where do existing controls fall short?
Explore further
AI agent security is a non-human identity problem before it is an AI problem. The article correctly shows that agents touch sensitive systems, invoke tools, and produce actions that create real enterprise risk. That makes identity, entitlement scope, and auditability the governing questions, not model sophistication. The practical conclusion is that agent governance belongs inside identity and access programmes, not beside them.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- Only 44% have implemented any policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
A question worth separating out:
Q: Who should own AI agent governance in an organisation?
A: AI agent governance should sit with identity, security architecture, and risk owners together, because the controls span identity, telemetry, policy, and operational response. If ownership sits only in AI engineering, the programme usually misses entitlement design and audit requirements. If it sits only in IAM, it usually misses runtime behaviour.
👉 Read our full editorial: AI agent security needs runtime visibility, not new security models