AI agent governance is shifting from prompts to runtime control

At a glance

What this is: Zenity’s analysis says AI agent security has to move from prompt-layer controls to runtime governance of agent behaviour, context, and action boundaries.

Why it matters: IAM, PAM, and NHI teams need to treat agents as governed identities with constrained actions, or risk losing visibility into who and what is acting across enterprise systems.

👉 Read Zenity's analysis of AI agent governance and runtime control

Context

AI agent governance fails when security teams focus only on prompts, inputs, and outputs. The real issue is whether an agent can decide and act inside connected systems with authority that outlives a single request, which makes this an identity governance problem as much as an AI problem.

For IAM and NHI programmes, the question is no longer whether AI is present in the workflow. It is whether the organisation can define, review, and contain an agent’s runtime behaviour across CRM, email, finance, and other business systems before that behaviour becomes operational default.

Key questions

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. The key is to define what each agent may do inside connected systems, then monitor actual runtime behaviour against that scope. If the agent can act independently, governance must follow execution, not just deployment.

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. Once an agent can make downstream choices, the dangerous action may be fully valid from a prompt perspective and still unacceptable from a governance perspective. Control has to extend to actions, not just text.

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. Configuration can define a starting point, but it cannot reliably contain runtime decisions or changing access paths. Practitioners need continuous monitoring and contextual policy enforcement instead.

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.

How it works in practice

Why prompt filtering misses the real agent risk

Prompt filtering and model safety reduce some harmful inputs, but they do not govern what an agent does after it has access to tools and data. The core failure mode is action-layer abuse: an agent can accept legitimate input, then trigger a downstream action that no reviewer sees in real time. In identity terms, the control boundary is not the prompt. It is the combination of permissions, execution context, and allowed actions. That is why runtime governance matters more than content filtering for agentic systems.

Practical implication: review agent permissions and action scopes, not just prompt protections.

Runtime governance for AI agent identity and access

Runtime governance means controlling what an agent may access, when it may act, and under what contextual conditions those actions are allowed. For AI agents, that requires identity boundaries that resemble NHI governance but must also account for decision-making at execution time. If an agent can choose actions dynamically across systems, then static approval at provisioning is not enough to describe effective privilege. The governance model has to follow the agent through each session and each tool call, not just the deployment checklist.

Practical implication: map agent identities to each connected tool and enforce session-level constraints.

Why autonomous behaviour changes the control model

An agent that reasons, decides, and acts independently is not governed well by controls built for fixed workflows. Traditional checks assume a human initiates a request, a reviewer approves it, and the system performs a bounded action. Autonomous behaviour collapses that sequence. The security model has to distinguish between a tool-using workflow assistant and an identity that can initiate, sequence, and complete actions on its own. Once that boundary is crossed, governance shifts from request approval to continuous containment.

Practical implication: classify which systems are truly autonomous before assigning human review or NHI controls.

NHI Mgmt Group analysis

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.

AI agent identity is becoming an NHI governance problem with autonomous characteristics. Once agents hold credentials, invoke tools, and act across systems, they need the same lifecycle discipline as other non-human identities, but with stronger attention to decision timing and action sequencing. That is where conventional provisioning logic becomes incomplete, because the risk is not only who the agent is, but what it can decide to do next.

Runtime context is the missing governance layer for agentic systems. The market keeps talking about guardrails, but the real issue is whether policy can follow the agent into each action path, tool call, and delegated task. Without context-aware boundaries, enterprises will keep discovering that policy written for static systems does not survive dynamic execution. Practitioners need a governance model that moves with the agent.

Agent security is now a programme design issue, not a point-control issue. Organisations that place AI agents inside customer, finance, and operational workflows are creating a cross-domain identity problem that spans IAM, NHI, PAM, and AI governance. The lesson for security leaders is to stop treating agent governance as a niche overlay and start building it into identity architecture from the outset.

From our research:

• 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.
• That gap is why readers should also review the OWASP Agentic AI Top 10 alongside runtime identity controls for agents.

What this signals

Agent-governance debt: many programmes will discover that they have approved agent deployments faster than they have built control points for those agents. That creates a structural mismatch between adoption and oversight, especially when multiple business teams can spin up agents faster than identity teams can classify them. The practical result is that governance must shift from periodic review to continuous inventory and containment.

The teams most exposed are the ones that treat AI agents as a feature inside existing apps rather than as identities with their own access boundaries. Once agents operate across finance, customer, and operational systems, the control model has to connect IAM, NHI, and AI governance in one operating view.

Security leaders should expect agent behaviour to become a standard audit question, not a niche AI discussion. The near-term programme signal is simple: if you cannot explain what each agent can access, what it can do, and who owns it, your identity model is already behind the deployment curve.

For practitioners

• 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. Use that inventory to decide whether the agent belongs under NHI controls, autonomous governance, or both.
• 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. Reassess those permissions whenever the workflow changes, because runtime context determines whether the privilege remains valid.
• 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. That evidence shows whether the agent stayed within its intended scope better than prompt review alone.
• Test whether human review can actually keep pace Validate whether your current approval and certification processes can see and respond to agent behaviour quickly enough to matter. If the answer is no, redesign the control model around continuous containment instead of periodic review.

Key takeaways

• AI agents change the control problem from prompt safety to runtime authority, which current IAM models do not fully cover.
• Enterprise adoption is moving faster than policy creation, leaving most organisations with governance intent but incomplete enforcement.
• Practitioners should classify agent identities, constrain action scope, and monitor actual behaviour rather than relying on configuration alone.

Key terms

• Agent Identity: An agent identity is the set of credentials, permissions, and ownership signals tied to an AI system that can act in a business environment. It becomes a governance object when the system can select actions, use tools, and access data beyond a single static workflow.
• Runtime Governance: Runtime governance is the practice of controlling what a system may do while it is operating, not just what it was allowed to do at deployment. For AI agents, it means checking actions, context, and permissions as execution unfolds, because preapproval alone does not capture live behaviour.
• Action Scope: Action scope is the set of operations an identity is allowed to perform inside connected systems. For AI agents, scope must be defined by tool access, data reach, and decision boundaries, because the same prompt can produce different actions depending on runtime context.
• Agentic AI: Agentic AI refers to AI systems that can decide, sequence, and carry out actions with limited or no human intervention. In identity governance, that changes the control problem from static access to ongoing containment, because the system may initiate action paths rather than simply respond to requests.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: The Vendor to Beat, Built Before the Category Had a Name. Read the original.