What should teams do when AI approvals do not prevent risky behaviour?

Why approval-only governance fails for adaptive AI

Approval gates are useful for setting boundaries before a system is released, but they do not govern every decision an adaptive system makes once it starts operating. That is the core reason teams need runtime controls, not just launch-time review. A system can stay inside policy at approval time and still drift into risky behaviour through tool choice, prompt variation, changing context, or unexpected downstream actions.

The practical distinction is between policy on paper and policy in execution. If the system can act, call tools, or reach data after approval, the real control point is the moment of action. That is where teams need to decide what the system may do, under what conditions, and with what monitoring or intervention path.

Pre-approval still matters for use-case screening, role assignment, and deciding whether a workflow should exist at all. But for systems with autonomous or semi-autonomous execution, teams should treat approval as one control layer, not the control layer. When the risk is created by runtime behaviour, the response has to be runtime governance.

How to move governance closer to execution

The most effective pattern is to constrain the system at the point of action, using per-action policy enforcement, narrow delegated authority, and monitored tool access. That means the system should only receive the minimum authority required for the current task, and the authority should be visible, revocable, and scoped to the action rather than the whole session or environment.

This also changes how teams design workflows. A broad approval to “use the finance tools” or “manage customer records” is usually too coarse if the system can branch into multiple actions with different risk levels. Finer-grained policy checks, especially for sensitive tools or destructive operations, give teams a way to block the specific risky step without shutting down the entire use case.

Runtime controls work best when they are paired with clear decision boundaries. If an action is low risk and reversible, automation can proceed with lighter friction. If it changes records, moves money, exposes data, or creates external side effects, the system should face stronger checks, tighter scopes, or human confirmation before execution.

What “good” looks like in operational terms

Teams should be able to explain, for any material action, who or what approved it, what authority was granted, what tool was called, and what evidence was recorded. If that chain cannot be reconstructed, the system may still be functioning, but it is not operating under strong governance.

Good operating design also means limiting the blast radius of mistakes. A system that can only read a narrow dataset, call one approved tool, or complete one bounded task is easier to trust than a system with open-ended permissions and vague guardrails. The more adaptive the system, the more important it is to separate proposal from execution.

Monitoring should focus on the actions that matter, not just on whether a request was initially allowed. If a system is behaving in a way that contradicts the approved purpose, produces unusual tool patterns, or starts chaining actions in ways the approver did not intend, that is an operational control failure even if the original approval was valid.

Risk and Threat Considerations

Approval-only governance creates a false sense of safety because it assumes the risky part of the system happens before deployment. In practice, the exposure often appears later, when the system composes tools, expands scope, or takes an action that was never individually reviewed. This is especially important when the system can touch production data, external services, or privileged workflows.

Failure mechanism: The system receives broad standing permission, then uses that permission in a way the initial approval did not anticipate, whether through overbroad delegation, tool chaining, context drift, or misuse of a legitimate path.

Impact: The result can be unauthorized data access, unintended transactions, broken separation of duties, or hard-to-audit actions that are technically allowed but operationally unsafe.

Practitioner Guidance

What to prioritise: Put the strongest controls around the actions with real side effects first, especially anything that can change records, expose data, or trigger external systems. That is usually where approval-only models fail earliest.

Decision rule: If an action can materially affect users, systems, or data, require runtime policy enforcement and scoped authority at the point of execution; if it is read-only and reversible, lighter control may be acceptable.

What to verify: Confirm that the system’s actual tool permissions, token scope, and execution paths are narrower than its full theoretical capability. If the runtime grant is wider than the approved use case, the control design is too weak.

Practitioner takeaway: The goal is not to approve AI more often, but to ensure that every meaningful action remains bounded, observable, and revocable while the system is running.

Related resources from NHI Mgmt Group

• How should security teams handle risks from AI browser extensions?
• How should security teams govern API keys used for generative AI access?
• Why do control plane tools fail to prevent risky AI agent behaviour?
• How should security teams detect risky AI agent behaviour in production?