Hold them to the same bounds as agents you build. A vendor's agent should be registered, owned by your process owner, tested on your own cases, limited by your rules at the moment it acts, and recorded in a way you can inspect. Write the conditions into the contract: notice of model changes, access to decision records, and the right to restrict or suspend.
Why can't you rely on the vendor's assurances?
A vendor can tell you its agent is tested, safe and compliant. Those claims describe the vendor's tests on the vendor's data. They say nothing about your customers, your products, your limits or your exceptions. A claims agent that performs well across the vendor's other customers may still misread your policy wordings.
Vendors also change things. A new model version, a revised prompt or a new feature can change behaviour overnight. If your governance depends on the vendor, it changes when they do.
What are the practical steps?
- Register the agent. Every vendor agent goes in your register with an internal owner. Our answer on how to govern AI agents across a whole company covers the register.
- Map what it can do. List every action the vendor agent can take in your systems. Many products ship with more capabilities switched on than you need.
- Switch off what you don't need. Narrow the agent's capabilities to your use.
- Test on your cases. Before go-live and after each significant vendor change, run the agent on your own historical cases and score the results.
- Put your limits in front of its actions. Where possible, route the agent's actions through your own enforcement layer, so your limits apply regardless of the vendor's settings. Where not possible, limit the access its service identity holds.
- Get the record. You need each decision, its inputs and the reason it was allowed, in a form your auditors can read.
- Contract for change. Notice of model and behaviour changes, with time to retest.
What should the contract cover?
| Term | Why it matters |
|---|---|
| Notice of model or behaviour changes | So you can retest before the change reaches your customers |
| Access to decision records | So you can reconstruct and audit decisions |
| Your right to restrict capabilities | So you set what the agent may do, not the vendor |
| Suspension on request | So you can stop it quickly without terminating the contract |
| Data use limits | Your data is not used to train for other customers without consent |
| Where data is processed | For privacy and, in some sectors, residency rules |
| Exit and data return | Records and data come back to you when the contract ends |
| Incident notification | You hear about problems that affect you promptly |
For EU financial entities, DORA's ICT third-party risk rules apply to these arrangements, and many of these terms will already be on your list.
Do the vendor's guardrails count?
As one layer, yes. As your governance, no. A vendor's guardrails reflect the vendor's view of acceptable behaviour, not your limits. Our answer on whether a model's own guardrails can govern an AI agent explains why. The principle is to govern the action, not the model: whoever built the agent, its actions in your business meet your bounds.
A worked example
Take a lender that buys a collections platform with a built-in agent. Out of the box, the agent can send messages, set up payment plans of any length and waive late fees.
The collections manager registers the agent, switches off fee waivers, and caps payment plans at six months with anything longer held for a person. Testing on the lender's past arrears cases shows the agent sometimes misses signs of vulnerability in difficult cases, so those cases are routed to specialists before the agent drafts anything. The contract adds 30 days' notice of model changes. When the vendor announces a new model, the lender reruns its cases before the change goes live.
Which controls make the answer hold?
- Internal ownership of every vendor agent.
- Your tests, your cases.
- Your limits enforced at the action, where the architecture allows.
- Records you can read without asking the vendor each time.
- Change notice and retesting.
- A management system above it. The NIST AI RMF Govern function for AI agents covers third-party AI in its accountability structures.
The board should see vendor agents in the same report as your own, by what they may do; see boards should govern agent authority, not agent technology. The topic guide, agent governance is a bound, not a model, explains the underlying principle.
Questions people ask
What if the vendor won't give us decision records?
Then you cannot audit or reconstruct its decisions, and you should limit it to low-impact work or look elsewhere. Records are not optional for agents that act.
Should vendor agents be tested as often as our own?
Yes, and at every vendor change you are notified of. If notice is unreliable, retest on a fixed schedule as well.
Is a vendor's certification enough?
It is useful evidence about the vendor's processes. It is not evidence about how the agent performs on your cases.