1. What LLM07 Actually Is
A tool is insecure when it gives the model a capability that is broader than the user, task, or policy should allow. The vulnerability is usually not the model choosing poorly; it is the application exposing a dangerous function and then letting untrusted text steer the arguments. That turns the LLM into a confused deputy between attacker-controlled language and privileged systems.
Tool design includes the function schema, argument validation, authorization model, side effects, error handling, logging, and confirmation flow. If any of those assume the model has trustworthy intent, the tool is already unsafe. A model can be prompted, injected, or simply mistaken. The tool must remain correct under those conditions.
The model is not the approver
A statement such as "the model decided this action is safe" is not an authorization check. Authorization must be enforced outside the model, against the authenticated user, current tenant, requested object, and allowed business action.
2. Attack Shapes (Defanged)
Defanged by design
The examples describe tool-failure patterns without operational payloads or targetable tool calls.
2.1 Over-broad read tool
A search or database tool accepts arbitrary filters and runs with a service account that can see more data than the current user. A prompt injection or malicious user asks a narrow question, but the model constructs a broad query. The tool returns data the user should never have been able to read.
2.2 Unsafe write tool
A ticket, email, CRM, or deployment tool performs side effects as soon as the model calls it. If the action is irreversible or external-facing, a single misinterpreted instruction can send the wrong message, alter a record, or trigger a workflow.
2.3 URL fetcher as SSRF helper
A generic HTTP tool lets the model fetch arbitrary URLs. Even without a classic SSRF exploit string, it can bridge from language into internal network access if egress controls and host allow-lists are absent.
2.4 Error-message oracle
A tool returns verbose exceptions, stack traces, schema hints, or permission errors directly to the model and user. Attackers can use those differences to enumerate objects, infer hidden capabilities, or tune later requests.
3. Blue-Team Detection
Tool security is observable if every call is logged as a first-class security event: principal, tenant, tool name, arguments, policy decision, retrieved context, output size, target object, side-effect flag, and confirmation status. Without those fields, incident response cannot tell whether a bad answer was only text or an action.
| Signal | Likely issue | Response |
|---|---|---|
| Tool call after low-trust retrieval | Indirect prompt injection may be driving side effects | Require confirmation or block action |
| Arguments outside normal envelope | Model created broad or malformed query | Reject with schema validation and alert |
| Denied egress or host mismatch | Generic fetch tool attempted unapproved destination | Log as high-signal security event |
| Write action without confirmation record | HITL bypass or bad tool policy | Suspend tool and review workflow |
| Verbose tool errors in model output | Information disclosure through tool plumbing | Sanitize errors and rotate exposed secrets if present |
MITRE ATLAS helps describe the model-manipulation stage, while MITRE ATT&CK covers the conventional consequences: discovery, collection, exfiltration, or impact performed through a trusted application component.
4. Mitigation and Build Controls
- Least-privilege credentials. Scope every tool call to the current user and tenant. Avoid ambient admin credentials in the agent runtime.
- Typed, narrow schemas. Prefer constrained enums, object IDs, and bounded parameters over free-form strings. Reject unknown fields and ambiguous instructions.
- Policy engine outside the model. The model proposes a tool call; deterministic policy decides whether that call is allowed.
- Side-effect classes. Mark tools as read-only, reversible write, irreversible write, or external communication. Require stronger confirmation as impact rises.
- Egress allow-lists. HTTP tools should reach only approved hosts and paths. Network policy must enforce this, not the prompt.
- Safe errors. Return stable, minimal errors to users and models; send detailed diagnostics to logs with access control.
# ILLUSTRATIVE - tool policy envelope
tool: crm_update_case
side_effect: reversible_write
allowed_roles: [case_owner, support_lead]
arguments:
case_id: existing_case_visible_to_user
status: enum[open, pending_customer, resolved]
note: max_length=1000, no_secrets=true
requires_confirmation: true
denied_if:
- retrieved_context_trust == public_web
- user_tenant != case_tenant
- model_confidence_only == true5. Mapping to WSTG, ATLAS, and Related LLM Risks
| Tool weakness | OWASP WSTG / ASVS lens | MITRE view | Related LLM risks |
|---|---|---|---|
| Over-broad read access | Authorization and access-control testing | Collection through trusted application path | LLM06, LLM10 |
| Unsafe side effects | Business-logic and transaction testing | Impact through delegated function execution | LLM08, LLM01 |
| Generic network fetch | SSRF and egress-control testing | Discovery or exfiltration via application proxy | LLM02, LLM06 |
| Weak schemas | Input validation and error handling | Execution after model manipulation | LLM04, LLM09 |
LLM07 is where classic application security and AI security meet. WSTG-style testing finds the broken authorization and input validation; ATLAS explains how model manipulation reaches the tool boundary; the OWASP LLM risks explain why the model should never be trusted as a policy engine.
Design Tools as Security Boundaries
These risks are not solved by a policy paragraph. They need adversarial testing, defensive telemetry, and architecture changes that can be inspected. Use the AI red-teaming path to validate controls, the blue-team guide to operationalize detections, and the contact route to request a focused review.