A customer security review rarely fails because the team has no security work at all. It fails because the work is scattered. One engineer knows the tool scopes. Another knows the RAG pipeline. A product manager knows the approval flow. A founder knows the customer promise. When the buyer asks for evidence, the team starts stitching answers together during the meeting.
That is a risky way to sell or launch an AI agent. Production agents sit near customer data, internal documents, browser sessions, support queues, finance workflows, and write-capable APIs. A buyer does not only need to hear that the agent is useful. They need to see whether the team understands the agent’s boundaries and can prove how those boundaries are enforced.
This article describes a practical AI agent security review packet to prepare before a customer call. It is not a certification package and it is not a replacement for a full security assessment. It is the minimum structured evidence a serious buyer, security lead, or internal approval board will expect before trusting an agent in a production workflow.
Start with the decision the packet must support
The review packet should answer one decision: can this agent be approved for the proposed production scope? If the packet tries to prove that the agent is safe in every possible situation, it becomes too vague. If it names the exact scope, the review becomes much clearer.
Write the intended scope on the first page. For example: the agent can summarize support tickets, draft replies, search approved help center articles, and suggest account actions, but it cannot send replies, issue refunds, change permissions, export customer data, or update billing without approval. That one paragraph gives every later control a reference point.
1. Architecture map
The architecture map should show where the user request enters, which model or orchestration layer receives it, which retrieval systems are queried, which tools are available, where logs are written, and where human approval can interrupt the flow. A simple diagram is enough if it names the real components.
Avoid generic boxes like “AI layer” or “backend.” Buyers need to see the trust boundaries. Mark which inputs are trusted instructions, which are user requests, which are retrieved content, which are tool outputs, and which systems can create side effects.
Good evidence includes a diagram, a component list, data stores, external services, tenant boundaries, and a short explanation of what happens when the agent cannot access a system. If the agent uses a browser session, show whether that session is isolated and what actions are blocked.
2. Tool inventory
Every AI agent with tools needs a tool inventory. It should list each tool, purpose, read/write status, permission scope, allowed arguments, blocked arguments, approval requirement, logging behavior, and owner. This is often the most useful part of the packet because tool risk is concrete.
The key distinction is not “safe tool” versus “unsafe tool.” It is what the tool can do in this product context. A search tool that only reads public documentation has a different risk profile from a CRM export tool. A browser click tool has a different risk profile from a draft-only email tool.
Include at least one denied tool-call example. Show a request that tried to send data to an unapproved destination, change a permission, or call a write API without approval. The denial trace proves the control exists outside the marketing copy.
3. Data movement map
The packet should explain where data can move. Buyers will want to know whether the agent can send information to email, webhooks, spreadsheets, third-party tools, browser forms, analytics systems, model providers, or long-term memory.
A useful data movement map names the source, destination, data class, policy, approval requirement, retention rule, and logging behavior. If sensitive values are redacted, show an example. If certain destinations are allowlisted, show how the allowlist is enforced.
Do not hide unresolved risk. If the current implementation relies on manual review for some data movement, say so and explain the temporary limit. Honest limits are easier for a buyer to approve than vague claims that no data can ever leak.
4. Prompt injection and untrusted-content tests
Prompt injection belongs in the packet because customer reviewers increasingly know that agents can be steered by documents, webpages, tickets, emails, and tool responses. The packet should show that the team has tested indirect prompt injection, not only obvious malicious chat messages.
Prepare a small set of fixtures: a RAG document containing hidden instructions, a tool response pretending to be a system message, a browser page telling the agent to click an approval button, and a user request that tries to combine a normal task with a data export. For each fixture, show the expected behavior and actual trace.
The best result is not always a refusal. Sometimes the right behavior is to ignore the hostile instruction, answer only from trusted sources, ask for approval, redact sensitive content, or escalate. The packet should connect each outcome to a named control.
5. Approval policy and approval records
If the agent can trigger actions, the packet must explain approval. Approval should be scoped to a specific action, payload, destination, and risk level. A generic “approved by human” note is too weak for write-capable agents.
Show what the approver sees. The approval record should include the requested action, affected account or object, tool name, arguments, data destination, policy reason, requester, approver, timestamp, and final decision. If an approver can edit the action before approving it, show how that edit is logged.
Also show a rejected approval. Rejections demonstrate that the process can stop the agent, not only rubber-stamp it.
6. Logging and incident reconstruction
Buyers often ask what happens if the agent makes a bad decision. The packet should answer with an incident reconstruction example. Pick one realistic failure: wrong retrieval, blocked tool call, sensitive data redaction, approval rejection, or conflicting policy sources.
Show the trace fields that would let a reviewer reconstruct the event. Useful fields include user request, retrieved source IDs, trust labels, tool calls, tool arguments, policy checks, approval records, final answer, and redaction decisions. Avoid logging raw secrets or unnecessary personal data.
This section is especially important for enterprise buyers. They do not expect zero incidents. They expect the team to detect, explain, contain, and improve from incidents.
7. Known limitations and risk decisions
A review packet that claims everything is solved is usually less believable than one that names the remaining risks. Known limitations help the buyer understand the real operating boundary.
List open risks with severity, mitigation, owner, decision date, and review date. For example: browser automation is limited to approved domains; refunds above a threshold require manual approval; memory is disabled for regulated accounts; export destinations are restricted to allowlisted domains; prompt injection tests run before model and tool changes.
Make sure every limitation has an owner. A limitation without an owner becomes background noise. A limitation with an owner becomes governed risk.
8. Release and regression process
The packet should explain how the team keeps the agent safe after the customer call. Model changes, prompt edits, retrieval updates, new tools, and approval UX changes can all change behavior. Security reviewers want to know how the team catches regressions before production.
Prepare a release checklist that includes guardrail regression tests, prompt injection fixtures, tool permission tests, data egress tests, approval-scope tests, and logging checks. Store the last-run date and release decision. This converts safety from a one-time claim into an operating process.
What to send before the call
Do not send a giant internal document. Send a concise packet with the architecture map, scope statement, tool inventory, data movement map, prompt injection test summary, approval sample, trace sample, known limitations, and review contact. Put deeper evidence behind links or appendices.
The packet should make the buyer feel that the team has already done the hard thinking. If the buyer has to discover every boundary during the call, the review will feel immature. If the packet names the boundaries and shows evidence, the conversation can focus on fit, exceptions, and next steps.
Related resources
- Sample AI Agent Readiness Audit Report
- AI Agent Security Review Questions Buyers Ask Before Approval
- AI Agent Guardrail Evidence Pack for Customer Security Reviews
- AI Agent Guardrail Testing Examples
- AI Agent Readiness Audit
If your team needs an independent review before a customer security call, run the AI Agent Readiness Self-Assessment or request an AI Agent Readiness Audit.