Where should approval for agent actions be enforced?

How approval should be enforced across agent hops

Approval belongs in the enforcement point that every action must pass through, not in the message payload or in a single product feature. That means the decision stays outside the protocol so the same policy can govern tool calls, agent-to-agent handoffs and payment or fulfillment steps. If approval is only advisory, the next hop can silently continue without it.

The practical test is whether an approver can block, scope, or time-limit the action at the point of execution. If the enforcement layer cannot see the current principal, requested tool, target resource and step in the workflow, it cannot reliably decide. In multi-hop systems, the approval state also needs to survive delegation, retries and translation between services.

That is why approval should be treated as a control-plane responsibility. The protocol can carry context, but the policy decision needs an external authority that can apply consistent rules regardless of which agent, connector or vendor is involved. Otherwise, approval becomes a local convention rather than a security control.

Why protocol-level approval fails in real agent workflows

Protocol-level approval is fragile because downstream components often re-emit, transform, or partially reconstruct a request. A hop may preserve the intent but lose the approval evidence, or it may forward the request in a form that no longer exposes the original constraint. When that happens, the control silently degrades into a hint.

This is especially dangerous when different hops have different blast radii. A benign-looking tool call can turn into a higher-risk action once it reaches a payment rail, production admin API, or external data source. If the approval was only attached to the first message, the later hop may execute with broader authority than the reviewer intended.

Approval in the control plane also supports consistent handling of exceptions. You can require step-up review for unusual destinations, high-value transfers, or cross-boundary actions without redesigning the protocol each time. The approval decision becomes reusable policy, not a one-off implementation detail.

Where control-plane approval belongs in the agent stack

In a well-structured agent stack, the control plane sits between intent and execution. The agent can propose an action, but the control plane decides whether the action is allowed, whether it needs human review, and what constraints apply before the execution plane carries it out. That separation is what keeps policy independent from any one tool or model.

This is also where delegated authority should be narrowed. For example, a task-scoped approval can allow one payment, one lookup, or one document update, rather than granting a standing ability to repeat the same action indefinitely. If the system supports multiple agents or vendor services, the control plane should evaluate the same rule set across all of them.

A useful design pattern is to bind approval to the action, not just to the actor. The reviewer should be approving a specific operation against a specific target under specific conditions, rather than signing a broad approval token that can be replayed elsewhere. That keeps context attached to the decision instead of to the transport.

Risk and Threat Considerations

When approval is embedded only in protocol messages or vendor-specific features, it is easy for a downstream hop to ignore, strip, or misinterpret it. That creates a control gap between what was reviewed and what actually executes, which is exactly where overreach, payment abuse, and delegated-action misuse tend to appear.

Failure mechanism: The system treats approval as metadata instead of an enforcement decision, so a later hop can proceed with a request that no longer carries verifiable, context-aware authorization.

Impact: Actions can execute outside the intended scope, approval can be bypassed through handoff or transformation, and incident response becomes harder because the audit trail no longer reflects the true decision point.

Practitioner Guidance

What to verify: Confirm that every executable hop, including tool brokers, orchestration layers and payment or fulfillment services, checks the same approval decision before action. If any hop can act on a request without consulting the control plane, the design is not enforcing approval.

Decision rule: If the action can change money movement, external state, or privileged access, require a fresh policy decision at execution time rather than trusting approval carried earlier in the chain. If the action is low impact, the policy may be lighter, but it should still be enforced centrally.

What good looks like: The system can show who approved, what was approved, when it was approved, and which execution hop consumed that approval. That evidence should survive retries, handoffs, and downstream translation without relying on a single platform feature.

Practitioner takeaway: Approval is only real when the enforcement point can stop the action at the moment of execution; anything less is documentation, not control.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• How can organisations reduce the blast radius of compromised agent identities?
• Where does cross-environment agent discovery fit in an IAM programme?
• How should security teams handle approval for sensitive AI agent actions that happen asynchronously?