Your AI Runs Locally. Where Does Its Traffic Go?
You move your AI stack onto your own Linux server. The model runs on your GPU. Your documents stay in a database you manage. The application is behind authentication.
Then someone asks a straightforward question: which external services did that stack contact yesterday?
Answering it can be surprisingly difficult.
A working AI deployment may include a model server, a chat interface, a document processing pipeline, an automation platform, and tools that call external APIs. Each component has its own settings and network behavior.
Local inference tells you where the model performs its computation. To understand where information can travel, you need visibility into the surrounding system.
Follow the whole request
Consider a document assistant that uses a local language model. A user uploads a PDF and asks for a summary.
Depending on its configuration, the application might send scanned pages to an external OCR service, use a hosted embedding API, or pass a search query to a web service. The final answer could still be generated entirely on your server.
This is an illustrative architecture, but the distinction matters: several components can handle information before the local model receives it.
The tools themselves often document these choices. Ollama's FAQ states that prompts and data remain unseen by Ollama when models run locally. It also describes optional cloud models and web search, with a setting to disable those cloud features.
Separately, n8n documents telemetry enabled by default in self-hosted installations, along with controls to turn it off. Telemetry, cloud inference, and a workflow's own API calls serve different purposes and need separate review.
The useful question is which of those behaviors your deployment actually uses, and whether they match your requirements.
Outbound connections deserve an owner
Outbound traffic, or egress, is traffic leaving a server or workload for another destination.
An inbound access policy answers who may reach your service. You also need to decide which external services that workload may contact. A private application can still make outbound connections if its network policy permits them.
For AI agents, that decision becomes especially important when a tool can read files, call arbitrary URLs, or execute commands. The consequences of an incorrect action depend partly on the permissions and destinations available to it. OWASP's guidance on excessive agency explains how unnecessary capabilities and permissions increase the potential damage.
Network restrictions can help contain those capabilities. Application authorization, scoped credentials, and appropriate approval steps remain necessary, especially when an allowed external service can itself receive sensitive data.
A server-wide traffic total leaves questions unanswered
Suppose your server contacts a storage provider, a model registry, and an unfamiliar HTTPS endpoint during the same hour.
A single traffic total cannot explain which workload made each connection. Attribution changes the investigation: a scheduled backup reaching storage has a different explanation from a document assistant reaching the same destination for the first time.
A useful review should answer four questions:
- Which workload made the connection? Identify the responsible service or container.
- Where did it connect? Record the destination and any reliable information about its purpose.
- How much data was sent? Keep sent and received traffic distinct.
- When was the destination first observed? Compare it with deployments, configuration changes, and expected tasks.
That last distinction matters when interpreting volume. Pulling a large model mainly brings data into the server. Uploading a backup mainly sends data out. Both can produce substantial network activity, but they tell different stories.
A small transfer deserves context too. An API key or a short confidential document does not require gigabytes of traffic.
Interpret the evidence before approving a destination
A familiar provider name helps you investigate a connection. Shared infrastructure can host many customers, however, so an IP address may not identify the specific account, resource, or recipient involved.
Likewise, frequent activity establishes that something happened repeatedly. It does not establish that the activity was intended. An unwanted integration can be present throughout an observation period and appear perfectly routine.
Traffic metadata also has limits. A destination, timestamp, and byte count do not reveal the contents of an encrypted request. Establishing whether information was disclosed may require application logs, configuration review, or other evidence.
Keep the coverage of the observation in view. A monitoring gap leaves an unanswered period. Sampling can miss short connections. A quiet report is meaningful only within what the monitoring actually observed.
Review first and make targeted changes
Start with one workload that handles sensitive information. Write down the external services it needs, then observe representative activity, including scheduled jobs and maintenance.
Investigate destinations you cannot explain. Where an optional feature causes an unwanted connection, review its configuration first. Where a network restriction is appropriate, scope it to the workload and destination, check the expected effect, and preserve a clear way to reverse it.
Repeat the review after adding tools or changing integrations. A deployment's network requirements can change even when the local model stays the same.
How nuDefend helps
nuDefend brings this review onto the Linux server. It identifies supported AI workloads and shows observed outbound destinations, traffic sent, and when destinations were first seen. Where it recognizes a destination, it provides context to help explain the connection.
On a protected server, start with:
sudo nudefend workloads
sudo nudefend egress
sudo nudefend egress review Ollama
The last command is an example for an identified Ollama workload. These commands inspect the current findings without changing network policy.
For a destination you decide to restrict, nuDefend offers a workload-specific block with a preview and an option to undo it. This review-driven control sits alongside its automatic blocking of known malicious addresses.
Container observations are sampled, so brief connections can be missed. Observation gaps are disclosed, and traffic volume alone is not classified as a data leak. Workload reports and traffic history remain on your server. See the documentation for coverage and behavior.
Self-hosting gives you the ability to control your AI infrastructure. Reviewing its outbound connections helps you turn that ability into informed decisions about where it may send information.