The NIST AI RMF says third-party models, data and software must be governed, mapped and monitored like your own, with contingency plans if they fail. For an AI agent platform, the third party is a chain: a model provider, the platform, its connectors and its data feeds. You answer for what the agent does on your systems, whoever built it.
What does the framework say about third parties?
Third-party risk appears in three of the four functions of the NIST AI Risk Management Framework 1.0. In substance:
- Govern asks for policies and procedures that address risks from third-party software, data and AI, including intellectual property concerns, and contingency processes for failures in third-party systems considered high-risk.
- Map asks for risks and benefits to be mapped for every component of the system, including third-party data and software, and for the organisation to understand what it is relying on.
- Manage asks for third-party risks to be monitored regularly with controls applied, and for pre-trained models from others to be monitored as part of normal operation.
The framework is voluntary. Our glossary entry on the NIST AI Risk Management Framework gives the overview.
Who does this apply to?
Every organisation that adopts the framework and uses AI it did not build entirely itself, which is nearly all of them. For agents, the deploying firm is responsible for its own use of the agent even when the agent, the platform and the model all come from suppliers.
What is different about a platform that runs agents?
A vendor of a scoring model supplies one component with one output. An agent platform supplies the machinery that lets software act on your systems. That changes what can go wrong and where.
The supply chain is deeper. Behind the platform sits at least one model provider, which may change its model without asking you. Connectors reach your ledger, ticketing system or payment rail. Data feeds bring in facts from outside. A failure at any layer becomes an action on your customer's account.
Authority may live with the vendor. On some platforms, the limits on what an agent may do are set in the vendor's configuration. If the vendor changes a default, your agent's authority changes with it.
Evidence may live with the vendor too. If the record of what the agent did, and why, is held only by the platform, you depend on it to answer your supervisor.
Concentration builds quietly. Several agents in different business lines may rely on the same model provider. One model change affects all of them on the same day.
What should you ask an agent vendor?
The framework's outcomes translate into a short list of questions. Ask them before you sign and again at each review.
- Which model providers sit behind the platform, and how will you tell us when a model changes?
- Who sets the limits on what each agent may do, and can you change them without our approval?
- Can we see, export and keep the full record of every action and the decision behind it?
- How is each agent tested before it acts, and is it tested on our cases or on yours?
- How are facts reaching the agent labelled by source, so untrusted inputs cannot trigger actions?
- What happens to our agents if your platform or your model provider fails, and how do we stop them?
- Do you train or adjust models on our data?
Take an illustrative case. A consumer lender buys an agent platform for customer service. Due diligence finds that the platform's model provider can update its model at any time, and that the platform keeps logs for a short period only. The lender writes three things into the contract: notice of model changes, a right to export complete action records, and an agreed process to cut agents to read-only during an outage. It then re-tests its agents on its own cases whenever a change notice arrives.
How do you meet the framework for agent platforms?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Third-party policy | Policy covering model providers, agent platforms, connectors and data feeds | Approved policy |
| Map third-party components | Supplier register per agent: model, platform, connectors, data sources | Component inventory |
| Due diligence | Standard question set for agent vendors, answered and reviewed | Completed due diligence file |
| Contractual controls | Change notice, log export, audit rights, no training on your data | Signed contract terms |
| Monitor third-party changes | Model change triggers re-testing on the firm's own cases | Change notices linked to test results |
| Contingency | Documented fallback: agents cut to read-only or stopped; work returns to staff | Contingency plan and test of it |
| Concentration | Map which agents share each model provider | Concentration report |
Banks will meet overlapping supervisory expectations; see OCC third-party risk and agent vendors. In the EU, ask also whether agent vendors are ICT third-party providers under DORA.
What will a supervisor, auditor or customer ask?
- Which suppliers stand behind each agent, down to the model?
- How do you learn of a model change, and what did you do after the last one?
- Can you produce the full action record for an agent without the vendor's help?
- Who can change an agent's limits: you or the vendor?
- What is your exit plan if the platform fails or you leave it?
What does the framework leave out?
It does not tell you how much due diligence is enough, what contract terms to require, or how to tier suppliers. It does not create legal duties. Binding third-party rules come from elsewhere: banking supervisors, DORA in the EU and the EU AI Act's split between providers and deployers. Our piece on the EU AI Act and third-party agents you buy covers the last. For the full map, see our guide to AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme keeps authority and evidence with the customer. Limits are the customer's own bounds within the minimum chain, and every verdict is filed in an append-only record the customer can reconstruct. We never update model weights for a customer, and a change of model provider sends affected agents back through Attest before they regain depth.
Questions people ask
Is a model provider a third party if we only use it through an agent platform?
Yes. It is a fourth party from a contract point of view, but it is part of the agent's supply chain, and its changes reach your customers. Map it and require notice of changes through your platform contract.
Does vendor certification remove the need for our own testing?
No. Certification of a vendor tells you about the vendor's controls. It does not tell you how a specific agent behaves on your cases, with your sources and limits.
What is the most common gap in agent vendor contracts?
Evidence. Firms agree service levels but forget to secure a complete, exportable record of agent actions and the reasons behind them, which is what a supervisor will ask for after an incident.