AI Control Library / CF-03: AI Supply Chain & Third-Party Risk
Designation: Core | Control types represented: Operational and Technical
Control requirement
Assess and control third-party plugins and APIs before granting AI systems access. Define approved capabilities, data flows, permissions, trust boundaries, change handling and revocation, and verify behavior at the integration boundary.
Why this matters
A plugin can turn generated text into a payment, data disclosure or configuration change. Trust in the model provider does not establish trust in the tool provider or authorize every action exposed by the API.
How the control types work together
Operational controls define acceptance, responsibility and response. Technical controls verify artifacts, observe actual use or enforce data and action boundaries. The process must cover the same deployment that the technical mechanisms protect.
When it applies
External tools, connectors, MCP integrations, action plugins and APIs called by AI workflows, including read-only tools with sensitive-data access.
Tailor review depth to information sensitivity, granted authority and business dependence. Record what the organization can test directly, what relies on provider evidence and how material visibility gaps affect the acceptance decision.
Ownership
The integration owner is accountable; security, data owners and supplier-risk reviewers approve access and operators maintain revocation capability.
Implementation guidance
- Inventory tool providers, endpoints, authentication, data destinations and actions; assess source integrity, service terms and change responsibilities.
- Grant narrowly scoped identities and actions, validating requests and separating model suggestions from independently enforced authorization.
- Treat tool descriptions and returned content as untrusted inputs; test data leakage, unintended actions, cross-user access and changed tool behavior.
- Monitor material actions, retain proportionate evidence and test credential revocation, endpoint blocking and containment of queued or delegated requests.
How to verify it
Use representative deployment records and authorized controlled tests. Establish the assessed service, artifact version and acceptance conditions before interpreting results; do not extend evidence beyond the boundary it covers.
| Test | Expected result |
|---|---|
| Attempt an action outside approved scope in an authorized test | Independent authorization prevents the action. |
| Return adversarial instructions through a tool fixture | The workflow does not expand data access or action authority based on that content. |
| Revoke the integration during active use | Further consequential requests are blocked or contained and outstanding work is accounted for. |
Record a finding when a required result cannot be demonstrated or actual practice differs materially from the accepted conditions. Assign corrective action and verify the affected boundary before closing the issue.
Evidence to retain
- Tool and API risk assessment
- Permission and data-flow records
- Boundary and adversarial test results
- Monitoring, revocation and change records
Protect supplier-confidential information, credentials and personal data in these records. Preserve enough version and scope information to establish which service or artifact the evidence supports.
If the control fails
Disable the affected action path and notify security and the integration owner when the tool exceeds approved scope or its behavior cannot be trusted. Reassess changes before restoring access.
Example in practice
Hypothetical example: An invoice agent uses a supplier lookup API. A test response includes instructions to send records to a new endpoint; independent routing and authorization block the transfer despite the model’s proposed action.
Related controls
- CF12-007: AI API Security
- CF12-008: AI Tool & Plugin Sandboxing
- CF14-005: MCP & Tool Protocol Security
Framework mappings
- NIST AI RMF (MAP 1.6)
- MITRE ATLAS
- OWASP LLM Top 10
Review and maintenance
Review at the interval approved by the control owner and after relevant supplier, component, contract, access or deployment changes. Reassess material incidents and new evidence, updating acceptance conditions and verifying corrective actions where required.
Back to AI Supply Chain & Third-Party Risk
Version 1.0