A vendor due diligence questionnaire for AI agent platforms asks how the platform grants, proves, enforces and records what its agents may do, alongside the usual security, resilience and data questions. Send the questions below, require evidence for each answer, and score the replies against what a good answer looks like before you sign.
How is this different from a standard vendor questionnaire?
A standard questionnaire asks whether the vendor is secure and stable. That still matters, but it misses the main risk of an agent platform: an agent acting within its technical permissions and still doing something nobody authorised. You need to know how authority is decided, how it is checked at the moment of action, and how you will reconstruct a decision after the fact.
The answers should map to the controls you would expect of any governed agentic operating system. If they do not, you will be building those controls yourself around the platform.
Note the vocabulary. Vendor due diligence is a procurement control. It is not customer due diligence, the anti-money-laundering check on your own customers, although the platform may end up running parts of the latter for you.
How do you use the questionnaire?
Send the full list, but tell the vendor that each answer needs evidence: a document, a configuration screen, a test you may run. Then score each answer as strong, partial or weak. Do not average the scores. Decide in advance which questions are blocking, and let a weak answer on any of them stop the process.
If the platform will carry out financial crime work, add the sector questions at the end. The guides on whether an AI agent can perform customer due diligence and FATF customer due diligence with AI agents explain what those agents must leave to a person.
The questionnaire
| No. | Question | A good answer | Evidence to request |
|---|---|---|---|
| 1 | Is authority granted per agent or per capability? | Per capability, per customer | Configuration showing different levels for two tasks of one agent |
| 2 | How is an agent's authority proven before it acts? | Tested on our own cases against a stated floor | A certification report on sample cases |
| 3 | Does authority expire? | Yes, on a fixed cycle, and lapses automatically | Expiry setting and a lapse event in a test log |
| 4 | What is checked at the moment of action? | Role, certification, source, our limits and platform rules, all at once | A refused or held action naming the deciding rule |
| 5 | Which actions can no agent take on your platform? | A short, written list | The list and its test results |
| 6 | Where do held actions go? | To a named person, with the draft attached | An approval record |
| 7 | Can records be altered after they are written? | No; records are append-only | Attempted edit and export |
| 8 | Do you train models on our data? | No; improvements change instructions, sources and bounds, not weights | Contract clause and data flow description |
| 9 | Which model providers and subprocessors do you use? | A full list, with notice of changes | Subprocessor register |
| 10 | What security attestations do you hold? | Current SOC 2 report and ISO/IEC 27001 certification, or a plan with dates | Reports under NDA |
| 11 | Do you hold or plan ISO/IEC 42001 certification? | Held, or a stated position | Certificate or roadmap |
| 12 | How do you notify incidents? | Within a contractual time, with a named contact | Incident clause; sample notice |
| 13 | How do you support our resilience obligations? | Testing support, exit plan, data return | Exit plan; resilience test summary |
| 14 | Which party is the provider and which the deployer under the EU AI Act? | A clear statement of roles and the documents they will supply | Technical documentation index |
| 15 | How do we get a complete record of one decision? | Self-service export with sources and verdict | Sample export |
For EU financial entities, questions 12 and 13 sit inside DORA's ICT third-party risk requirements, so align the wording with your register of ICT providers.
A scored sample
A hypothetical insurer scored three answers from one vendor:
| No. | Vendor answer | Score | Note |
|---|---|---|---|
| 1 | "Each agent has an autonomy level from 0 to 5" | Weak | One level per agent; cannot hold a claims agent at read-only for payments while letting it draft letters |
| 3 | "Customers review agents annually" | Partial | Review exists but nothing lapses automatically |
| 8 | "We never fine-tune on customer data; changes are made to prompts and retrieval" | Strong | Contract clause supplied |
Question 1 was blocking for this insurer, so the process stopped there despite strong answers elsewhere.
Which questions should be blocking?
For agents that will act above drafting, make questions 1, 4, 7 and 8 blocking. If the agents will handle high-risk customers, add the evidence items from the enhanced due diligence checklist and ask how the platform keeps the final decision with a person, as enhanced due diligence requires judgement no agent should own.
Questions people ask
Should we accept a vendor's own questionnaire answers?
Accept them as a starting point only. Ask for the evidence column and run at least questions 4 and 7 yourself in a trial environment. Answers about enforcement are easy to write and hard to fake in a test.
Who should review the replies?
Procurement manages the process, but security, risk, data protection and the business owner of the first agent should each score the questions in their area. Record who scored what.
How often should the questionnaire be repeated?
At contract renewal, and whenever the vendor changes model provider, hosting or its approach to authority. Ask the vendor to notify you of those changes in the contract.