Test what the agent does, not what the vendor says. Assess a vendor's AI agent by listing every action it can take in your systems, running it read-only against your own past cases, tracing where your data goes, and proving you can limit, record and stop it. A named owner signs each step, and each step leaves a document.
What is a vendor agent assessment, and who owns it?
A vendor agent assessment decides whether a third party's agent may act inside your business, and on what terms. It differs from a normal software review because the product makes choices. Two installations of the same agent can behave differently on different data, so the vendor's own testing cannot stand in for yours.
The business owner of the process the agent will serve owns the assessment. Procurement runs the contract, third-party risk runs the due diligence, security reviews access and data flows, and data protection reviews personal data. The point of vendor assurances are not your governance applies throughout: a certificate held by the vendor tells you about the vendor's controls, not about how the agent will behave with your customers.
What are the steps, and who acts at each one?
- Person, business owner: writes the job description. What work the agent will do, which systems it will touch, and which actions it should never take. This becomes the yardstick for everything that follows.
- Person, procurement: obtains the capability inventory. A list from the vendor of every tool, connector and action the agent can invoke, including ones you do not plan to use.
- Person, security: maps actions to your systems. For each action, which system it changes, whether it can be undone, and which permission it needs.
- Person, data protection: traces the data. Where prompts and records go, which model provider and sub-processors receive them, how long they are kept, and whether they are used to train anything.
- Agent under test, depth 1: runs on your cases in a sandbox. Read-only, against a set of your past cases with known outcomes. Its answers, refusals and requests to escalate are captured.
- Person, business owner: scores the results per capability, comparing the agent's answers with what your staff actually did.
- Person, security: tests the controls. Can permissions be set per capability? Can actions be held for approval? Does every action produce a record you own and can export? Can the agent be suspended in minutes?
- Person, third-party risk: reviews resilience and exit. What happens if the vendor or its model provider fails, changes the model, or ends the contract.
- Person, business owner: decides, approving named capabilities for a pilot or rejecting the agent, with reasons.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Job description | Nothing | none | Defining the work and the limits |
| Capability inventory | Nothing | none | Obtaining the full list |
| Action mapping | Nothing | none | Judging reversibility and permissions |
| Data tracing | Nothing | none | Approving data flows |
| Sandbox test | Answers past cases read-only | 1 | Choosing the cases |
| Scoring | Nothing | none | Comparing with real outcomes |
| Control test | Responds to holds and suspension | 1 | Running the tests |
| Resilience and exit | Nothing | none | Accepting residual risk |
| Decision | Nothing | none | Approve, narrow or reject |
What evidence should each step leave?
- Job description: a signed one-page scope with the forbidden actions listed.
- Capability inventory: the vendor's list, dated and versioned, with any action you plan to disable marked.
- Action mapping: a table of action, target system, reversibility and permission.
- Data tracing: a data-flow diagram and the list of sub-processors, feeding your data protection impact assessment where personal data is involved.
- Sandbox test: the case set, the agent's answers and the expected outcomes.
- Scoring: a pass or fail per capability, with the failures described.
- Control test: records of a held action, a refused action and a suspension, each taken from the agent's own log.
- Resilience and exit: the contract clauses on model changes, notice, data return and log export.
- Decision: a signed approval naming capabilities and depths, or a rejection with reasons.
Which controls matter most?
You hold the limits. If only the vendor can change what the agent may do, you have no control of your own. Insist that permissions, holds and suspension sit with you, because agent governance is a bound, not a model: the limits must be yours whoever built the agent.
You own the record. Every action and refusal should be written to a store you control. A vendor dashboard you cannot export is not an audit trail.
Model changes are notified. The same agent on a new underlying model is a different agent. The contract should require notice and let you re-test before the change reaches production.
Deployment matches your data rules. Some firms need the agent to run inside their own environment; how do you deploy an AI agent on-premises? covers the trade-offs.
What should you measure during assessment?
Track the share of test cases each capability got right in plain counts ("172 of 200"), the number of refusals that were correct, the cases where the agent acted when it should have escalated, and how long suspension took in the test. Record the time the vendor needed to answer each question too; slow answers on data flows often predict slow answers in an incident.
Where does it usually go wrong?
The assessment covers the demo, not the product. The vendor shows three neat use cases; the agent can do thirty things. Assess the full inventory.
Questionnaires replace testing. A long questionnaire answered "yes" throughout says nothing about behaviour on your data. Third-party risk staff may use an agent to compile and compare answers, as discussed in can an AI agent assess third-party risk?, but someone still has to run the agent on your cases.
Business teams buy around the process. A team subscribes directly and the assessment never happens. Shadow AI agents are an access problem before they are an AI problem, so block unapproved connections at the identity layer.
Regulatory roles are not settled. Under the EU AI Act, providers and deployers carry different obligations. Agree in writing which you are for each use.
Questions people ask
Is a vendor's SOC 2 report enough to approve its agent?
No. A SOC 2 report describes the vendor's controls over its own service. It does not test how the agent decides on your cases, which actions it takes in your systems or whether your staff can stop it. Treat it as one input to the third-party review.
How long should a vendor agent assessment take?
Long enough to run the agent on a realistic set of your cases and test the controls, which is usually weeks rather than days. The data tracing and contract work often take longer than the testing.
Should the same assessment cover every customer-facing use?
No. Assess each use separately, because the same agent can be safe for answering balance questions and unsafe for agreeing payment plans. The capability list makes this practical.