What data leaves your network when you deploy an AI control plane on-prem

Start with the execution path, not the product

A reviewer asking what leaves the network is really asking what each component touches and where it sends the result. An enforcement layer that sits in the AI execution path may see traffic between users and models, between agents and tools, and between assistants and MCP servers. Each of those hops carries different data, and each can be configured differently.

NIST's preliminary draft Cybersecurity Framework Profile for AI recommends that organizations maintain representations of AI data flows, including inference request paths, to enforce defence boundaries and detect anomalies. It also notes that AI agents may have access to data sources or tools that a user typically would not. So the map has to cover tool-call paths as well as prompt and response paths. A diagram that stops at the chat interface leaves out the flows most likely to carry sensitive data.

The NIST generative AI profile adds that data and content flows within the system, and dependencies on upstream data sources, should be documented and tested. Treat the enforcement layer as one more system with upstream dependencies that need to be written down.

What the deployment model fixes and what configuration decides

Some properties follow from where the software runs. When the enforcement layer is deployed in your own cloud account or data centre, interaction content is processed on infrastructure you operate. That removes one class of vendor-hosted processing, but it does not by itself prove that nothing leaves. Licence validation, update retrieval, telemetry and support access can each create outbound connections even when the processing is local.

Other properties depend on how you configure the system: which retention period applies to evidence, which region stores it, which destinations are on the egress allow-list, and whether sensitive values are redacted before any record is written or forwarded. Reviewers should separate these two groups explicitly. A flow that is fixed by architecture needs a risk decision. A flow that depends on configuration needs an owner, a setting and a way to verify the setting.

The enforcement action itself changes what can cross the boundary. If policy redacts a sensitive value before a prompt reaches an external model, that value does not leave in the prompt. If policy blocks a request, the payload never reaches its destination. The same logic applies to evidence: what is stored depends on what the enforcement layer retained after the decision was made.

Controls that constrain and verify outbound traffic

Egress allow-listing is the primary technical control. Restrict the enforcement layer's outbound connections to named endpoints and protocols, and make your own gateways the point where those rules are applied and logged. NIST's draft guidance on AI data centre security (SP 800-239, initial public draft) describes ingress and egress gateways that can be rate-limited, and treats security monitoring and logging at data transfer nodes as essential. Verifying egress at your own gateways does not depend on trusting vendor documentation.

Encryption applies to every flow, internal and external. NIST's drafts recommend protecting data in transit and at rest, so ask who holds the keys and whether they can be held by you. Private networking limits exposure for flows that must exist. Retention settings limit how long evidence persists, and data residency settings limit where it is stored.

Change control matters as much as the initial design. NIST's draft profile describes version control and logging for configuration changes. Apply the same discipline to egress settings, so a later change to telemetry or update behaviour is visible and reviewable. Then re-verify periodically, because a data-flow map is accurate only as of the last time someone tested it.

Audit evidence: where it lives and who controls it

Evidence is where egress questions meet regulatory ones. Under the EU AI Act, providers of high-risk AI systems must keep the logs referred to in Article 12(1) that their systems generate automatically, to the extent those logs are under their control. As of November 2026, confirm current application dates against the consolidated text. The practical point holds regardless of timing: when logs sit in your environment, control over them should be allocated explicitly, along with retention period and location.

The Act's technical documentation requirements also refer to data management systems and procedures, including data storage and data retention. Reviewers and regulators looking for traceability will ask where evidence is kept and for how long. Evidence that is complete but stored in an unapproved location, or deleted before it is needed, fails the purpose it was generated for.

Trussed is deployed self-managed in the customer cloud, with configurable retention and data residency. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants (allow, redact, block, rate limit, escalate for human approval) and generates audit-ready evidence from those decisions. It generates 30+ GB of audit evidence per day, which is a useful reminder to size storage and retention deliberately.