Illustrative sample

Sample AI security review

What the end of an AI security review looks like. This is an illustrative report on a fictional system. It shows the structure and level of detail of the real deliverable, and contains no client data.

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

ToolReachesCan change things?Control in place today
search_policy_docsPolicy document indexNoNone needed beyond index access
lookup_customerCustomer record (read)NoOne shared service account
draft_emailOutbound email draftsDrafts onlyAgent reviews before sending
update_claim_statusClaims system (write)YesOne shared service account
issue_refundPayments (write)YesAmount 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.

Related

Want this for your own system?

Tell us what it is and we’ll get back to you within 48 hours.

Get in touch