What breaks when an LLM can choose tools freely?

What breaks is the assumption that valid actions can be precomputed in the client. When the model chooses tools and parameters at runtime, forbidden calls become harder to prevent and easier to infer from error feedback. Teams need role filtering, narrow tool descriptions, and backend enforcement to keep the model from turning free text into excess privilege.

Why This Matters for Security Teams

When an LLM can choose tools freely, the control problem shifts from access approval to runtime containment. Static allowlists, prompt-only guardrails, and client-side checks assume the action set is known in advance. That breaks as soon as the model can infer alternative paths, chain tools, or probe error messages to discover what the backend will tolerate. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework is converging on the same point: the model is not a trusted policy engine.

NHI Management Group has documented how rapidly agent misuse becomes visible only after deployment. In AI Agents: The New Attack Surface, SailPoint reports that 80% of organisations say their AI agents have already performed actions beyond intended scope, including unauthorised system access, sensitive data sharing, and credential exposure. That is not a tuning issue. It is a privilege design issue.

In practice, many security teams encounter tool abuse only after the agent has already made an unexpected call, rather than through intentional testing of the full tool chain.

How It Works in Practice

The practical fix is to move enforcement away from the model and into the execution path. The LLM may suggest an action, but the backend should decide whether that action is allowed for this identity, this session, and this context. That means narrow tool descriptions, role filtering, real-time policy evaluation, and backend authorization checks that validate both the target and the parameters.

For agentic workflows, static RBAC is often too blunt. A better pattern is intent-based or context-aware authorisation, where the decision is made at request time using current task context, data sensitivity, and trust state. This aligns with emerging agent guidance in OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize that agent behavior is dynamic and tool use can expand unexpectedly.

• Restrict the tool catalog to the minimum set needed for the task.
• Validate tool calls on the server, not in the client or prompt.
• Issue short-lived credentials per task or per session, then revoke automatically.
• Use workload identity to bind the agent to a cryptographic identity, not just a text prompt.
• Log attempted calls, rejected calls, and parameter changes for review and detection.

This is where workload identity becomes the control primitive. Standards such as SPIFFE and OIDC-based tokens are valuable because they identify what the agent is, while backend policy decides what that identity can do right now. NIST’s AI RMF supports this approach by pushing organisations toward measurable governance and continuous risk treatment, not just pre-approved access lists.

These controls tend to break down when the agent can call external plugins or indirect tools that introduce hidden privilege paths because the policy boundary is no longer the visible application alone.

Common Variations and Edge Cases

Tighter tool control often increases integration overhead, requiring organisations to balance reduced blast radius against developer velocity and operational friction. That tradeoff is real, especially in environments where agents need broad discovery access or must operate across multiple data planes. There is no universal standard for this yet, so current guidance suggests treating high-risk tools differently from low-risk read-only tools.

One common edge case is tool chaining. Even if each individual action seems safe, a sequence of actions can produce escalation, exfiltration, or lateral movement. Another is error-based inference: if the agent learns too much from “permission denied” messages, retries, or schema validation failures, it can map the control surface and search for a permissible bypass. That is why failure messages should be minimal and non-revealing.

For teams still maturing their controls, the most defensible pattern is to separate planning from execution. Let the model propose, but require a deterministic authorization layer to approve, deny, or scope every tool call. That approach is reinforced by NHI research such as LLMjacking: How Attackers Hijack AI Using Compromised NHIs, which shows how quickly exposed credentials can be abused once an attacker reaches the control plane.

Where this guidance breaks down most often is in loosely governed multi-agent systems with shared credentials and broad plugin access because one compromised agent can amplify its reach through the rest of the workflow.

Related resources from NHI Mgmt Group

• Why do AI agents create more IAM risk than ordinary developer tools?
• What breaks when an AI system can choose tools and actions on its own?
• What breaks when an agent uses mutable marketplace metadata to choose tools?
• What breaks when organisations rely on vaulting and rotation for agent credentials?