An agent proven at one firm has not been proven at another. The second firm has different policies, different customers, different data and different limits, and the agent has never been tested against any of them. Certification that means something is per customer: it proves the agent on the work of the firm that will rely on it, and that firm owns the result.
Why doesn't proof travel between firms?
The same agent, with the same model and the same vendor, meets very different work in different firms. Consider two illustrative lenders using one vendor's collections agent.
The first lender has a hardship policy that pauses contact for thirty days when a customer reports a job loss. The second offers an immediate reduced payment plan instead. The first holds customer data in one core system; the second splits it across two, one of which is often a day behind. The first serves mostly salaried borrowers; the second serves many self-employed borrowers with irregular income.
An agent certified at the first lender has shown it applies the first lender's hardship policy, reads the first lender's systems correctly, and handles salaried customers well. None of that says it will apply the second policy, cope with the lagging system or recognise difficulty in irregular income. The evidence is real. It is about someone else's work.
What changes from one customer to the next?
| What differs between firms | Why it affects certification |
|---|---|
| Policies | The right answer to the same question differs; an agent correct at one firm is wrong at another |
| Sources | Different documents, data quality and provenance mean different grounding |
| Systems and tools | Different integrations fail in different ways |
| Customers | Different populations surface different edge cases and vulnerabilities |
| Limits and risk appetite | The floors and ceilings that decide depth differ |
| Regulatory context | Firms in different markets face different obligations |
Any one of these can change whether an agent should pass. In practice, several differ at once.
What does vendor certification actually tell you?
Vendors often hold certifications, and they are worth having. They answer a different question.
An ISO/IEC 42001 certificate shows that an organisation runs a certified AI management system: that it has governance, risk management and controls around how it builds and runs AI. That is useful when choosing a vendor. It is not a statement that a particular agent does your work well; the distinction is drawn out in whether AI agent certification is the same as ISO certification. A SOC 2 report attests to controls over security, availability and related areas. Again, valuable, and again, about the vendor's controls, not the agent's fitness for your cases.
A vendor that tests its own agent on its own cases has evidence about its own test set. The argument that a vendor's certification is not yours follows directly. So does the answer to whether a vendor can certify its own AI agent: it can test it, and should, but it cannot certify it for you.
Why must each agent be certified too?
Per-customer is one half of the principle. Per-agent is the other. Within a single firm, each agent is certified to one depth on its own evidence, and each action it takes carries a different risk and needs a depth of its own. The case for certifying the agent and setting the depth each action needs and the case for certifying per customer are the same argument applied in two directions: evidence has to match the exact thing being trusted.
Put together, the unit of certification is one agent, for one customer, proven on that customer's cases. Anything broader is an assumption.
Does this make certification expensive?
It costs more than relying on a vendor's word. The cost is mainly in assembling cases and labelling them, and it scales with the number of capabilities and their risk.
There are ways to keep it manageable. Start with the agents you want to grant execution, since read-only agents need lighter evidence. Reuse your cases across vendors, so switching or comparing agents does not mean starting again. Standards and published levels, such as those described in AIUC-1, autonomy levels and certification: how they fit, can help with vendor selection before you invest in certification.
The alternative cost is deploying an agent whose only evidence is about another firm. That cost arrives later, as incidents, complaints and supervisory questions.
What should you ask a vendor?
Ask for their certifications and attestations, and value them for what they show about the vendor. Then ask how the agent will be tested on your cases, against your floors, before it acts, and how often that test will be repeated. Ask who owns the result. If the vendor's answer is that its own testing should be enough, the agent has not been certified for you.
Where Pryme fits
Pryme certifies each agent for each customer. Attest replays the agent against real cases from that customer's own operation and scores every answer against the customer's floors across seven gates. The certificate belongs to the customer, lapses after 90 days, and is enforced at the moment of action. See what it means to certify an agent.
Questions people ask
Can two firms in the same group share a certificate?
Only if they share the same policies, sources, systems and limits for that agent, which is uncommon. Where any of those differ, certify separately.
Does a new customer need to start from zero?
They need their own cases and their own floors. A vendor's experience can make the agent better before testing, but the evidence that grants depth has to be the customer's.
Is per-customer certification required by regulators?
Regulators generally expect firms to understand and control the systems they rely on, including those from vendors. Per-customer certification is one practical way to show that.