Supply Chain
Signed and pinned model artifacts, tools and MCP servers, with drift detected rather than discovered.
Objective
Know and verify every model, tool, package, and protocol server your agents depend on.
Minimum bar (L2). An approved registry of models, tools, and MCP servers. Versions pinned. New additions subject to review before first use.
12.1 Controls #
| ID | Control | Minimum bar (L2) | Enforced state (L3) |
|---|---|---|---|
| SUP-1 | Signature and provenance verification | Provenance is recorded for every model artifact, container image, and tool package in use: where it came from, who approved it, and the version against which the approval was made. Verification may be performed at approval time rather than continuously at load. | Signature verification and provenance attestation for model artifacts, container images, and tool packages. |
| SUP-2 | MCP servers as privileged integrations | Third-party MCP servers are used only from an approved list, authenticated with OAuth 2.1 and PKCE where the transport supports it, and issued tokens audience-bound to the receiving server. Tool descriptions are reviewed at approval and treated as untrusted input, and local servers are sandboxed rather than run with the invoking user’s full permissions. | MCP servers treated as privileged integrations: authenticated, authorized, inventoried, version-pinned, and reviewed on the same cadence as any system granted equivalent access. An MCP server is an API gateway into your estate with an unusual client population. |
| SUP-3 | Third-party agent assessment | Vendors supplying agents or agentic features complete a security questionnaire covering agent identity, credential scope, egress architecture, telemetry, and offboarding before deployment. Absent or evasive answers are recorded as accepted risk with a named signatory rather than quietly closed. | Third-party agent assessment covering the vendor’s own agent controls, not merely their SOC 2 scope. Ask specifically about their egress architecture, their credential model, and their agent offboarding process—most vendors have no answer to the last one. |
| SUP-4 | Automated drift detection | Model versions, tool definitions, and MCP server tool schemas are pinned and recorded at approval, then compared against running configuration on a defined schedule. Re-approval is required when a previously approved server changes the tools it exposes—the rug-pull case, where trust granted once is never revalidated. An agent bill of materials, in CycloneDX or an equivalent format, makes this comparison tractable. | Automated drift detection: alert when a model version, tool definition, or MCP server capability changes underneath a running agent. |
| SUP-5 | Contractual change notification | Contracts and terms for model and agent providers are reviewed for change-notification obligations, and the absence of one is documented as accepted risk rather than overlooked. Provider changelogs and deprecation notices are monitored by a named owner. | Contractual notification requirements for material changes to model behavior, safety configuration, or data handling. |
12.2 Evidence to Request #
- The approved registry with version pins.
- Signature verification logs.
- A completed third-party assessment for one agent-bearing vendor.
12.3 Failure Modes #
- MCP servers stood up by engineering teams as convenience integrations, holding broad credentials, invisible to security.
- Model version changes shipped by a provider without notice, altering behavior beneath controls that were validated against the prior version.
- Open-weight models deployed internally with no provenance verification, on the assumption that self-hosting is inherently safer. Self-hosting changes the trust question; it does not remove it.