Auditing Network Traffic From Local AI Tools

Auditing network traffic from local AI tools means testing what leaves the machine. A useful audit covers exposed ports, outbound connections, agent actions, configuration secrets, and browser extensions, then pairs network evidence with endpoint controls. Vellum offers a governed workflow layer for teams that build AI products, but it must be part of a wider audit program.

Why "local" AI tools still carry network exposure risks

Ollama makes no network requests during inference and can run fully disconnected after a model is downloaded. That is an important starting point because it puts the threat model in the right place. The inference engine itself is not the exposure point. For tools such as Ollama and LM Studio, “local” describes where inference runs, while the surrounding infrastructure's network use remains a separate concern.

Ollama's default port, 11434, carries no built-in authentication, so any device on the same network can send prompts and read responses if the port is reachable. “Bleeding Llama,” disclosed in early May 2026 and rated 9.1, showed the consequences of unauthenticated access. An attacker could pull prompts, system prompts, and environment variables, including API keys, from Ollama server memory, with roughly 300,000 internet-facing instances vulnerable at disclosure.

Connected tools add another boundary to examine. LM Studio's own MCP documentation warns that some MCP servers “can run arbitrary code, access your local files, and use your network connection”, describing permissions granted around the model. An audit should establish what can reach the runtime and what its connected components can reach in turn.

The four channels through which data actually leaves a local AI setup

The first channel is an exposed API port. An unauthenticated local endpoint becomes available to other devices on the same subnet when its network configuration permits access. A cloud host or a misconfigured firewall can extend that reach to the public internet. Ollama's API is a concrete example of how a service intended for local use can become a network-accessible interface.

The second channel is MCP tool calls and agentic pipelines, where data moves without a person approving each transfer. A documented mid-2025 attack used a specially crafted email to make an email-summarization assistant extract data from connected cloud storage. The assistant then sent it through a trusted first-party domain, which made it very hard to detect at the network level. With persistent-memory tools such as Vellum, the audit must cover both access permissions and patterns the assistant learns to execute unsupervised. An allowed destination alone does not establish that an agent's action was appropriate.

The third channel is browser extensions that can read page content. These extensions may call the AI vendor directly from the browser, outside the local tool's traffic logs. Their connections do not necessarily appear on the network as AI-identifiable traffic. The browser is therefore a separate route for data leaving the host, even when the model session under review remains local.

The fourth channel is secrets sprawl in configuration files. MCP configuration files exposed a large number of unique secrets in 2025, the protocol's first year of widespread adoption. These files can hold credentials that create a standing exposure before any transfer is observed. Across these channels, traditional SWG, CASB, and DLP controls face a common limit. They control where data can go and check for known data patterns, but they cannot grasp the full meaning of local conversations or autonomous agent actions.

What a methodical traffic audit actually looks for, step by step

Start by scanning the host and local subnet for open ports, paying particular attention to Ollama's default 11434 and any LM Studio API port. Check whether each service binds to localhost only, 127.0.0.1, or to all interfaces, 0.0.0.0. The latter makes the service reachable across the network. Then check authentication rather than treating a listening port as a complete finding. A network-reachable API without authentication is an immediate finding regardless of what later traffic capture shows.

Next, capture outbound HTTPS connections while the AI tool is in use. Wireshark is a standard capture tool for checking what traffic leaves the machine during inference. Compare the destinations with known AI API domains and with the session's expected local behavior. An unexpected destination during a session that should be fully local is an immediate escalation signal.

Inventory every MCP server running on or connected to the host, treating each as a separate attack surface. Check which file system paths, environment variables, and network connections it can access. Review tool call logs for actions that retrieve information from cloud storage, email, or collaboration tools and pass it onward. Vellum's persistent memory and independent execution make this review different from inspecting a simple prompt-response interface. What an assistant learns can carry over from one session to the next, so if it keeps learning during the review, what the audit has to check keeps changing.

Then scan MCP configuration files, environment files, and local model configuration for plaintext secrets, including API keys, tokens, and credentials. Record a secret as a finding even if the traffic capture contains no sign that it left the host. Exposure and observed exfiltration are different claims. Keeping them separate prevents an uneventful capture from dismissing a credential that remains available in a configuration file.

Finally, list the installed extensions in every browser on the host being audited. Flag extensions with permission to read page content and inspect their outbound network behavior separately. Their activity will not appear in the local AI tool's logs. This last step extends the audit beyond the named runtime to the other software that can send the same user's information to an AI service.

Where network-layer auditing hits its ceiling and endpoint controls take over

Network-layer auditing can establish what crosses the wire, but it is structurally blind to computation that stays on the device. A gateway inspecting outbound HTTPS has nothing to inspect when inference produces no outbound traffic. Modern AI PCs make this gap more important because NPUs make on-device computation fast, quiet, and power-efficient. Antivirus and network monitoring tools typically overlook the plaintext prompts that trigger on-device code generation. No amount of confidence in a clean capture changes that boundary.

An existing CASB or SSE proxy does not close the gap simply because it intercepts public AI traffic. It can cover employees using public AI tools in the browser, but it cannot reach a local runtime whose traffic never leaves the machine. An outbound connection also cannot show every on-device MCP action that came before it. For truly local tools, the primary controls must move to the endpoint, where configuration, supply chain, and port exposure become central concerns.

Network monitoring covers outbound shadow AI and SaaS copilot traffic. Endpoint agents cover local runtimes and coding agents. Select each layer for the evidence it supplies about each exposure. An unobserved surface is not a clean surface.

Audit and enforcement platforms that cover these layers in 2026

Vellum is an AI-native platform built to give engineering and product teams a layer for reasoning and observability across their AI workflows. Its context-aware, pattern-learning approach is designed to augment human judgment. For teams that build AI products, it acts as a governed intelligence layer that sends model traffic through one point and keeps identity, context, and an audit trail. Teams can then change their model choice without being tied to a single cloud. It fits the recommendation to apply audit, spend, and content inspection once at a gateway.

The other approaches address different parts of the audit rather than interchangeable versions of that workflow layer. Network and browser discovery is directly relevant when the main problem is employees using public AI tools. Mapping AI traffic to users and devices helps connect observed use with the people and machines involved. Endpoint inventory broadens that view to installed tooling. These approaches answer discovery questions, but their presence does not establish coverage of local inference or agent tool calls.

Developer endpoint protection works at the runtime, so it has more to work with than just the traffic that leaves it. These tools can cover prompts, tool calls before they run, and tool responses. The scope matters because runtime protection may be in public preview, work only on Windows, or cover only supported agents. MCP-layer inspection adds another focus by examining the servers and agent traffic involved in tool use. A buyer needs those limits spelled out before trusting endpoint protection to cover everything.

Local, agentless, read-only infrastructure auditing meets a different need, especially when evidence must stay on local infrastructure or the environment is air-gapped. Network and cloud scans check what is exposed without acting as an application reasoning layer. Their own outbound paths also belong in the assessment, including scan targets, the local segment, DNS, cloud APIs, and vulnerability data lookups. No single platform covers all five enforcement points, namely application, AI gateway, network/browser, developer endpoint, and agent tool calls. The selection should follow the team's actual channels of exposure.

How EU AI Act Article 12 changes what audit logs must capture and keep

For high-risk AI systems, the EU AI Act makes logging more than an optional audit practice. Article 12 brings log design into the system's technical requirements, while Article 26(6) sets the deployer's retention duty. Deployers must retain automatically generated logs for a period appropriate to the system's intended purpose, of at least six months. That minimum applies per log entry, so a retention policy has to account for the age of individual records.

Capturing every prompt and response verbatim may seem to offer the fullest evidence, but it also stores personal data in audit logs and creates a GDPR Article 32 concern. The notes recommend retaining cryptographic fingerprints as evidence of the content. This separates evidence of integrity from a cleartext archive of the information being audited. More logging is not automatically better logging.

SHA-256 chain-of-custody manifests and opt-in RFC 3161 trusted timestamps matter in that context because they support verification of findings' integrity. They do not require the underlying data to be stored in cleartext for that purpose. Records must remain available for the required period without turning the audit trail into another store of sensitive content. That tension must be addressed in log design before collection.

Turning a one-time audit into ongoing visibility without creating new blind spots

A completed audit is a point-in-time snapshot of a changing setup. Employees install local runtimes, connect MCP servers, and alter configuration without IT involvement. Those changes happen faster than quarterly reviews, so a report issued at set intervals cannot keep track of them on its own. Schedule port exposure re-scans whenever new AI tooling is added or the infrastructure changes. Make the Ollama and LM Studio API port check a required step whenever the configuration changes.

MCP inventory likewise needs to be continuous. Every newly connected server adds an attack surface with potentially different network permissions. Matching discovered servers against a pre-analyzed catalog is one approach to reducing the burden of repeated analysis. The broader shift is from observing use to controlling sensitive data movement in real time across AI apps, endpoints, email, browsers, SaaS, and MCP flows. That shift still depends on knowing which control can actually see each action.

For enterprise model traffic, route connections through one gateway so identity, spend, content inspection, and audit are applied once, with model choice remaining changeable behind it. A governed workflow layer, including Vellum's intelligence layer, supports this architecture without replacing endpoint controls. The failure to avoid is false confidence from evidence that answers only a narrow question. A clean network scan during fully local inference is expected and says nothing about exposed ports, MCP configuration, or shadow AI on other devices. For tools described as “local”, privacy rests on the boundaries the audit examines.