The AI Agent Vendor Security Questionnaire

A security questionnaire for an AI agent or MCP tooling vendor needs nine sections beyond what a standard SaaS security review covers: agent identity model, tenant isolation, audit export, data retention, subprocessors, model routing transparency, incident SLAs, data-use for training, and exit and data portability. A generic SaaS questionnaire assumes static human users behind a login screen; agent tooling introduces autonomous, credentialed, non-human principals that call tools and take actions with much less human oversight per action.

Why a Generic Security Questionnaire Falls Short

Most enterprise security questionnaires were built for software where a human logs in, clicks through a UI, and every consequential action has a person behind it in real time. AI agent tooling breaks that assumption in ways that a standard questionnaire doesn't probe: an agent can be invoked thousands of times without a human present for any individual invocation, a tool call can traverse multiple vendors in a single task, and the model actually processing your data can be routed dynamically in ways the calling application never sees.

None of that means the standard questions — SOC 2 status, encryption at rest and in transit, MFA support — become irrelevant. It means they're necessary but not sufficient. The sections below extend a standard review with the questions specific to agentic tooling. For the equivalent question set aimed at evaluating a full AI governance platform rather than a point tool, see An AI Governance Platform RFP Checklist.

1. Agent Identity Model

• Do agents receive distinct, first-class credentials, or do they share a service account with other agents or the calling application?
• Are agent credentials short-lived or rotatable without requiring a redeployment?
• Can you distinguish, in the vendor's logs, which specific agent instance performed a given action — not just which application or API key?
• If the vendor's product allows sub-agent delegation, is each delegated agent independently identifiable, or does delegated work appear attributed to the parent agent only?

2. Tenant Isolation

• Is tenant data logically isolated at the storage and query layer, or does isolation depend on application-level filtering that a bug could bypass?
• Has tenant isolation been independently tested (penetration test, third-party audit) and can you review a summary or attestation?
• In a multi-tenant deployment, can one tenant's agent activity affect another tenant's performance, quota, or data — even unintentionally through a shared resource?
• If the vendor offers a dedicated or single-tenant deployment option, what is the cost and lead time difference versus shared multi-tenant infrastructure?

3. Model Routing Transparency

• Which specific model or models process your data, and does the vendor disclose routing decisions, or is routing opaque behind a single product name?
• If the vendor routes requests across multiple underlying model providers for cost or availability reasons, can you pin your traffic to a specific model or provider, or exclude specific ones?
• Does the answer to the previous two questions remain stable for the life of the contract, or can the vendor change routing without notifying you?
• If a request is routed to a subprocessor's model, do that subprocessor's data-use and retention terms apply, and are they disclosed?

4. Data-Use for Training

• Can any data submitted through the vendor's product — prompts, outputs, tool call arguments and results — be used to train or fine-tune the vendor's own models or a subprocessor's models?
• If there's an opt-out, is it the default for enterprise customers, and does it apply retroactively to data already processed?
• Is this term identical in the contract and in the vendor's public documentation, or does the contract carve out different terms than what's publicly stated?

5. Audit Export

• Is every agent action — task execution, tool call, policy decision, configuration change — logged with enough structure to reconstruct what happened, by whom (or which agent), and when?
• Can logs be exported to your own SIEM or data lake, and is export real-time or batch?
• Is the audit log tamper-evident — does the vendor use a mechanism (cryptographic chaining, append-only storage, independent attestation) that would reveal after-the-fact modification? See Tamper-Evident Audit Logs with Cryptographic Proofs for what this mechanism should look like in practice.
• Can you query the audit trail by specific agent, tool, or time window without a support ticket to the vendor?

6. Data Retention

• What is the default retention period for prompts, outputs, and tool call data, and is it configurable per tenant?
• Does retention apply uniformly, or do certain data types (embeddings, cached responses, derived analytics) persist longer than the primary record?
• How is retention actually enforced — is there a technical deletion process, or is the stated retention period a policy with no verification?
• Can you request early deletion of specific records, and how is that request fulfilled and confirmed?

7. Subprocessors

• Does the vendor maintain a public, current list of subprocessors that touch your data, including any underlying model providers?
• Are you notified before a new subprocessor is added, and is there a mechanism to object?
• For each subprocessor, does the vendor's own data-use and retention commitment flow through, or does the subprocessor's separate terms apply?

8. Incident SLAs

• What is the vendor's committed notification window for a security incident that involves your data, and is that commitment contractual or aspirational?
• Does the notification commitment distinguish between a confirmed breach and a suspected one, and what triggers each?
• What information is the vendor obligated to provide in an incident notification — scope, timeline, affected data types, remediation status?
• Has the vendor run an incident response exercise recently, and can they describe (without disclosing incident-specific details) what that exercise covered?

9. Exit and Data Portability

• If you terminate the contract, what data can you export, in what format, and within what time window?
• Is there an egress cost for retrieving your own logs, audit trail, or any derived artifacts (fine-tuned models, stored embeddings)?
• What is the vendor's data deletion commitment after contract termination, and is deletion confirmed in writing?
• If the product includes agent configuration, policies, or workflow definitions, can those be exported in a reusable format, or are they locked to the vendor's proprietary structure?

Scoring the Responses

A vague or evasive answer to the retention or subprocessor questions is itself a finding. A vendor that cannot specify what happens to your data cannot be held accountable for it later, contractually or otherwise.

Using This Alongside Procurement

This questionnaire covers the security dimension of vendor evaluation. It pairs with a broader evaluation that also weighs cost structure and organizational fit, and with the prior question of whether to run this evaluation against vendors at all versus building the control internally — see Build vs Buy for AI Agent Governance and Choosing an AI Agent Management Platform.

Common Questions

Should we require answers to all nine sections from every vendor, regardless of what the tool does?

Weight by what the vendor's product actually touches. A tool that only reads non-sensitive data warrants less scrutiny on data-use and retention than one that processes regulated data or has write access to production systems. But don't skip a section just because a vendor's sales team says it doesn't apply — verify that against what the product actually does.

How is this different from asking for a SOC 2 or ISO 42001 report?

Those attestations verify that a control environment exists and was tested by an independent auditor, which is valuable evidence — but the scope of what's covered varies, and neither is designed around agent-specific questions like model routing transparency or sub-agent delegation. Use the attestation as supporting evidence for specific questionnaire answers, not as a substitute for asking them. See SOC 2 vs ISO 42001 for AI Agent Programs for how the two attestation types differ in scope.

What if a vendor refuses to answer the model routing questions, citing competitive sensitivity?

Push back specifically on the data-handling implications rather than the general routing logic — you don't need their routing algorithm, you need to know which entities process your data and under what terms. A vendor unwilling to name which model providers touch your data is asking you to accept an unknown data-processing chain, which is a legitimate reason to escalate the question or reconsider the vendor.

What Good Looks Like

• Every section has a specific, documented answer, not a general assurance.
• Model routing and subprocessor chains are disclosed and stable for the contract term.
• Audit export and retention answers are backed by a technical mechanism, not just a stated policy.
• Exit and portability terms are confirmed before signing, when your negotiating leverage is highest.
• Discrepancies between sales claims and written answers are resolved in writing before the contract is finalized.