The main failure is that the model can convert untrusted text into real action. Without strict boundaries, prompt injection, SSRF, and over-scoped credentials can push the system into unintended requests, data exposure, or destructive writes. The issue is not the LLM alone, but the delegated access path around it.
Why Tool-Boundary Failures Turn an LLM into an Action Engine
Once an LLM can call tools, the risk shifts from generated text to delegated execution. The boundary is the control plane: which tools exist, what inputs they accept, what data they can read, and what side effects they can trigger. If that boundary is loose, untrusted content can be translated into network requests, file writes, ticket updates, or data exports with the model acting as an overconfident intermediary.
That is why agentic systems fail in practice when teams treat tool access like a convenience layer instead of a privileged interface. Prompt injection becomes more damaging because the model may follow hostile instructions hidden in pages, documents, or chat content; SSRF matters because the tool can reach internal endpoints; and over-scoped credentials turn a planning error into real impact. The pattern is described in the AI Agents: The New Attack Surface report, which notes that 80% of organisations report their AI agents have already performed actions beyond intended scope.
In practice, many security teams discover the problem only after a tool has already been used in a way no one intended, not during design review.
How It Works in Practice
Tool use becomes unsafe when the model can move from interpretation to execution without a hard policy decision in between. A secure design separates planning, approval, and action, and keeps the model from freely assembling side effects out of arbitrary text. The LLM should not be trusted to decide whether a request is safe just because it appears coherent or helpful.
- Tools should be narrowly scoped to one business function, with explicit allowlists for destinations, methods, and object types.
- Credentials should be bound to the smallest practical privilege, with short lifetimes and clear ownership.
- Inputs from web pages, emails, tickets, and documents should be treated as hostile data, not instructions.
- High-impact actions, such as deletion, transfer, or external disclosure, should require an independent approval step.
Good boundary design also means logging the exact prompt, tool call, parameters, and resulting side effect so that a reviewer can reconstruct what the model saw and what it actually did. This matters because a model may look deterministic in a demo while behaving differently once a live connector, retrieved content, or hidden instruction is introduced. The same report also states that only 52% of companies can track and audit the data their AI agents access, which leaves a large blind spot for investigation and compliance.
These controls tend to break down when teams wire many tools into one general-purpose agent and then rely on natural-language prompts as the main governance layer.
Common Variations and Edge Cases
Tighter boundaries often reduce flexibility and automation speed, so organisations have to balance convenience against blast-radius control. That trade-off becomes sharper when the agent is used for support, research, or operations, where small mistakes may be tolerated but silent side effects are not.
One common edge case is read-only access that still leaks sensitive data through summaries, logs, or citations. Another is partial write access, where the tool cannot modify everything, but can still trigger an irreversible workflow such as sending mail, opening tickets, or exporting records. The highest-risk systems are not always the most powerful ones, but the ones that combine broad retrieval, weak provenance, and action permissions in the same path.
There is also no universal standard for how much human review should sit between an agent and production systems. Current guidance suggests using stricter approval for external communications, financial actions, credential handling, and any workflow that crosses a trust boundary. The model can assist in those cases, but it should not be the final authority on whether the action is acceptable.
Risk and Threat Considerations
The material risk is delegated abuse, where an attacker or hostile input uses the model’s tool access to turn untrusted content into real-world action. That creates exposure across confidentiality, integrity, and availability because the compromise path is often indirect, through a seemingly harmless prompt or retrieved document.
Failure mechanism: Prompt injection, SSRF, and over-scoped credentials combine when the model can interpret attacker-controlled text as instruction and then use a tool with insufficient boundary checks. The attacker does not need to break the model itself, only the access path around it.
Impact: The result can be unauthorised data access, sensitive disclosure, destructive writes, malicious requests into internal systems, or activity that is difficult to attribute because it was executed through a legitimate agent workflow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 — Excessive Agency | Directly addresses over-broad tool authority in agentic systems |
| A3 — Prompt Injection | Explains hostile text steering tool use through untrusted instructions | |
| A4 — Insecure Output Handling | Covers unsafe translation from model output into side effects or requests | |
| Recommendation — Restrict agent actions to the minimum approved tool scope and require explicit policy checks for higher-risk calls. Treat external content as data, isolate instructions, and block tool execution from untrusted prompts. Validate model outputs before they trigger requests, writes, or other side effects. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity and Access Governance | Tool access depends on scoped credentials and delegated privileges |
| Recommendation — Bind tool credentials to least privilege, short lifetimes, and clear ownership. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Tool-calling agents need bounded access, approvals, and traceable authorization |
| Recommendation — Enforce role-bound access and approval controls for every privileged agent action. | ||
| CIS Controls v8 | 6 — Access Control Management | Limits who and what can perform sensitive actions through tool paths |
| Recommendation — Constrain, review, and revoke tool-linked access paths that exceed operational need. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | External tool exposure creates attackable interfaces and request paths |
| Recommendation — Harden exposed agent endpoints and monitor for abuse of externally reachable interfaces. | ||
Practitioner Guidance
What to prioritise: Treat every tool-connected LLM as a privileged integration, not a chat feature. Start by classifying the highest-impact actions it can take, then remove direct execution from anything that changes data, reaches internal services, or crosses a trust boundary.
Decision rule: If a tool call can expose secrets, mutate records, or contact an internal endpoint, require explicit policy enforcement outside the model and add a human approval gate for exceptional cases. If the action is low impact and reversible, keep the scope narrow and the audit trail complete.
What practitioners underestimate: The biggest failure is usually not model intelligence, but permission inheritance. Once the agent inherits broad credentials, every prompt injection, bad retrieval, or malformed request becomes a potential control-plane event.
Practitioner takeaway: The right boundary is the one that keeps the model useful while making unsafe actions impossible to execute silently.
Related resources from NHI Mgmt Group
- What breaks when an AI agent is allowed to call tools without strict scope controls?
- What breaks when AI agents can interact with gateway entities, analytics, and debugging tools without strict boundaries?
- What breaks when teams connect LLMs to production APIs without strict access boundaries?
- What breaks when an agent can call tools without user context?
