Can an AI Control Plane Run Behind Your Firewall Without the Vendor Seeing Your Data?

What "behind your firewall" should mean

A self-managed deployment of runtime AI policy enforcement places the enforcement point in the execution path, between applications or agents and the models and tools they call. Four things need a location: the data plane that handles live requests and responses, the policy engine that evaluates them, the store that holds evidence of each decision, and the configuration for retention and data residency. In a self-managed model, all four run in your cloud account or network, and your team operates them.

Running in your cloud is necessary but not sufficient. A vendor-operated service deployed into your account, with standing remote administrative access, can still reach content. Conversely, a deployment with no standing access and narrowly restricted outbound connections can keep the vendor out of the content path. The question is therefore not where the software runs but which connections and access paths exist between that software and the vendor.

At one end of the range sits an air-gapped architecture with no outbound connectivity at all. Most regulated enterprises will land somewhere short of that, permitting a small number of known connections. Each permitted connection is a flow that must be understood and tested.

Patterns that keep content inside the boundary

Four patterns do most of the work. Deployment in your own cloud account puts the data plane and evidence store under your administrative control. Private networking keeps inference traffic off public paths. Customer-managed encryption keys mean evidence at rest cannot be read without a key you control and can revoke. Egress restrictions limit the enforcement component to an explicit allowlist of destinations, which turns a vendor's description of its network behavior into something you can enforce.

Each pattern is verifiable. Review the deployment topology to confirm components run in accounts you administer. Check routing and security group configuration for private paths. Confirm in your key management system that you hold the keys and can see their usage. For egress, run a test: restrict outbound traffic to a minimal allowlist in a test environment, then confirm that enforcement, evidence writing and retention still function. Any failure reveals a dependency the vendor did not describe.

Also inventory every outbound dependency of the enforcement component, including model providers, licensing endpoints and update channels. NIST's AI Risk Management Framework notes that risk management can be complicated by how customers integrate third-party data or systems into AI products, particularly without sufficient internal governance and technical safeguards. A dependency inventory is a basic form of that safeguard.

Zero trust principles point the same way. NIST's draft guidance on AI data center security describes zero trust as limiting damage even when one component is compromised. Applied here, treat a vendor-supplied component and any vendor-initiated connection as untrusted by default, and grant only the access you can justify.

Regulatory and governance considerations

As of November 2026, Regulation (EU) 2024/1689, the EU AI Act, states that it does not affect existing Union law on personal data processing. It also leaves in place the obligations of providers and deployers as data controllers or processors where AI design, development or use involves personal data. For a buyer, this means any vendor flow that could carry personal data in prompts or outputs still raises a controller and processor question under data protection law. Keeping content inside your boundary reduces the number of flows that need that analysis.

The Act's recitals also describe compliance measures such as anonymisation, encryption, and technology that brings algorithms to the data without transmitting or copying raw data between parties. Those references sit in a different context, but the principle is a useful design test for any enforcement deployment: prefer moving the logic to the data over moving data to the logic. The Act's text further ties deletion to purpose, which supports setting retention periods deliberately and not by default.

Residency, third-party access and retention requirements differ across HIPAA, GDPR, NYDFS and sector rules. Have counsel confirm which apply to your deployment and what they require of evidence storage and vendor access. Separately, track the vendor's no-visibility claim as a third-party risk item with an owner and a re-verification date, because updates and configuration changes can alter data flows after initial approval.

Where Trussed fits

Trussed enforces policy in the execution path: interactions and tool calls are allowed, redacted or blocked at runtime, not reviewed after the fact. That enforcement produces audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency, so evidence is stored in the customer environment.

Treat that description the way this guide recommends treating any vendor's: as the starting point for the flow-by-flow review above. The same diagram request, egress test, key ownership check and support-access questions apply, and a vendor that welcomes them is easier to approve than one that does not.