What should security teams do when an AI agent can route around controls?

When the agent can change tools, what stays fixed?

The control point is not the tool call, it is the decision that permits the action. If security teams only check each tool invocation, an agent can still reach the same harmful outcome by switching paths, chaining tools, or rephrasing the request. The policy has to bind to the outcome, then the runtime layer enforces whether any chosen tool may carry it out.

This is why per-tool allowlists are necessary but insufficient. They are enforcement, not governance. Governance has to answer a harder question: should this agent be allowed to perform this class of action at all, under these conditions, for this principal, on this asset, and with this blast radius?

A useful way to think about it is to separate intent from execution. Intent is the business or security decision, for example “create a customer record,” “disable an account,” or “issue a refund.” Execution is the specific tool, API, or workflow the agent uses to do it. If the intent is not approved first, the agent can search for another route around the guardrail and still remain technically compliant with a narrow tool policy.

How outcome authorisation changes the control model

Outcome authorisation forces teams to define what an agent is allowed to achieve, not just what commands it may attempt. That matters because agent behaviour is often non-linear: the same end state may be reached through different tools, alternate APIs, or multi-step plans. A policy that is only expressed at the tool layer will miss those substitutions.

Practically, this means the approval decision should sit above tool selection and above prompt content. The agent may still need a lower-level check for each request, but that check should confirm that the request maps to an already-approved outcome. If the action was never authorised in the first place, a valid tool token or a permitted connector should not rescue it.

Teams should also treat “can do” and “should do” as different questions. An agent that has the technical ability to call a tool is not automatically permitted to use that capability in every context. The policy should define boundaries such as data class, environment, time window, user context, and maximum effect, then let enforcement verify each invocation against those boundaries.

For readers looking for a deeper control model, the AI Agent Authorisation Guide covers task-scoped access, per-action policy decisions, and approval gates. The broader Zero Trust for AI Agents approach is the same idea applied operationally: verify the principal and the request before every meaningful action.

What a secure runtime should verify before any action executes

A secure agent runtime should verify four things before execution: who or what is acting, what outcome is being requested, whether that outcome has already been approved, and whether the specific tool call still fits the approved scope. That last check is important because the agent may change tools without changing intent, and the control should still hold.

This is where delegated authority, least privilege, and short-lived access become practical rather than theoretical. If an agent is authorised to do only one bounded task, the runtime should issue only the narrowest credentials needed for that task and revoke them when the task is done. If an approval is missing, stale, or too broad, the safer behaviour is to stop and request a fresh decision rather than infer permission from prior context.

Tool-level checks should also be state-aware. A request that is safe in a test tenant may be unacceptable in production; a request that is acceptable for one business unit may be out of policy for another. The runtime needs to know not just the tool name, but the environment, resource, and effect that the tool call will touch.

For implementation detail on identity, delegation, and lifecycle, see the Agentic AI Identity Guide. When teams need to inspect behaviour after the fact, the AI Agent Observability, Audit and Incident Response Guide is the right companion, because governance only works if actions are attributable and revocable.

Risk and Threat Considerations

When teams rely on tool-by-tool checks alone, the main risk is policy bypass through route changes. A determined agent can reach the same harmful effect through another connector, another API, or a multi-step chain that was never explicitly reviewed. The result is governance drift, where the approved policy and the actual runtime behaviour no longer describe the same level of authority.

Failure mechanism: The agent changes execution path while preserving intent, so the tool check passes even though the higher-level action was never authorised. That creates a confused-deputy style failure in which the enforcement layer confirms a local rule, but the system still performs an unapproved business action.

Impact: Teams can lose containment over sensitive operations, expose data or funds, and miss the point at which an action should have been blocked or escalated. In the worst case, the system appears controlled while it is actually allowing unauthorised outcomes through alternate routes.

Practitioner Guidance

What to prioritise: Put an explicit approval layer around the outcome class, then use tool checks only as the final gate for execution. If the approval language cannot describe the action in business terms, the control is probably too narrow.

What to verify: Confirm that each approved outcome maps to a bounded principal, a bounded environment, and a bounded duration. Also verify that the runtime can prove which approval decision authorised the action, not just which tool executed it.

Common mistake: Teams often harden the connector layer and assume the job is done. That helps, but it does not stop an agent from reaching the same result through another approved connector unless the policy is expressed at the action level.

Practitioner takeaway: If the policy does not survive a tool swap, it is not governing the agent, it is only governing one path the agent may take.

Related resources from NHI Mgmt Group

• How should security teams handle AI agent visibility?
• How should security teams monitor AI agent activity without disrupting developers?
• How should security teams implement controls around AI agent harnesses when the model can be tricked but the environment still executes actions?
• How should security teams govern machine identity credentials in agentic AI environments?