What Security Review Teams Actually Request
Across enterprise AI vendor evaluations in the past year, security and compliance reviewers have converged on a consistent set of requests rather than accepting general assurances of "responsible AI" practice. The pattern is evidentiary: reviewers are checking for artifacts they can independently inspect, not claims they must take on faith.
Specifically, reviewers ask whether a vendor can provide:
- Exportable, time-stamped logs of agent tool calls, including parameters and the context that triggered the call
- Internal risk documentation mapped explicitly to NIST AI RMF functions (Govern, Map, Measure, Manage), or ISO/IEC 42001 certification status, evidenced through audit or assessment records rather than descriptive claims
- A demonstrable least-privilege access enforcement mechanism at the tool-call layer, distinct from application-level role-based access control, shown live or in a sandbox
- A SOC 2 report or equivalent attestation scoped specifically to the AI system, not only to the vendor's broader corporate environment
The evidentiary standard
Reviewers are not evaluating marketing materials. They are completing structured checklists that require inspectable artifacts. A narrative description of a control does not close the same item as a demonstrable artifact of that control.
Evidence Categories at a Glance
| Evidence Category | What Reviewers Need |
|---|---|
| Agent Permission Logs | Exportable, time-stamped records of tool-call scope, parameters, and initiating context |
| Least-Privilege Enforcement | Demonstrable tool-call access boundaries, distinct from user-level role-based access control |
| Framework Alignment | Risk documentation mapped to NIST AI RMF functions or ISO/IEC 42001 controls, with supporting assessment records |
| Scoped Attestation | SOC 2 reports covering the AI system specifically, not only the corporate environment |
Where the Procurement Cycle Stalls
The security review stage is the most common point of delay when governance or auditability questions remain unresolved. This is not because governance is inherently slow to evaluate, but because vendors frequently respond to structured requests with narrative claims.
A request for exportable tool-call audit logs answered with a description of internal logging practices, rather than a sample export, typically generates a follow-up request rather than a closed item. The same pattern holds for framework alignment: a claim of "following NIST guidelines" without a documented crosswalk to the AI RMF functions leaves the reviewer unable to complete their checklist.
Each unresolved item tends to route back through legal, security, and procurement stakeholders sequentially, adding cycle time that compounds across multiple open questions rather than resolving in parallel.
Runtime Governance Is Architecturally Distinct from Pre-Deployment Risk Assessment
A recurring source of confusion in procurement conversations is the difference between pre-deployment risk documentation and runtime governance. Frameworks such as the NIST AI RMF and ISO/IEC 42001 primarily document risk assessment, mitigation planning, and management-system processes established before or independent of a live deployment.
Runtime governance, by contrast, concerns what happens while an agent is operating: whether tool-call permissions are enforced in real time, whether an out-of-policy action is blocked or flagged as it occurs, and whether the resulting activity is captured in an audit trail attributable to a specific agent identity. The Model Context Protocol's security guidance and OWASP's LLM Top 10 category for excessive agency both address this runtime layer specifically.
Reviewers increasingly ask about both categories separately. A vendor that only has pre-deployment documentation cannot answer runtime-specific questions with that documentation alone.
Pre-Deployment
- Risk assessment and mitigation plans
- Management-system audits (AI RMF, ISO 42001)
- Documented governance policies
Runtime
- Agent identity and session attribution
- Least-privilege tool-call scoping
- Real-time policy enforcement
- Exportable, time-stamped audit logs
Reviewers now request evidence for both layers separately
Conflating pre-deployment documentation with runtime governance in a vendor response typically triggers clarification requests and restarts the review queue.
Evidence to Prepare Before Active Procurement
Vendors that prepare the following before entering active procurement address the request categories reviewers actually use, rather than responding reactively after review has stalled:
- Exportable tool-call logs with timestamps, parameters, and initiating context, in a format reviewers can inspect directly
- Internal risk documentation mapped explicitly to NIST AI RMF functions, or ISO/IEC 42001 certification status with supporting records
- A demonstrable least-privilege enforcement mechanism at the tool-call layer, distinct from application-level role-based access control
- A SOC 2 report or equivalent attestation with a scope statement covering the AI system rather than only corporate infrastructure
- A clear, documented answer on whether policy enforcement occurs at runtime or only through pre-deployment assessment
The Verification Gap and Its Limits
It is worth being precise about what current evidence supports. No publicly available, independently verifiable study quantifies how much AI governance maturity reduces procurement or sales-cycle duration. Practices for producing tool-call audit trails are not standardized across vendors, so claims that specific controls make a vendor "pass review faster" describe a plausible mechanism rather than a proven outcome.
What is documented is the composition of reviewer requests and the categorical problem that unverifiable claims create: when a vendor has no attestation, no exportable logs, and no certification or framework mapping, reviewers cannot close the item regardless of the vendor's actual technical maturity.
The practical implication for product and platform leaders is that governance investment should be judged first by whether it produces reviewer-consumable evidence, not by whether it satisfies an internal governance narrative.