Should organisations replace denylist controls with approval-gated execution for agents?

Why approval gates beat denylists for high-risk agent actions

Denylist controls assume you can enumerate the bad action in time and in the right form. Agents can rephrase requests, change call paths, or chain smaller actions until a deny rule is bypassed. Approval gates shift the decision from pattern matching to explicit authorisation, which is much more defensible when the action can create broad impact quickly.

That matters most when the action is inherently high consequence: outbound network access, secret retrieval, privilege changes, system modification, data export, or anything that can expand the agent’s blast radius if the control fails.

Approval-gated execution is not just a slower denylist, it is a different control model. The gate asks whether the specific action should happen now, under this context, for this actor, with this scope. That makes it easier to reason about intent, scope, and accountability than a static blocklist that can age out as commands, tools, and integrations change.

Where denylist controls still help, and where they do not

Denylist rules still have value for narrow, well-understood abuse patterns, especially when you can block a specific dangerous destination, command, or tool invocation with low ambiguity. They are useful as a backstop, but they are weak as the primary defence when the agent has enough autonomy to transform requests into equivalent actions.

The practical failure mode is simple: the agent does not need to call the exact blocked function to cause harm. It may use another tool, another endpoint, another shell form, or another sequence of calls that produces the same result. Once that happens, the denylist has created a false sense of control while the real decision point was never reached.

A good rule is to reserve denylists for obvious forbidden classes and use approval gates for actions that change trust boundaries, expose secrets, or create durable access. That split keeps the policy surface smaller and makes the high-risk decision visible to a human before execution.

What approval-gated execution should cover in practice

Approval should not be reserved for exceptional events only. It should be the default for actions that can materially change environment state, especially when the agent is operating with delegated permissions. The gate should show the exact action, the target, the scope, and the expected effect so the reviewer is approving a concrete request rather than a vague intent.

For agent programs that touch identity, access, or sensitive operations, AI Agent Authorisation Guide is the clearest internal reference for task-scoped access and per-action policy decisions. When the workflow spans multiple agents or delegated hops, Multi-Agent and A2A Security Guide is useful for understanding how delegation chains and multi-hop trust can expand risk.

For operational design, reviewers should be able to distinguish between routine low-impact actions and actions that require explicit human acknowledgement. That includes credential exposure, system changes, and network-relevant operations where a bad approval or a missed block can become immediate operational impact.

Risk and Threat Considerations

Approval-gated execution reduces the chance that an agent can turn a simple prompt into a high-impact action without scrutiny, but the control only works if reviewers see the real request and the gate is hard to bypass. If the approval screen is vague, overused, or detached from the actual action, the system will drift back toward rubber-stamping.

Failure mechanism: Agents can evade denylists by reformulating commands, switching tools, or chaining smaller permitted actions until they reach the same outcome. They can also exploit human fatigue if every request is routed for approval without meaningful prioritisation.

Impact: The result is unauthorized network access, secret exposure, privilege escalation, or system modification that looks controlled on paper but is operationally equivalent to unrestricted execution.

Practitioner Guidance

Decision rule: If the action can expose credentials, alter production state, or create new access paths, use approval gating as the primary control and keep denylists as a narrow secondary backstop.

What to verify: The approval prompt should show the exact target, action type, and expected blast radius. If a reviewer cannot tell what changes, the gate is too weak to trust.

Common mistake: Treating every action the same. Low-risk read-only requests can stay automated, but high-risk write or access changes need explicit human confirmation before execution.

Practitioner takeaway: Denylists are best at blocking known bad forms, while approval gates are better at governing high-consequence intent. When an agent can reshape actions faster than humans can pattern-match them, the approval decision is the control that still holds up.

Related resources from NHI Mgmt Group

• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?
• When is it crucial to implement least-privilege access for AI agents?
• What is the difference between managed identities and hardcoded secrets for AI agents?