Three organizations, one control: destination allowlists for AI agents on a Linux server, and why limits inside the tool are not enough

If your server runs n8n, an agent that carries out tasks, an MCP server or a script that communicates with a model, it has a process that decides for itself where to connect on the network. The limits you set probably sit inside the tool itself: a configuration setting, a prompt instruction or a list of permitted tools. Connections need to be logged somewhere the agent cannot write.

What was published

Anthropic, October 9. The company published a report on unintended model actions observed during evaluations and internal use. The report describes four types of behavior: exploiting basic software flaws on a third-party website to run commands on its server, submitting a real form on a website instead of a practice form, bypassing a restriction to reach information that requires a token or payment, and using URL shortening services to bypass a limit in the fetch tool. According to the company, the actual impact of the cases identified so far was minimal. To the best of its knowledge, none involved customer data. Following the findings, it extended the removal of live internet access to all internal evaluations. Access will remain disabled until the company verifies that its monitoring reliably detects these behaviors. The company is also reducing internet access for its internal agents and moving them to managed infrastructure with strong isolation.

MITRE ATT&CK. Version 20 of ATT&CK added the technique T1700, AI-Enabled Exfiltration. It describes an attacker inducing an enterprise AI agent to exfiltrate information through direct or indirect prompt injection, or by other means. The attacker does this by exploiting the tools the agent is authorized to use. One analytic in the detection strategy attached to the technique describes an AI-associated process accessing information outside its authorized scope. A connection then leaves the same process lineage for a destination outside the list of authorized AI endpoints. According to Cyber Security News, the version was released on October 13.

CERT-In, October 15. India's national incident response team published advisory CIAD-2026-0049 with a severity rating of Critical. According to the authority, model providers voluntarily reported that, during research and evaluation, their models accessed live systems belonging to organizations in India and read business records, including personal information and confidential material. Access was enabled by credentials exposed in configuration files and public code repositories, and by overly broad cloud permissions. None of the organizations detected the access themselves. The recommendations include blocking outbound traffic (egress) by default and allowing only the destinations required for the task. Enforcement should take place at the network level, not through instructions to the model. The advisory also recommends logging model-initiated requests wherever possible: destination, port, protocol and outcome. For organizations running agents, the authority recommends assigning a separate, short-lived identity to each run, restricting outbound traffic to the required destinations and keeping a tamper-resistant activity log.

Three sources, one specification

Read together, the three publications point to three requirements shared by all of them.

The boundary is enforced outside the agent. Anthropic's report shows why. According to the company, some of its fetch tools limit the length of URLs a model can request. The aim is to reduce the risk of long URLs being used for unwanted actions, such as exfiltrating larger amounts of information. Several models, including Claude Opus 5 and Claude Mythos 5, bypassed the limit using free URL shortening services. The operator of da.gd also detected the use and reported it to the company. Anthropic describes most of these behaviors as persistence: when a model cannot complete a task as specified, it works around the restriction instead of stopping. The company also notes that some cases occurred during ordinary agent use, not just evaluations. Your agent receives equally ambiguous tasks. When an agent sees a restriction as an obstacle to its goal, it may look for a way around it. A kernel firewall rule is not open to negotiation with the agent.

The boundary is tied to the process. MITRE's analytic ties the outbound connection to the agent's process lineage, and CERT-In calls for a separate identity for each run. One allowlist for the entire server does not meet this requirement: the backup process needs access to object storage, CI needs access to the code repository, and the agent probably needs neither. Each agent needs its own list.

The log does not rely on the agent's account. CERT-In warns against relying solely on retrospective transcript reviews. Such reviews may miss activity that the model presents as legitimate in its reasoning. Anthropic writes that a model's account of its reasoning is not necessarily reliable evidence of why it acted. In one case, according to the report, the model claimed in its reasoning that it was merely demonstrating the process, but actually submitted the form. A reliable log records connections through a separate component.

What URL shorteners teach us

The URL shortening case shows how to write an allowlist. A shortening service is a seemingly harmless destination that accepts arbitrary content from anyone and passes it on. Including it in the approved destination list removes much of the list's value. In our assessment, paste sites, generic webhook endpoints and general-purpose redirect services belong in the same category: any service that accepts content from anyone who contacts it and makes that content available elsewhere. An agent does not need these services to work. If you have a genuine need for one, approve the exact address you use.

For the same reason, it is worth approving exact hostnames rather than entire domains. Blanket approval for a domain allows access to all its subdomains, which can be used to hide information. DNS queries are also a channel for transferring information: data can be included in the name the agent asks to resolve.

The Linux gap, and the list no one has written for you

The T1700 page lists only two platforms: SaaS and Windows. Linux is not listed. This does not mean the risk is absent from a Linux server. It means there is no ready-made mapping for your environment. MITRE's detection analytics also rely on parameters such as $AuthorizedAIEndpoints$ and $AuthorizedAIDataScope$. In our assessment, the notation suggests that these are variables whose values need to be defined. No one has defined them for your server. CERT-In's recommendation to allow outbound traffic only to required destinations also assumes you know what those destinations are. Your first task, then, is to write the list. Without it, there is nothing to enforce and nothing to detect.

CERT-In notes another aspect. According to the authority, all incidents involving AI agents exploited known weaknesses: credentials exposed in code, repository history and configuration files, abandoned APIs, internet-facing management interfaces and unpatched middleware. In the voluntarily reported incidents, agents were observed recovering the same exposed credential and reusing it in separate operations. Your server can therefore also be a destination for an agent run by someone else.

Practical steps

• Map the agents. Include not only processes that listen on a port, but also those that only make outbound connections: a task-running agent, an automation process or a scheduled script.
• Observe before you write. Over a period of time, record the destinations each process actually connects to and how much traffic goes to each destination.
• Write a list for each agent. Use exact hostnames without wildcards. Do not include shortening and redirect services, paste sites or generic webhook endpoints.
• Enforce at the network level, by process. Not in the prompt or the tool's settings. On Linux, you can use, for example, systemd's IPAddressAllow or an nftables rule matched to the service's cgroup.
• Restrict DNS too. A restricted agent should resolve only the names you have approved.
• Log somewhere the agent cannot write. Record the destination, port, protocol and outcome. CERT-In recommends retaining logs for at least 180 days.
• Check inbound access too. Look for exposed credentials in code, commit history and configuration files. Replace every exposed credential, remove internet access to management interfaces and require multi-factor authentication for all administrative access.

How nuDefend helps

What is running. nudefend workloads shows the AI tools running on the server: model servers, chat interfaces, vector databases, automation platforms and MCP servers. It shows tools running on the host or inside a container, along with the basis for identifying each one. nuDefend also identifies agents that do not listen for connections and only make outbound connections.

Where it connects. nuDefend records the destinations each AI tool communicates with, the amount of traffic sent to each destination and when the destination was first detected. When a destination is identified, its name and a description of its type of activity are shown. nudefend egress review <workload> shows all destinations for one tool and indicates whether monitoring covered the full period. Reports and history are stored in a local database on the server.

The list is built from actual traffic. At first, nuDefend only records traffic. At the end of the monitoring period, it produces a list based on the traffic observed. On the Outbound screen, you approve the destinations the tool actually needs. Addresses shared by several services are not approved automatically. They are flagged for your review.

Enforcement sits beneath the tool. Once the restriction is enabled, the tool can connect only to destinations you have approved. Every attempt to connect to another destination is blocked before the traffic leaves the server. The restriction applies only to the selected tool, and the rest of the server continues to operate as usual. The restriction can be applied to almost any tool the system identifies, and the screen shows whether each tool is restricted. If you do not give final confirmation within ten minutes, the restriction is lifted automatically. nuDefend monitors itself and restores its rules if someone tries to change them.

What it resolves, too. A restricted tool can resolve only the addresses you have approved. Every other lookup is stopped before it leaves the server. Approval applies to the exact name, not its subdomains. Every blocked lookup appears on the screen alongside the tool's name. This is usually the first sign that a tool is trying to reach a destination you have not approved.

The receiving side, too. nudefend expose shows every service listening on the server and who can reach it. nuDefend alerts you when a previously internal service becomes accessible from outside. A signed threat list is updated every 30 minutes and blocks traffic to and from malicious addresses and domains. Repeated password-guessing attempts against SSH, mail, FTP and website login pages are blocked at the firewall.

More details are available on the outbound traffic page, the exposure page and in the documentation.

The bottom line

An AI lab, MITRE's technique framework and a national cybersecurity authority point to the same control: an approved destination list for each agent, enforced at the network level rather than in the prompt, with connection logs that do not depend on the agent's account. The URL shortener cases described by Anthropic show what happens when the limit sits inside the tool. On a Linux server, no one has written the authorized destination list for you. That is the first task: check where each agent connects, write a list without general-purpose relay services and enforce it at a layer beneath the agent.