Notifications
Clear all
Topic starter
12/06/2026 9:58 pm
TL;DR: Enterprises are moving past prompt filtering toward runtime governance because agents reason, decide, and act inside connected business systems, not just at the input layer, according to Zenity. That shift matters because current security programmes were built for static controls, while autonomous behaviour changes what can be observed, certified, and contained.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
Q: How should security teams govern AI agents that can take actions in enterprise systems?
A: Security teams should govern AI agents as identities with explicit action scopes, tool permissions, and lifecycle controls.
Q: Why do prompt filters fail as the main control for AI agents?
A: Prompt filters only address the input layer, while most business risk appears after the agent has access to tools and data.
Q: What breaks when AI agent governance is treated like a configuration setting?
A: What breaks is the assumption that a one-time setup can govern a system that behaves differently across sessions, tools, and business contexts.
Practitioner guidance
- Classify agent identities before deployment Create a registry of every AI agent, the systems it can reach, the actions it can take, and whether it operates under human approval or independent execution.
- Restrict runtime authority to explicit business context Tie each agent to the minimum set of tools, data sources, and action types needed for a single business purpose.
- Move review from prompts to actions Audit agent logs for the actions taken after a prompt is accepted, including records created, messages sent, approvals triggered, and APIs called.
What's in the full announcement
Zenity's full analysis covers the operational detail this post intentionally leaves for the source:
- How Zenity frames runtime monitoring for agent behaviour across connected enterprise systems
- The specific deployment patterns they say customers are using to govern agent actions at scale
- Examples of the security layer concept they describe for monitoring and responding to agent behaviour
- The analyst recognition context and category framing behind the AI agent governance discussion
👉 Read Zenity's analysis of AI agent governance and runtime control →
AI agent governance and runtime control: what changes for IAM teams?
Explore further
13/06/2026 12:26 am
Prompt-layer security is the wrong mental model for agent governance. Agents do not fail only at the input boundary. They fail when a legitimate prompt leads to an unauthorised downstream action inside connected business systems, which means the control surface is runtime authority rather than text filtering. Practitioners should treat agent behaviour as the security object, not the prompt itself.
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.
- 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.
A question worth separating out:
Q: Who should own accountability for AI agent behaviour in the enterprise?
A: Accountability should sit with the team that owns the agent’s business purpose, access scope, and operating controls, not with a vague platform function. If the agent can reach finance, CRM, or email systems, the owner must be able to explain its permissions, logs, and containment model when something goes wrong.
👉 Read our full editorial: AI agent governance is shifting from prompts to runtime control
