Illustrative sample. The system, company and findings below are fictional and describe common failure modes of tool-using LLM applications. They are not from a real engagement.
The system under review
Example Insurance Co. runs a claims-support assistant. A customer-service agent types a question; a language model searches policy documents (retrieval), reads the customer’s record, and can draft emails, update claim status and issue small goodwill refunds through tools.
Tool and permission map
| Tool | Reaches | Can change things? | Control in place today |
| search_policy_docs | Policy document index | No | None needed beyond index access |
| lookup_customer | Customer record (read) | No | One shared service account |
| draft_email | Outbound email drafts | Drafts only | Agent reviews before sending |
| update_claim_status | Claims system (write) | Yes | One shared service account |
| issue_refund | Payments (write) | Yes | Amount set by the model; no limit in code |
Prioritised findings
High F1
Every tool shares one write-capable service account
The lookup, status-update and refund tools all run under the same credential, so any one of them can reach everything the account can.
Recommended: Give each tool its own least-privilege credential, so a misused tool cannot reach the others’ data.
High F2
The refund amount is chosen by the model with no server-side limit
Nothing outside the model checks the amount or the number of refunds. A wrong or manipulated instruction becomes a payment.
Recommended: Enforce a ceiling and a per-claim count in the payments service, and require human approval above a threshold.
High F3
Retrieved document text can carry instructions into a tool-calling context
Policy documents and uploaded attachments are indexed together. Text inside them reaches the same context that decides which tool to call, so a crafted document can try to steer the agent.
Recommended: Separate untrusted content from instructions, keep uploaded files out of the trusted index, and re-check tool calls against the user’s request.
Medium F4
The audit log records answers but not tool calls
After an incident you could read what the assistant said, but not which tools it called, with what arguments, or what came back.
Recommended: Log every tool call with arguments, result and requesting user, in a store the agent cannot edit.
Medium F5
Blocked or unusual tool calls are neither blocked nor flagged
There is no rule for a tool called outside its normal pattern, so a failure is silent until someone notices its effect.
Recommended: Add blocking rules for out-of-policy calls and an alert on repeated attempts.
Medium F6
Coverage answers are given without checking them against the policy text
The assistant states what a policy covers in fluent prose. Where the retrieved text is thin, it can sound sure and be wrong.
Recommended: Require a cited source for every coverage statement, and test accuracy on a fixed question set.
Low F7
Internal hostnames appear in the system prompt
Anything in the prompt can be coaxed out, so internal names should not be there.
Recommended: Move them into configuration the model never sees.
What we would log and block
Log
- Every tool call: who asked, which tool, arguments, result, time.
- Every refusal by a guardrail, with the rule that fired.
- Retrieved sources behind each answer, so a statement can be traced.
Block
- Refunds above the ceiling or beyond the per-claim count.
- Tool calls the user’s request does not plausibly require.
- Instructions arriving from retrieved or uploaded text, treated as data.
Suggested order of work
01
Separate the credentials and add the refund ceiling. These close the highest-impact gaps first.
02
Add tool-call logging. Every later control depends on being able to see what happened.
03
Handle untrusted document content, then add blocking rules and alerts.
04
Cite-or-refuse on coverage answers, and measure accuracy on a fixed question set.
What this sample is, and is not
- It shows the shape of the deliverable. A real review is written for your system.
- No review can promise that nothing gets through; the aim is to reduce risk and leave you evidence.
- Implementing the fixes is scoped separately after the review.
Want this for your own system?
Tell us what it is and we’ll get back to you within 48 hours.
Get in touch