AI Agent Security: The Review Checklist Buyers Actually Use

Security review is where AI agent deals stall. Here is the checklist reviewers work from — and the documentation that answers it before they have to ask.

July 28, 2026 · 9 min read

AI agent deals rarely die in security review because the product is insecure. They die because the answers arrive in fragments, over three weeks, in email. A security reviewer working from a checklist will accept a documented risk far more readily than an undocumented reassurance. The goal is not a perfect posture — it is a legible one.

1. Data flow and residency

• Which model providers process customer data, and under what contract
• Where inference happens geographically, and whether the region is pinnable
• Whether prompts, outputs, or tool results are retained, and for how long
• Whether any customer data is used for training or fine-tuning — state this explicitly, even when the answer is no
• Sub-processor list, kept current, with a change-notification commitment

One diagram answers most of this. Publish it in the paper rather than emailing it on request; the request itself adds a week.

2. Identity, permissions, and scope of authority

An agent that acts inside a customer's systems is an identity, and reviewers treat it as one. Document how the agent authenticates, which scopes it holds, whether permissions are per-tenant or shared, and how least privilege is enforced. Then document the scope of authority in business terms: which actions run unattended, which need approval, which are prohibited.

3. Prompt injection and tool abuse

This is the question that separates vendors who have deployed from vendors who have demoed. Untrusted content — an inbound email, a web page, a PDF — can carry instructions. Explain your controls: input isolation, tool allow-lists, output validation, confirmation on irreversible actions, and evaluation suites that include adversarial cases. Naming the attack class and your mitigation earns more trust than any certification badge.

Reviewers are not looking for a vendor with no risks. They are looking for a vendor who already knows what their risks are.

4. Audit logging and reconstruction

• Is every agent action logged with inputs, tool calls, and outputs?
• Can a specific decision be reconstructed months later for an auditor?
• Are logs exportable to the customer's SIEM?
• What is the retention period, and who can access the logs?

5. Evaluation, monitoring, and drift

Models change. Reviewers want to know how you detect regression: what your evaluation suite covers, how often it runs, what happens when a provider ships a new model version, and what your rollback procedure is. A written change-management policy for model updates is unusual enough that it becomes a differentiator.

6. Certifications, and what they do not cover

SOC 2 Type II, ISO 27001, and a completed CAIQ or VSA questionnaire shorten the process. None of them answer agent-specific questions about autonomy, injection, or reconstruction. Provide both: the certification for the procurement checkbox, and the agent-specific documentation for the engineer who reads past it.

Put it in writing before the review

Every item above can be answered in eight to twelve pages. Vendors who publish that document find the security review compresses from weeks to days, because the reviewer's first pass is reading rather than asking. That is the document we write for AI agent companies — under your brand, in four weeks.