When an AI agent turns inward: Loom and ToFu show why your server is the most dangerous target

If you run AI agents on your own Linux server, you probably think about outbound traffic mainly in terms of the internet: where the agent sends data and which external server it downloads code from. A setup like this includes an orchestrator that manages the agents, several MCP servers that provide tools, and perhaps connections to cloud services. The connections that cause the most damage often point inward: to 127.0.0.1, private network addresses, and endpoints that provide cloud or container credentials. Both publications describe cases where the orchestrator's infrastructure code, or tools it runs, opened these connections to an address chosen by someone other than the administrator. In Loom, this required an authenticated user with the appropriate permission.

We examine the two publications together because they describe the same pattern: an AI agent turns the server into a proxy used against the server itself. The practical conclusion is that you need a destination policy on the host for each agent process. Do not rely on every component to filter the URLs it receives.

What was published

Three vulnerabilities in Loom. On 2 October 2026, AWS published security bulletin 2026-124-AWS for Loom, an open-source platform from AWS Labs for orchestrating AI agents. AWS recommends upgrading to version 1.7.0 and ensuring that forks and derived code also include the fixes. According to the bulletin:

• CVE-2026-103956 (authentication bypass, CWE-306 and CWE-1188): In versions before 1.6.1, any network client could obtain full administrative access to the agents' control plane if the deployment had no identity provider configured. These permissions allowed the client to register tool servers, read stored integration credentials, and rewrite IAM policies associated with agent roles. The vulnerability was fixed in version 1.6.1, released on 4 August 2026.
• CVE-2026-103957 (CWE-918 and CWE-201): In versions before 1.7.0, an authenticated user with mcp:write or a2a:write permission could configure an OAuth2 discovery URL. The document at that URL instructed the server to send OAuth2 client secrets, or another user's access token, to a third-party-controlled endpoint. According to AWS, version 1.6.1 blocked access to internal addresses through this path but did not fully address token leakage. The complete fix was included in 1.7.0.
• CVE-2026-103958 (CWE-918): In versions before 1.7.0, a user with the same permissions could direct connections for tool servers (MCP) and remote agents (A2A) to any destination on the internal network and read the responses. These destinations included the endpoint that provides container credentials.

A study of 273 MCP servers. On 9 October 2026, researchers from Pennsylvania State University, Université Montpellier, and Dartmouth College published the paper on ToFu. They built a fuzzing tool that generates security tests from the descriptions the tools themselves provide to the model. They ran it against 273 open-source MCP servers containing 3,405 tools. According to the paper, they found 253 confirmed bugs across 343 tools on 118 servers. The findings included 64 cases of path traversal, 7 of SSRF, 5 of data exfiltration, and 3 of OS command injection. The largest group consisted of 115 cases of output returned without escaping.

The paper also describes an attack the researchers call Repeat-After-Me: the model is asked to repeat text that looks like a tool call. The orchestration layer interprets the output as a real call and executes it. According to the paper, this behavior was reproduced in six orchestration layers: LangGraph, MAF, ADK 2.0, AutoGen, Strands, and CrewAI. The researchers conclude that a model-generated argument should not be treated as trusted input, even if it conforms to the tool's schema.

The same mechanism at two layers

In Loom, the orchestrator's own infrastructure code opened connections to any address supplied by the user. This is the code that handles OAuth2 discovery and connections to tool servers and remote agents. In ToFu, the same pattern appears one layer down, inside the tools. In the paper's case study, a web page screenshot tool checks only that the input is a valid URL. According to the researchers, an agent influenced by injected content can use this tool to read files from the server and take screenshots of services listening on loopback and the private network. On another MCP server, designed for WordPress, a tool accessed a caller-supplied site URL without restriction. According to the paper, this bug was found in a run with all tests enabled. The run log shows a connection to an address on 127.0.0.1.

In both cases, a component receives an address from an external source and opens a connection to it from inside the server. From the network's perspective, the connection originates from the agent process. Any service that assumes only the machine itself can access it is therefore exposed to such a connection.

Who controls the URL

This condition keeps the pool of potential attackers relatively small. For tools, that pool is much wider. ToFu's threat model assumes an attacker who can influence what the model reads: user instructions, retrieved content, and output from other tools. The researchers therefore treat every schema-conforming argument as potentially hostile. According to the paper, many tools implicitly rely on the model to filter input, even though that input may be under an attacker's control. In practice, the author of a web page the agent reads may determine the URL an MCP tool accesses.

Why internal destinations matter

From the outside, an internal destination looks safer than one on the internet. From an attacker's perspective, the reverse is true. Internal destinations may host services that were never hardened because "they are only on localhost," the agents' own control plane, and endpoints that provide credentials. In CVE-2026-103958, the attacker can not only reach the container credentials endpoint but also read its response. If the container's role credentials were read, AWS therefore recommends rotating the IAM role's session credentials and checking CloudTrail for unexpected use. This is how the damage extends from the server to the cloud account.

The SSRF tests the researchers built for ToFu define prohibited destinations in the same way: loopback, RFC 1918 ranges, link-local addresses, and cloud metadata addresses. According to the paper's impact table, an SSRF bug occurs when the server connects to an attacker-chosen address, including these address types. Such a connection violates the requirement that server requests reach only their intended destinations.

Why component-level fixes are not enough

There are three reasons. First, fixes arrive in stages. In Loom, version 1.6.1 blocked internal addresses in the discovery path. Another release was still needed to fully address token leakage. Second, ToFu found 7 SSRF bugs in the tools tested. According to the paper, scanners that search code for a fixed list of dangerous operations miss properties such as "the destination is restricted to an allowlist." There is no single point in the code to search for to check this property. Third, according to the paper, only 273 of the 1,404 repositories that expose tools could be run during testing. The rest failed to build, failed to start, or required credentials. The numbers describe what could be tested, not the full set of repositories.

The researchers recommend that each tool enforce the restrictions it declares. This is sound advice for tool authors, but it is not enough for a server operator running ten tools from ten authors. The host is where you have control. A rule enforced on the address a process actually connects to does not depend on how the URL was written. ToFu tests alternative IP address representations in input, such as octal or hexadecimal notation and IPv4-mapped IPv6 addresses. At the connection level, the address has already been parsed, and these differences no longer matter.

Loopback is not a boundary against a local process

The temporary measure AWS recommends for CVE-2026-103956 is to ensure an identity provider is configured before the backend is accessible beyond loopback. Binding to loopback protects against network clients, which is precisely the issue in this vulnerability. But it does not protect against SSRF: an agent running on the same host can easily reach 127.0.0.1. Both sides therefore need attention. Control planes should be bound to loopback, and agent processes should be restricted to explicitly approved destinations, with no other access to the host's loopback.

Practical steps on the server

If you run Loom:

• Upgrade to 1.7.0 and check that your forks also include the fixes.
• Until you upgrade: ensure that a Cognito user pool or an external identity provider is fully configured before the backend is accessible beyond loopback. Also ensure that LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is not set in any deployed environment other than local development. This is AWS's guidance. Contrary to the GBHackers coverage, it is not limited to production. In addition, restrict mcp:write and a2a:write to trusted administrators. According to AWS, this reduces the risk but does not eliminate it without the fix.
• After upgrading: rotate the OAuth2 client secrets in MCP and A2A integrations. Revoke and reissue tokens that were active while the system was vulnerable. If the container's role credentials were read, rotate the session credentials and check CloudTrail.

For any agent setup:

1. Identify the orchestrators, agents, and MCP servers running on the server, and which of them accept a URL, hostname, or address as input. Examples include page retrieval and screenshot tools, webhooks, and discovery.
2. Bind control planes, administrative interfaces, and databases to 127.0.0.1. Check the actual state, not just the configuration file.
3. Run each agent under its own user, in a separate network namespace or a separate container, so that its loopback is not the host's loopback and firewall rules can identify its traffic.
4. For these processes, block the host's loopback, link-local addresses (169.254.0.0/16 and fe80::/10), RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and private IPv6 addresses (fc00::/7) by default. Allow access only to internal destinations the agent actually needs, approving each destination separately.
5. Do not block without logging: log every attempt by an agent process to reach a metadata address or an endpoint that provides credentials. Such an attempt is a finding that warrants investigation.
6. Reduce the permissions of the cloud role assigned to the agent. If credentials leak, those permissions will determine the extent of the damage.
7. Test new MCP servers in an isolated environment. According to the paper, four servers affected the host during testing: they deleted files outside the workspace, accessed a path outside the designated directory, closed terminal sessions that were not their own, and launched processes without limits. The researchers cite these cases as another reason to run such tests in a sandbox.

How nuDefend helps

The nudefend workloads command shows the AI tools running on the server, including agent platforms and MCP servers, whether they run directly on the host or in a container. Each tool is shown alongside the information used to identify it.

The nudefend egress review command shows the destinations each tool has connected to, the traffic volume for each destination, and when each destination was first identified. A recognized destination is shown by name, alongside a description of its activity type. This makes an unusual destination you did not expect stand out in the list.

You can use this information to set a policy. Start with monitoring, approve the destinations the tool actually needs, and enable the restriction. Once it is enabled, the tool can connect only to approved destinations. Every attempt to connect to another destination is blocked before traffic leaves the server. nuDefend also restricts the names the tool is allowed to resolve. Every blocked lookup is shown alongside the tool's name.

The nudefend expose command shows every service listening on the server and who can reach it, from the server's own perspective. A service bound to 127.0.0.1 or ::1 is marked as local-only. If a service that was internal-only becomes accessible from outside, nuDefend detects the change and raises an alert. If a service is exposed unintentionally, you can block its port from the dashboard or command line after a preview shows exactly what will be blocked. More details are available on the outbound traffic page and the exposure page.

The bottom line

The Loom vulnerabilities and ToFu's findings describe the same problem at two layers: a component in the agent setup receives an address from someone other than the administrator and opens a connection to it from inside the server. The destination is often the server itself, the private network, or an endpoint that provides credentials. Upgrade Loom to 1.7.0 and handle credentials according to AWS's guidance. Beyond that, do not wait for every tool author to fix URL handling. Bind control planes to loopback, isolate each agent at the network level, and block agent processes from accessing internal destinations by default. Treat every request they make to a metadata address as an event that requires investigation.