AI agent governance is shifting from prompts to runtime control

At a glance

What this is: Zenity frames AI agent governance as a runtime problem, not a prompt problem, because agents act inside enterprise systems and can take unapproved actions after input filtering has already finished.

Why it matters: IAM and security teams need to govern what agents can do at execution time, because prompt guardrails do not control downstream actions, delegated access, or autonomous decision-making in live systems.

Context

AI agent governance is the discipline of controlling what an agent can do after it has been prompted, not just what it is allowed to say or receive. The gap matters because agents do work inside CRM, email, and financial systems, where the risk is action, not only content.

Zenity's article argues that the old model, focused on prompt filtering and model safety, misses the actual attack surface created when an agent reasons, decides, and acts on behalf of a user. For identity programmes, that shifts attention from input hygiene to runtime boundaries, delegated authority, and observable execution.

The article also positions this as a scaling problem for enterprises that are already deploying large numbers of agents across multiple platforms. Human review cannot keep pace with autonomous actions, so governance has to move closer to issuance, authorisation, and runtime monitoring.

Key questions

Q: What breaks when security teams only filter prompts in agentic AI systems?

A: Prompt filtering only reduces conversational abuse. It does not stop an agent from calling tools, using APIs, or taking harmful downstream actions with valid credentials. If the execution path is ungoverned, a clean prompt can still produce a risky refund, data retrieval, or configuration change. The control gap is delegated privilege, not the text response.

Q: Why do AI agents need separate runtime authentication and authorisation controls?

A: Because agent governance answers who approved the agent and what it should do, while runtime controls decide whether the agent can actually act in a specific system. Without enforcement at the access layer, policy can describe boundaries that the live agent never has to obey. That is a direct production risk.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: Should organisations govern AI agents differently from chatbots?

A: Yes. Chatbots mainly expose content risk, while AI agents create action risk because they can decide, select tools, and execute in live systems. Governance has to focus on delegated authority, business-process containment, and runtime boundaries rather than conversation safety alone.

How it works in practice

Why prompt filtering does not govern AI agent action

Prompt filtering only constrains the input layer. It can block malicious text, but it does not control what an agent does once it has context, tools, and authority inside connected systems. That is why prompt injection is not the central governance boundary. The real issue is that an agent can interpret a request, select a tool, and perform an action that looks valid from the prompt alone but is unsafe in runtime context. In identity terms, the subject is not the prompt. It is the delegated execution path that follows it.

Practical implication: treat prompt controls as one input safeguard, not the governance model for agent behaviour.

Runtime control is the real enforcement point for agent identity

Runtime control means governing the agent while it is operating, based on the context of the task, the intent behind the request, and the scope of the systems it can reach. That is different from static policy because the risky decision often happens after the prompt is accepted. In autonomous systems, the identity is not simply authenticating once and staying still. It is choosing actions in real time. That makes runtime boundaries, action scoping, and continuously observable behaviour the controls that matter.

Practical implication: enforce action boundaries at execution time, not only at onboarding or prompt intake.

Why connected business systems expand agent risk beyond the chat layer

When an agent is connected to CRM, email, finance, or other enterprise systems, the security problem changes from content abuse to business-process abuse. The agent can take actions that are technically authorised but operationally wrong, such as sending messages, changing records, or initiating transactions without the intended human oversight. This is why governance has to account for downstream systems, not just the model interface. The agent inherits the blast radius of everything it can touch, and that blast radius is larger than most prompt-centric controls assume.

Practical implication: map every system an agent can reach and govern the highest-risk actions it can trigger there.

NHI Mgmt Group analysis

Prompt filtering is not a governance model for autonomous behaviour: It was designed for controlling inputs, not for constraining actions after an agent has context and tool access. That assumption fails when the actor can decide and execute at runtime, because the dangerous decision is often made after the prompt has been accepted. The implication is that identity governance has to move from content screening to execution control.

Runtime control is the new boundary for agent authorisation: The category is shifting because the relevant security question is no longer what the model saw, but what the agent was allowed to do next. That is a different control problem from chat safety or prompt moderation. Practitioners should treat runtime policy as the place where intent, context, and scope are enforced.

AI agent governance now depends on business-process containment, not model containment: Once an agent is wired into CRM, email, or finance, the blast radius becomes process-level, not interface-level. That changes how identity teams think about approval, delegation, and segregation of duties. The practical conclusion is that agent governance belongs in the same conversation as privileged workflow control.

Agent observability becomes an identity control, not just a detection aid: If security teams cannot see what an agent is doing in real time, they cannot govern it in real time. That is especially true when many agents act across many platforms at once. The implication is straightforward: runtime visibility is now part of identity enforcement, not a downstream monitoring luxury.

Named concept: runtime authority drift: This is the gap between the authority an agent is granted at setup and the wider action set it can accumulate once it is interacting with live systems. It is not just overprivilege in the classic NHI sense. It is a moving boundary problem created by autonomous execution. Practitioners need to govern the drift, because static policy will not.

From our research library:

• 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
• Read next: AI Agent Authorisation Guide

What this signals

Runtime authority drift: Identity programmes will increasingly need to govern how an agent's authority changes once it is connected to live systems, because the most dangerous action is often not the first one the agent was designed to take. That shifts policy design from static permission sets to runtime boundary enforcement and session-level visibility.

The practical programme question is no longer whether an agent can be prompted safely. It is whether the organisation can prove, in real time, which actions were permitted, which systems were touched, and where human review still has to sit in the loop.

For practitioners

• Define runtime authorization boundaries Specify which actions an agent may take after a prompt is accepted, including record changes, message sends, approvals, and transaction initiation. Tie each boundary to the business system it affects, not just to the model or interface layer.
• Inventory every connected system Map the CRM, email, finance, and workflow platforms each agent can reach, then rank them by business impact if the agent acts incorrectly. Use that inventory to decide where runtime enforcement must be strictest.
• Separate prompt safety from execution safety Keep prompt filtering and model safety as input controls, but add independent controls for action approval, scoped tool use, and session-level monitoring. Do not assume a clean prompt equals a safe outcome.
• Instrument agent activity for real-time review Log tool calls, downstream actions, and policy decisions in a form that operators can inspect while the session is still live. Without that, review happens after the business effect has already occurred.

Key takeaways

• AI agent governance fails when teams stop at prompt controls and never govern the actions an agent can take inside enterprise systems.
• The core risk is runtime behaviour at machine speed, where delegated access can turn a normal task into an unreviewed business action.
• Identity teams need execution boundaries, live observability, and scoped authorisation if they want to contain agent blast radius.

Key terms

• Runtime authority drift: A failure mode where an actor begins with a narrow, acceptable level of access or intent, then expands its effective authority as the session unfolds. In agentic systems, this often appears when the platform keeps trusting the interaction after the actor has already started to deviate from the original purpose.
• Prompt-layer control: A safeguard that filters or constrains what enters an AI system before the model or agent acts. It is useful for input hygiene, but it does not by itself govern downstream actions, delegated access, or business-system changes once execution begins.
• Runtime boundary: The point at which an identity's permissions, execution context, and observable behaviour are contained for policy purposes. In agentic systems, runtime boundaries matter because they determine whether the organisation can explain, audit, and limit what the agent did after execution begins.
• Delegation authority: Delegation authority is the right for one identity to act on behalf of another within a defined scope. For agents, it must be explicit, time-bound, and auditable because the system may initiate actions independently once granted access.

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 building or maturing an IAM programme, it is worth exploring.