AI Egress Controls: Decide What May Leave a Private Avatar

A private AI avatar should not have general internet access. Keep model and rendering workers on networks with no arbitrary outbound route, then send each genuinely necessary external connection through a policy-enforcing egress gateway. That gateway should know which workload is calling, which destination is permitted, what data may cross the boundary and how the service must fail when the connection is unavailable.

This is the practical answer to AI egress control. It is stricter than putting an avatar behind a firewall, but more useful than claiming that nothing ever leaves. A real-time service may need media relay, identity metadata, an approved model API, a system-of-record call, updates or operational signals. The architectural task is to make every exception explicit, minimal and revocable.

Data residency and egress answer different questions

Data residency asks where information is stored or processed. Egress policy asks what a running workload may send beyond a defined trust boundary, to whom and for what purpose. A system can satisfy a residency requirement while still making poorly governed outbound requests. Conversely, a tightly restricted service may deliberately use one external API under a documented exception.

Start with the data-flow map for the complete avatar journey, but add a decision to every boundary crossing: internal, approved egress or prohibited. Do not infer the answer from the product label. “On-premise”, “private cloud” and “sovereign cloud” describe hosting arrangements; none proves that network egress is absent.

The UK National Cyber Security Centre’s secure AI deployment guidance recommends appropriate access controls for AI APIs, models and data, segregation of sensitive environments, controls against exfiltration, secure defaults and transparency about where data may be used, accessed or stored. Those principles become operational only when the network can enforce them independently of a model response.

Inventory the outbound flows before writing firewall rules

An allow-list built from observed traffic is not an architecture. It can preserve accidental dependencies and miss flows that appear only during failure, scaling or maintenance. Build an egress register from the service design and validate it against traffic. Cover at least these seven classes:

1. Live media. Browser audio and video may use direct WebRTC paths or a relay. Signalling, STUN and TURN are separate dependencies, so document them separately. The enterprise WebRTC architecture guide explains why customer-hosted inference does not automatically create a private media path.
2. AI components. Speech recognition, language models, text-to-speech and rendering may be local, external or mixed. A hybrid stack needs a distinct rule for each remote component rather than a blanket “AI API” exception.
3. Knowledge and business systems. Retrieval, search, CRM, case management and transaction APIs should be reached through named interfaces with explicit data contracts.
4. Identity and trust. Token issuers, signing-key discovery, certificate-status checks and enterprise directories can create essential outbound dependencies even when inference is local.
5. Updates and artefacts. Model registries, package repositories, vulnerability feeds, licence checks and configuration distribution belong to a maintenance path, not the conversational path.
6. Operations and support. Metrics, traces, alerts and remote support may leave the environment only if their content, destination and retention are approved. Private deployment is compatible with useful monitoring without exporting conversation content; see the guide to privacy-aware on-premise AI observability.
7. Platform dependencies. DNS, time synchronisation, certificate authorities, container control planes and service discovery are easy to overlook. Treat them as designed dependencies with owners and failure behaviour.

For each flow, record the initiating workload, environment, destination, protocol, business purpose, permitted data classes, allowed fields, maximum payload and request rate, credential type, redirect policy, owner, review date and failure response. If the team cannot populate those fields, the connection is not ready to approve.

Separate the model from network authority

A prompt is not a network policy. OWASP’s prompt-injection guidance notes that indirect instructions can manipulate an LLM into interacting with other systems, and that there is no foolproof prevention inside the model. A February 2026 research preprint, Silent Egress, demonstrated a local agent leaking runtime context through outbound requests while the user-facing response appeared harmless. In that testbed, prompt-layer defences were weaker than domain allow-listing and redirect analysis. It is one study on one experimental system, not a universal benchmark, but it illustrates why enforcement belongs outside the model.

A useful private-avatar design has four zones:

1. Model and rendering workers

These workloads process speech, language or pixels but have no direct route to arbitrary external destinations. They receive bounded inputs from the orchestrator and return bounded outputs. They do not construct URLs, select credentials or decide where data is sent.

2. Conversation orchestrator

The orchestrator manages turn-taking, component calls and policy state. Its network access should be limited to named internal services and explicitly approved gateways. When a component is external, the orchestrator uses a fixed adapter rather than a general-purpose web client exposed to model instructions.

3. Action and data gateway

This is the controlled route to knowledge sources and business systems. It authenticates the workload and, where necessary, the user; checks the requested action; reduces the payload to an approved schema; applies rate limits; and produces an audit receipt. The safe action-gateway pattern for AI agents covers the authorisation side of this boundary.

4. Maintenance and control plane

Updates, model imports, configuration changes and privileged support use a separate administrative path. Production conversation workers should not gain general outbound access because an engineer needs to download an update. A controlled import process can scan, sign, stage and promote artefacts without turning every runtime pod or server into an update client.

Control destinations and payloads together

Destination controls answer where a workload may connect. Payload controls answer what it may send. Regulated buyers need both.

At the destination layer, start from default deny. Prefer private endpoints or fixed service identities where the architecture permits them. For internet destinations, allow only approved domains or address ranges, resolve them through governed DNS and decide whether redirects are rejected or re-evaluated at every hop. Block direct IP connections when the policy expects domain identity, and stop workloads from choosing alternative DNS resolvers.

Domain allow-listing is valuable but not conclusive. Shared hosting, changing provider addresses, content-delivery networks, DNS rebinding and open redirects can weaken a simple rule. TLS inspection may add visibility in some environments, but it can also break protocols, expose sensitive content to another control point and add latency. Make it a scoped risk decision rather than a universal requirement.

At the payload layer, send structured envelopes rather than free-form conversation context. Allow named fields, cap size and rate, remove unnecessary identifiers and scan for prohibited content before the request reaches the gateway. Keep reusable credentials outside prompts, model context and logs; the AI agent secrets-management guide sets out the accompanying workload-identity pattern.

Data-loss prevention can reduce risk, but it cannot prove that exfiltration is impossible. Sensitive material can be encoded, fragmented across requests or hidden in apparently valid fields. The strongest design reduces what the workload can read, what the adapter can send and where the gateway can connect. Inspection is then one layer, not the final boundary.

Choose the deployment model from the dependency map

Customer-hosted infrastructure gives an organisation direct control over routing, DNS, proxies and enforcement. It also gives the organisation responsibility for maintaining those controls, resolving certificate and connectivity failures, and coordinating updates. Yepic can support private, on-premise and sovereign architectures subject to a properly scoped implementation, but the final egress design depends on the selected speech, language, voice, rendering, identity and operational components.

Private cloud can provide strong network segmentation, managed private endpoints and elastic capacity. Public cloud can be appropriate where data classification, contract terms and operational requirements permit it. Hybrid deployment is often useful, but every external component becomes an explicit egress dependency with latency, availability, jurisdiction and data-handling implications.

“Zero egress” should be reserved for a system that can operate, administer and recover without external runtime connections. It may suit restricted networks, but only when every required component, trust dependency and update route has been designed accordingly. The restricted-network and air-gapped design guide explains why that is an engineering constraint, not a feature toggle.

Define failure before production

An approved service will eventually be unreachable. Decide what happens before the first outage. Suitable responses may include switching to an approved local component, offering a read-only knowledge journey, using scripted content, handing the user to a human or closing the session clearly.

Do not silently route to an unapproved public endpoint. A temporary loss of capability is preferable to an undocumented change in data destination. Make degradation visible to operations and understandable to the user without exposing sensitive infrastructure details.

Twelve production tests for AI egress controls

Run these tests from production-like workloads, not only from a network scanner:

1. An unlisted domain is blocked and the event identifies the initiating workload.
2. A permitted domain that redirects to an unlisted destination is stopped.
3. A DNS answer that changes unexpectedly or resolves outside the approved range is handled according to policy.
4. A direct IP request cannot bypass a domain-based rule.
5. A prompt or retrieved document cannot make the model fetch an arbitrary URL.
6. Encoded or fragmented sensitive content is constrained by the structured payload and rate limits.
7. An oversized request is rejected before it reaches the external service.
8. Tokens, authorisation headers and conversation content are absent from egress logs.
9. Loss of an approved external component activates the documented safe degradation path.
10. Revoking a workload or destination takes effect within the agreed operational window.
11. DNS, time or certificate-status failure produces a controlled result rather than an insecure bypass.
12. An audit record links the decision, workload, policy version, destination and outcome without storing unnecessary conversation content.

NIST SP 800-53 provides a broad catalogue of security and privacy controls, including the System and Communications Protection family; use it as a control source to tailor to the organisation’s risk, rather than treating one generic control as a complete AI design. The NCSC’s agentic AI cyber-risk advice published on 20 August 2026 is more specific: deny inbound and outbound network traffic by default, allow only required connections and consider service-aware proxies where domain allow-lists lack sufficient control. Neither source supplies a universal avatar firewall rule set: destinations, data classes and failure modes remain deployment-specific.

Apply the discipline to the whole user journey

Yepic’s Abu Dhabi Aviation and Oracle enterprise avatar integration involved separate development and production environments, API and iframe integration, real-time streaming, captions and microphone behaviour, WebRTC and network testing, browser remediation, cybersecurity support and ongoing maintenance. It is useful evidence that an enterprise avatar must be treated as an end-to-end service, not just a model endpoint.

That project should not be read as proof of a completed customer-hosted egress-control deployment. For a new private implementation, the correct next step is to map one representative conversation from microphone to response, identify every outbound dependency, and create an egress register before selecting firewall rules. The result is an architecture that can explain—in a security review and under failure—exactly what may leave, why it may leave and how permission can be withdrawn.