Most AI agent security reviews do not start with a dramatic red-team scenario. They start with a buyer, a security lead, or a platform owner asking plain questions: what can the agent access, what can it change, where can data go, and what evidence exists if something goes wrong?
Those questions sound basic, but they are often where an AI agent deal slows down. A demo may show a useful workflow. A product page may mention guardrails. Neither proves that the agent is ready to handle customer data, trigger tools, use a browser session, retrieve private knowledge base content, or make decisions near production systems.
This guide lists the security review questions buyers are likely to ask before approving an AI agent. It is written for teams selling, deploying, or internally launching AI agents that use tools, RAG, memory, customer records, browser automation, ticketing systems, or write actions. The goal is not to create a giant compliance binder. The goal is to have decision-ready evidence before the review meeting starts.
1. What can the agent access?
The first buyer question is usually about access. Reviewers want to know which systems the agent can read, which records it can see, and whether access is inherited from the user, assigned to the agent, or granted through a shared service account.
A weak answer is: “The agent only accesses what it needs.” A better answer names the systems, scopes, roles, tenant boundaries, and the mechanism that enforces them. If the agent can search tickets, read documents, inspect CRM records, or open browser pages, the reviewer needs to know where those permissions are checked.
Prepare evidence such as an access matrix, service account scopes, user delegation rules, tenant isolation tests, and examples of denied access. The denied examples matter. They show that the boundary is enforced, not only described.
2. What can the agent change?
Read-only agents are easier to approve than agents that can write, delete, send, publish, refund, update permissions, or trigger customer-facing actions. The moment an agent can change state, the review shifts from content quality to operational control.
Buyers will ask which actions are allowed, which are blocked, which require human approval, and whether approval is scoped to the specific action. “A human is in the loop” is not enough if the approval screen does not show the payload, affected records, destination, and risk category.
Prepare a tool inventory with read/write classification, approval requirements, example approval records, and blocked-action traces. If the agent can draft an email but not send it, or suggest a refund but not issue it, make that separation explicit.
3. Where can data leave the environment?
Data movement is one of the fastest ways to lose reviewer trust. An agent that summarizes customer data is one thing. An agent that can send that data to an email address, webhook, spreadsheet, third-party app, or browser form is another.
Security reviewers will ask whether destinations are allowlisted, whether new destinations require approval, whether sensitive fields are redacted, and whether the agent can be tricked into exporting data through a normal-looking productivity request.
Prepare destination allowlists, data classification rules, redaction examples, egress logs, and test cases for unapproved email addresses or webhooks. This is especially important for agents connected to support, sales, HR, finance, or internal knowledge bases.
4. How do you handle prompt injection?
Buyers are starting to understand that prompt injection is not only a chat problem. It can arrive through retrieved documents, web pages, tool responses, emails, tickets, comments, or pasted customer content. The practical question is whether the agent treats untrusted content as data or lets it become an instruction.
A credible answer explains the trust boundaries between system instructions, developer policies, user requests, retrieved content, and tool output. It also shows test results. A policy statement without tests is not enough for a serious review.
Prepare prompt injection fixtures, RAG attack examples, browser-page injection examples, tool-output injection examples, and traces showing the agent ignored or quarantined hostile instructions. Link each example to the control that caught it.
5. What evidence is logged?
When something goes wrong, the buyer will not want a vague transcript. They will want to know what the user asked, what context was retrieved, what tools were called, which policy fired, who approved the action, and what final output or side effect occurred.
Good evidence does not mean logging everything forever. It means keeping enough structured information to investigate incidents without leaking sensitive data into analytics or debug logs.
Prepare a sample trace, retention policy, redaction policy, approval log, tool-call log, and incident reconstruction example. The sample trace is often more convincing than a long verbal explanation because reviewers can see how decisions are recorded.
6. What happens when confidence is low?
Many agent failures are not caused by an attacker. They happen because the agent has partial context, stale documents, conflicting policies, missing permissions, or ambiguous user intent. Buyers will ask whether the agent guesses, asks for clarification, cites uncertainty, or escalates.
Prepare examples where the agent refuses to over-answer. Show a case with conflicting retrieved sources, a case with missing account context, and a case where the agent routes to a human because the evidence is incomplete. This helps buyers see that the agent is designed for production reality, not only happy-path demos.
7. How are model, prompt, and tool changes tested?
Security approval is not a one-time event. A model change, prompt rewrite, retrieval setting update, new tool, or approval UX change can alter behavior. Buyers increasingly ask how the team prevents a safe demo from becoming an unsafe release three weeks later.
Prepare regression tests for prompt injection, tool permissions, data movement, approval scope, sensitive data handling, and grounded answering. Store the last-run date, version, result, owner, and release decision. If a test fails, the release process should make the failure visible before production.
8. Who owns unresolved risk?
Some risks will not be fully removed before launch. That can be acceptable if the risk is understood, documented, mitigated, and owned. It is not acceptable when nobody can say who accepted the risk or what would cause the decision to change.
Prepare a risk register with severity, owner, mitigation, residual risk, decision date, and review date. For customer-facing reviews, translate this into plain language. Buyers do not need every internal debate, but they do need to see that risk is governed rather than improvised.
9. What should be in the review packet?
A useful AI agent security review packet should include the architecture diagram, tool inventory, access matrix, data movement map, approval policy, guardrail test results, prompt injection tests, sample traces, incident response flow, release regression process, and known limitations.
Keep it concrete. A short packet with real evidence beats a long packet full of promises. If a control is not implemented yet, say so and name the temporary mitigation. Reviewers are usually more comfortable with an honest limitation than with a polished claim that cannot be verified.
Related resources
- Sample AI Agent Readiness Audit Report
- AI Agent Readiness Audit
- AI Agent Guardrails Hub
- AI Agent Guardrail Evidence Pack for Customer Security Reviews
- AI Agent Guardrail Testing Examples
If you are preparing an agent for a customer security review, run the AI Agent Readiness Self-Assessment or request an AI Agent Readiness Audit.