What breaks when a ReAct agent can choose tools and models at runtime?

Why runtime tool and model choice breaks the old control boundary

A ReAct agent changes the security problem because the next action is not fixed at design time. It can choose a tool, revise its plan, or switch models after seeing new observations, so the real control point is the decision loop itself. If policy only approves the initial request, the agent can still expand its effective authority during execution.

That means the important question is not simply whether a tool call was allowed once. It is whether each step in the loop is evaluated against current context, current task scope, and current privilege. Runtime choice turns policy from a gate at entry into a continuous authorization problem.

In practice, that affects both model selection and tool selection. A weaker model might be acceptable for summarisation, while a stronger model or a different tool may be needed for retrieval, code execution, or external side effects. If those transitions are not governed, the agent can cross from low-risk reasoning into high-impact action without a fresh decision.

Where policy, trust, and blast radius fail

Static IAM and API policy assume the caller path, target, and intent are known in advance. A ReAct loop breaks that assumption because the agent can chain observations into new actions that were never part of the original request. That is why tools, model switches, and downstream effects need per-step boundaries, not just a single allow decision.

Practically, the highest-risk failure is over-broad delegation. A tool that looks harmless in isolation can become dangerous when the agent uses it repeatedly, in combination, or with a more capable model. AI Agent Authorisation Guide is useful here because it frames least privilege, task-scoped access, and per-action decisions as controls on the loop rather than on the starting request.

Another failure mode is hidden context growth. Each observation can carry fresh identifiers, secrets, or prompts that reshape the next action, so the effective trust boundary moves during execution. Zero Trust for AI Agents aligns well with that problem because it treats the principal, request, and policy outcome as continuously verified rather than assumed once at session start.

Model choice itself can also become a control bypass if switching models changes what the agent is capable of doing. A routing layer that sends some steps to a more powerful model without re-evaluating scope can unintentionally widen the blast radius. Agentic AI Security Guide is relevant because it connects tool use, orchestration, and identity into one threat surface.

How practitioners should govern the loop, not just the call

The right design pattern is to make every step externally governable. That means the agent’s plan, tool request, and model request should all be inspectable before execution, with policy that can deny, narrow, or require approval based on the specific step. AI Agent Observability, Audit and Incident Response Guide supports that approach because attribution and step-level logging are what make runtime governance enforceable after the fact as well.

Tool routing should also be constrained by task class. If a step only needs reasoning, it should not inherit network, filesystem, payment, or production-system access just because the enclosing agent can reach those capabilities. AI Coding Agents Security Guide is a good reference point for this pattern because it highlights how over-scoped credentials and ambient access turn an assistant into an execution risk.

The cleanest operational rule is simple: if the next action can change state, spend money, reveal secrets, or reach a different trust zone, treat it as a fresh authorization decision. That keeps the agent usable while preventing capability creep from accumulating invisibly across the reasoning loop.

Risk and Threat Considerations

Runtime tool and model choice creates a control gap that attackers can exploit through prompt injection, tool misuse, or delegation abuse. The danger is not just one bad action, but the agent learning enough from its environment to justify progressively more privileged actions that were never intended by the original policy.

Failure mechanism: A stepwise agent can translate benign-seeming observations into higher-risk tool calls, model switches, or chained actions, while static policy continues to evaluate only the original request envelope.

Impact: The agent can expand privileges during execution, access data or systems outside the intended scope, and amplify a single compromise into broader lateral or downstream damage.

Practitioner Guidance

What to prioritise: Put decision points at the boundaries where capability changes, especially tool invocation, model switching, and any action that can mutate state or cross a trust boundary. If those steps are not individually governed, the rest of the control stack will be reactive rather than preventive.

What to verify: Confirm that each agent step is tagged with the current task context, the allowed tool set, the permitted model set, and the approval rule that justified the step. If you cannot reconstruct why a high-impact step was allowed, the policy is too coarse to trust.

Common mistake: Teams often secure the first prompt and assume the session is contained. ReAct breaks that assumption because the dangerous decision is often not the first one, but the next one chosen after the environment changes.

Practitioner takeaway: Treat runtime agent governance as continuous authorization with observability, not as one-time access grant at session start.

Related resources from NHI Mgmt Group

• What breaks when an agent uses mutable marketplace metadata to choose tools?
• What breaks when an AI agent can choose its own attack path at runtime?
• What breaks when autonomous AI agents can choose models at runtime?
• What is the difference between human identity governance and AI agent governance?