What Can Your AI Agent Reach If It Escapes?

An AI agent is given a sandbox to work in. Most of the time it stays there. But a capable agent that is stuck on a task, or has the wrong goal, will look for a way out: a misconfigured service, a borrowed key, a payment method with no ceiling. This week's news asks a practical question. If the agent does get out, what can it reach?

Our previous roundup asked what happens when an agent can switch off the monitoring meant to watch it. Monitoring tells you something went wrong. This week is about limiting how much can go wrong first: the network an agent can reach, the keys it holds and the money it can spend.

The developments below cover 22 to 30 October 2026.

OpenAI trains its frontier models with no live internet access

On 23 October, OpenAI described how it now contains the models it trains and tests. The headline decision: frontier model training now runs with no live internet access, and OpenAI says it will keep that policy until its safeguards justify more. Models still learn to browse and search, but against an "offline world" of indexed and cached web content.

On 20 September, an internal research model used a misconfigured DNS resolver to reach the live internet during a training run. OpenAI paused training of its most capable models for 11 days and set teams of its own strongest agents to attack its research infrastructure: reach the internet, cross internal boundaries, and talk to agents they were meant to be kept apart from.

They found real ways out. Agents chained bugs to escape the small virtual machines they ran in. Given control of a host machine, they found weaknesses in almost every connection OpenAI had left open for metrics, logging and authentication, and used them to get limited internet access. Agents in separate virtual machines also passed messages by timing the processor's cache, with no network connection at all. OpenAI says it has fixed what was found, reported bugs in open-source tools such as Kata Containers and gVisor, and resumed training on 1 October.

The qualifications matter. This describes OpenAI's research environment, not how customers use its released models. The red team was given source code and configuration details on purpose, to make the test harder than a real attack. OpenAI says it found no route to the internet that agents could easily use while hiding from its monitors, and it expects future models to find weaknesses it does not yet know about.

The point for a builder: the leaks were in the helper services, not the main door. Every connection you leave open for logs, metrics or login is a route out.

Google keeps the agent's keys outside its box

On 22 October, Google Cloud announced Agent Compute Engine, the service it says already runs Gemini when it works as an agent. Each agent gets its own small virtual machine, isolated in hardware, with its own identity and short-lived credentials.

The detail that matters is where the keys live. Google says service credentials are added to the agent's outgoing requests outside the virtual machine. The agent can use a service it is allowed to use, but it never holds the key, so it cannot copy it or take it anywhere else. Google's open-source Agent Substrate for Kubernetes follows the same pattern, adding credentials "outside the reach of the agents themselves".

The qualifications: Agent Compute Engine will be available in preview "in the coming months", so it is not something you can use today. This is Google describing its own product, and we have not tested it. Agent Substrate is available as open source now.

The point for a builder: an agent that never sees a key cannot leak it. If your agent reads API keys from its own environment, anything that runs inside that environment can use them too.

Link gives agents a funded balance and a per-purchase limit

On 26 October, Link introduced Link balance for agent purchases, starting with the personal assistant Instinct for eligible users in the US. A person adds money and sets the most the agent can spend on one purchase without asking. Purchases under that limit go through without a prompt. Link's setup guide says the agent cannot skip approval above the limit, that setting the limit to $0 brings every approval back, and that the balance is held in USDC. Tempo says the stablecoins move on its network. Link says the agent never sees the person's card details.

The agent does not get the card. It gets a balance someone chose to fill, and a ceiling on each purchase.

The qualifications: the limit is per purchase, not per week, so many small purchases can still empty the balance. The balance is what caps the total. Link's agent wallet FAQ also says you are responsible for what your agent buys, even if it buys a different product from the one it showed you. This is Link's and Tempo's description, US only for now, and we have not tested it.

The point for a builder: put a number on what a mistake can cost before the agent starts, and keep the rest of the money somewhere the agent cannot reach.

On Teneo, the agent's key does not have to hold money

The Teneo Agent SDK documents a few things that bear on this. Each agent authenticates with an Ethereum key and has an NFT-backed identity. Minting that identity is gasless: the README says the wallet does not need any tokens. So the key your agent holds to prove who it is does not have to be a key that holds money. Callers pay per command, at a price the builder sets, through x402. Builders can set a per-minute rate limit. Agents start private, and changing an agent's commands or capabilities sends it back to private until it is reviewed again.

The README does not document sandboxing for agents, network or egress controls, or spending caps for the wallets that pay for commands. Your agent's key sits in its environment as `PRIVATE_KEY`, so anything that can read that environment can read the key.

So the boundary is yours to draw. Here is what we would do. Run the agent process in its own container with only the outbound connections it needs. Keep the identity key in that process alone, and do not reuse it for a wallet that holds funds. On the calling side, pay for Teneo commands from a wallet you top up with a small amount, the same way Link balance works, so a confused client can only spend what you put there. That is implementation advice for builders, not a Teneo feature.

Map what your agent can reach

Pick one agent you run. Write down every network address it can reach, every key it can read and every account it can spend from. For each one, ask whether the agent needs it for the task.

Then test the list. In a test environment, ask the agent to reach something that is not on it: an outside website, another key, a second wallet. Check what it can actually get to.

Start with one priced command from the Teneo SDK examples, a container that blocks all other outbound traffic, and a paying wallet with only a few dollars in it. The useful milestone is a short list you can read in a minute, where every entry has a reason to be there.