Fourth-Party Risk in a Customer-Hosted AI Control Plane: Subprocessors and Dependencies

What changes and what does not when enforcement is self-managed

A common assumption is that once the enforcement layer runs in the customer's cloud, the vendor's subprocessors drop out of scope. That is only partly true. What changes is location and visibility: the runtime executes in infrastructure you control, so you decide its network paths, storage regions and retention settings, and you can observe its outbound traffic directly.

What does not change is that the runtime still has dependencies. The AI execution path calls models, loads software libraries, pulls container images, authenticates through identity and secrets services, and invokes external tools. NIST describes generative AI value chains as involving many third-party components, including pre-trained models and software libraries, and names non-transparent or untraceable integration of upstream components as a risk. OWASP's LLM03:2025 makes a similar point: supply-chain risk extends beyond traditional code dependencies to third-party models and data, and a malicious LoRA adapter that compromises a base model is one of its examples.

The NIST AI RMF also states that all parties should manage risk in the AI systems they develop, deploy or use, including integrated components. Self-managed deployment therefore shrinks and clarifies the fourth-party surface. It does not transfer the responsibility away from you, and it does not eliminate the surface.

Dependency categories, data exposure and failure impact

Start the inventory with categories, then record specifics per deployment. The exposure column describes what a dependency can typically touch by design. Confirm it against your actual configuration, because the same component can behave very differently depending on what is enabled.

• Model providers and adapters: Exposure: prompts, retrieved context and outputs. Failure impact: degraded or unavailable responses, or altered behavior if a model or adapter is compromised.
• Libraries and container images: Exposure: everything the process can read in memory or on disk. Failure impact: code execution inside your boundary through a vulnerable or tampered component.
• Update and telemetry channels: Exposure: depends on what is transmitted outbound and what is accepted inbound. Failure impact: new vulnerabilities introduced by updates and patches, or unintended data leaving the environment.
• Identity and secrets services: Exposure: credentials and tokens used for model and tool calls. Failure impact: runtime cannot authenticate, or stolen credentials widen access.
• External tool and MCP server endpoints: Exposure: tool-call arguments and returned results, which may flow back into prompts. Failure impact: untrusted content re-enters the execution path, and outputs may cascade into other systems.
• Audit evidence storage: Exposure: records of what was permitted, which may contain sensitive content. Failure impact: gaps in evidence or exposure of the evidence itself.

Classifying dependencies by exposure and failure impact

A useful classification uses two questions per dependency. First, which of four data types can it touch: prompts, outputs, tool calls, or audit evidence? Second, what happens if it fails, changes unexpectedly or is compromised?

NIST's guidance for generative AI supports this approach. It recommends inventorying third-party entities with access to organizational content, maintaining approved provider and service lists, and documenting downstream impacts of dependencies such as plug-ins. It also suggests analyzing cascading impacts when model outputs become inputs to third-party plug-ins or other systems. Treat downstream consumers of outputs as part of the classification, not as a separate exercise.

For each critical dependency, also record the fallback. NIST notes that fallback and rollover options should be documented and tested, and that a fallback may be manual. A dependency that touches prompts and has no fallback deserves tighter controls and closer review than one that only touches telemetry and can be switched off. Review update paths for third-party services as a distinct risk, since NIST's draft cybersecurity profile for AI observes that updates and patches from third parties can introduce new vulnerabilities.

Responsibility, evidence and a worked example

Frameworks agree on the principle even where details differ. The NIST AI RMF is voluntary guidance, not law, but it calls for identifying and documenting internal controls for third-party AI components (MAP 4.2) and for regularly monitoring third-party resources with documented controls (MANAGE 3.1). The EU AI Act has been in force since 1 August 2024, as of November 2026. Confirm with counsel how it and any other regime that applies to you allocate duties for subprocessors, and carry those terms into your contracts.

Monitoring needs evidence. A dependency inventory shows what should happen, while evidence of what was permitted shows what did happen. This is where enforcement in the execution path supports dependency oversight: each allow, redact or block decision on a model, tool or MCP server call is a record you can review against the inventory.

Trussed is one example of this pattern. It deploys self-managed in the customer cloud with configurable retention and data residency, and enforces policy in the execution path across models, agents, tools and MCP servers. Its actions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It does not replace your dependency inventory or software bill of materials, and it does not provide model provenance. It gives you enforced control and evidence at the points where dependencies receive and return data.