Vendor assurances are not your governance

A provider's certificates, attestation reports and contractual promises describe how the provider runs its platform. They say nothing about what your agents are allowed to do in your business, who approves their held actions, or whether they behave correctly on your cases. Those decisions, and the evidence behind them, stay with you whoever supplies the agent.

What do vendor assurances actually cover?

Usually a lot, and all of it useful. A SOC 2 report attests to the provider's controls over security, availability, processing integrity, confidentiality and privacy. An ISO/IEC 27001 certificate shows an information security management system is in place. An ISO/IEC 42001 certificate shows the provider runs a certified AI management system. Contracts add commitments on data handling, uptime, incident notification and model behaviour.

Each of these answers a question about the provider: is its infrastructure secure, does it manage its own AI risks, will it tell you if something breaks. Those are questions you must ask, and the answers belong in your third-party risk file.

What they do not answer is the question regulators and customers will ask you: was this agent authorised to take this action, in your business, for this customer, and can you show it?

Where does the provider's responsibility end and yours begin?

The split is similar to the shared-responsibility model in cloud computing. The provider is responsible for the platform. You are responsible for how you use it.

The right column is your governance. No provider can fill it in for you, because it depends on your processes, your customers and your appetite for risk. Our explainer on what AI governance is describes the broader scope; for agents, see what AI agent governance is.

Why can't a provider certificate stand in for your evidence?

Because it is evidence about a different thing. A certificate tells you the provider tested its own system against its own criteria, or that an auditor checked its processes. It does not tell you how an agent handles your complaints, your refunds or your supplier changes.

An agent that performs well on a provider's benchmark may perform poorly on your work, because your cases have quirks no benchmark captures: product terms, historical exceptions, customer segments, the way your team writes notes. The only evidence that an agent can be trusted with a capability in your business is evidence from your cases. That is why authority should be certified per agent and per customer, not per vendor.

Provider assurances also age. A report covers a past period. Models and platforms change between reports. Your own evidence, refreshed as the agent works, is the only view that stays current.

What do provider guardrails leave undecided?

Providers build in rules that apply to everyone: block certain content, refuse certain categories of request, prevent certain actions across all customers. Those are worth having, and you should know what they are. But they are set to a general standard, not yours. A guardrail that stops an agent disclosing card numbers does not stop it issuing a refund above your limit. Our article guardrails are not governance explains the gap.

If you rely on the provider's guardrails as your only control, you have accepted the provider's view of acceptable risk as your own, without deciding to.

Who inside your organisation should own this?

Not procurement alone. Procurement can collect assurances and negotiate terms. It cannot decide what a claims agent may approve or who should review a held payment. Those decisions belong to the people who own the processes, with risk, compliance and technology in the room.

A cross-functional committee usually works best for setting the framework and approving material agents. Our guide on who should sit on an AI governance committee suggests a membership. The committee's policy should say explicitly that provider assurances are an input to third-party risk management and not a substitute for agent-level authority, approval and evidence; our guide on writing an AI agent governance policy shows where that sits.

What should you ask a provider, and what should you ask yourself?

Ask the provider for its assurance reports, its incident history, its guardrail list, how it notifies you of model changes, and how its platform lets you set bounds, hold actions for named people and export the decision record. These tell you whether the platform can support your governance.

Then ask yourself the questions the provider cannot answer. What may each agent do, at what depth? Who decided, and on what evidence from our own work? Who approves held items, and do they have time? What does our record show about refusals, holds and attempts beyond bounds? When was each agent's authority last renewed? If you cannot answer those, the provider's assurances are covering a gap they were never meant to cover.

What is the trade-off?

Doing your own governance on top of a provider's assurances costs time and expertise, and it can feel like duplicated effort. Buying a well-assured platform is supposed to save work.

It does save work: on infrastructure, security and platform-level controls. It cannot save the work of deciding authority and proving it on your cases, because that work is about your business. Take the list of agents you run on third-party platforms and, for each one, mark whether the bounds, approvers and evidence are documented by you or assumed from the provider. Anything assumed is a gap. The structure for closing it is in our guide to agent governance as a bound, not a model.

Where Pryme fits

Pryme is itself a provider, so the same rule applies to us. Our platform controls cover our platform. What each of your agents may do is set by its role's ceiling, your own limits and evidence from Attest on your own cases. You name the approvers, and the verdict record is yours to read and export.