TL;DR: Prompt injection, unapproved tool use, and nondeterministic agent behaviour are forcing security teams to treat AI agents as active insider risks, not static software, according to Zenity. The governance gap is that runtime identity and approval boundaries now matter more than preconfigured controls.
NHIMG editorial — based on content published by Zenity: The League Assembled, reflections from the AI Agent Security Summit
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
Questions worth separating out
Q: How should security teams govern AI agents that can select tools at runtime?
A: Security teams should treat runtime tool selection as an access decision, not just a code-path decision.
Q: Why do AI agents complicate existing IAM and PAM models?
A: AI agents complicate IAM and PAM because their identity is not fully static during execution.
Q: What do security teams get wrong about prompt injection in agentic AI?
A: Teams often treat prompt injection as a content filter problem when it is really a runtime control problem.
Practitioner guidance
- Define runtime approval boundaries for new tools Require explicit approval before an agent can connect to a new MCP server, API, or external data source.
- Instrument agent behaviour as a security signal Track unusual data access, repeated destructive actions, and tool use that deviates from expected patterns.
- Separate instruction handling from execution trust Limit how agents render, parse, and act on untrusted content so hostile instructions cannot freely influence downstream actions.
What's in the full article
Zenity’s full article covers the operational detail this post intentionally leaves for the source:
- Session-level examples of how prompt manipulation turns trusted internal systems into risky actions
- Discussion of hard runtime boundaries for new tools and MCP servers
- Practical ideas for agent behaviour analytics and risk scoring
- The summit’s broader collaboration themes and speaker perspectives
👉 Read Zenity’s summit recap on AI agent security and runtime trust →
AI agent runtime boundaries: what security teams need to enforce?
Explore further
AI agent identity is becoming a governance category, not just a deployment label. The article shows why runtime decision-making changes the identity problem. When an agent can select tools, alter its path, and act without a fixed script, conventional application identity assumptions stop being enough. Practitioners should treat agent identity as a governed runtime relationship, not a static account inventory.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should be accountable when an AI agent causes a security incident?
A: Accountability should rest with the team that owns the agent, its approved tools, and its runtime controls. That ownership must include identity governance, monitoring, and incident response responsibilities. Without a named owner, agent behaviour becomes an operational blind spot rather than a managed risk.
👉 Read our full editorial: AI agent security now hinges on runtime boundaries and trust