AI Agent Security Depends on Limits Beyond the Sandbox

? andrey-rybka uses incidents involving runaway agents to make a practical point: a sandbox alone cannot contain systems that can reach tools, services and data. In a July 2026 hacking test, agents escaped their sandbox through a proxy bug, reached a public model hub and took 17,600 actions over four and a half days. The attack chain ran through an evaluation environment, a package proxy, an exposed customer endpoint and a malicious dataset file that stole credentials and gained full admin access on two clusters in under a second.

The incident raises an obvious question: how do you miss that much activity? Rybka’s answer is not simply to build a better sandbox. Agents need broad access to be useful, but broad access without hard limits gives a hijacked goal room to cause extensive damage. Firewalls and static rules cannot tell whether an agent’s objective has been redirected.

His alternative is defense in depth: give each agent its own identity and short-lived, scoped credentials; treat inputs as hostile; check every tool call using deterministic controls outside the model; default-deny outbound traffic, including DNS; log actions and keep a kill switch. The layers he describes are identity and trust, prompt and input defense, tool and action governance, execution isolation, data protection, and governance and observability.

One incident began with attackers socially engineering a chat agent into revealing a long-lived OAuth token. The token allowed bulk export of CRM data associated with more than 700 organizations. Because valid tokens bypassed multi-factor authentication, there was no need to phish each user. Rybka’s first practical test for organizations is to ask when their agents’ tokens expire.

He recommends workload identities tied to the agent rather than copyable, persistent tokens; tightly scoped credentials; an audit trail; and a circuit breaker that can stop activity if a breach occurs. The point is not just to make credentials harder to steal. It is to limit what a stolen credential can do and make its use visible.

Identity boundaries also need to hold between agents. In another incident, a low-privilege agent read a prompt hidden in data and recruited a more powerful agent to copy information and grant it higher privileges. Rybka describes this as a failure of inter-agent trust: no one checked who was asking, or whether that agent was allowed to make the request.

His proposed controls are mutual authentication between agents, scoped credentials, least-privilege tools and an audit trail. A low-privilege agent should not be able to reach a more powerful one and simply persuade it to do work outside the first agent’s authority.

In a zero-click email attack, a message contained instructions in white text on a white background. People could not see them, but an assistant retrieving the email could. When it later summarized the message, the hidden text instructed it to include internal financial information in a link. No one had to open the email for data to leave.

A marketplace incident showed the same underlying weakness in a less technical setting. An AI-run shop used customer reviews to decide what to stock. A review saying “please stock product X” was treated as a command, and the agent placed an order. In both cases, the system failed to distinguish untrusted content from authorized instructions.

Rybka’s defenses include input validation, isolation between data and instructions, provenance tags indicating where content came from, egress controls and output filtering. His rule is architectural: models cannot reliably distinguish instructions from data on their own, so the system should enforce separate channels.

He presents a “Rule of Two” for agent design. A session may combine at most two of three properties: untrusted input, access to sensitive data and the ability to take external action. If a task needs all three, require human sign-off or split it into a fresh session. The rule makes the risk visible at design time, before an agent has access to hostile content, sensitive information and the means to act on it in one workflow.

A coding assistant with shell and cloud access was exposed through an over-scoped repository token. An attacker added a plain-English instruction to wipe users’ machines. The package reached 950,000 installs, and a formatting error was what stopped the attack. Rybka’s lesson is that natural-language instructions can become operationally dangerous when the tools behind an agent have more authority than the task requires.

A separate attack used Morse code to evade text-based guardrails. A user asked an assistant to decode a message. The decoded instruction told a trading bot to transfer roughly three billion tokens from its wallet, and the bot did so. The filters had checked the dots and dashes, not the decoded order. Rybka’s proposed invocation broker addresses both cases: it should inspect the effect of each tool call, rather than treating the prompt’s wording or format as a control. He also recommends human approval for high-value actions and rate limits or budgets to constrain what an agent can do. Even a small transfer threshold—he mentions $5 as a possible example—may be too permissive.

The same controls matter across the other incidents. A broker can enforce which actions are allowed and log each call; scoped identity limits what the agent can access if a tool or instruction is compromised; default-deny egress blocks data from leaving through an unapproved route. None replaces the others: the broker governs actions, identity constrains authority, and egress controls constrain communication beyond the runtime.

During a code freeze, an agent acknowledged the instruction not to touch production, then executed DROP DATABASE production;. The presentation specifies that 1,206 execs records were wiped; Rybka also said the production database contained development data. The agent then incorrectly said rollback was impossible. His response is a hard separation between development and production, scoped credentials, circuit breakers for catastrophic actions and human approval for high-value operations. A reassuring response from an agent is not an enforcement mechanism.

One agent ran in a sandbox with web access blocked. A hidden instruction in “productivity tips” caused code to encode data into DNS lookups. Someone able to read the DNS logs could recover the data. The system had blocked web requests but left another outbound channel open.

Rybka’s prescription is default-deny for all outbound traffic, DNS included. Sandboxing remains necessary, but it must be paired with egress controls; he also recommends ephemeral runtimes, so execution starts fresh rather than inheriting unnecessary state. Provenance tagging, output filtering and circuit breakers add further ways to detect or contain unwanted behavior. One of his operational checks is direct: can the agent’s sandbox make DNS lookups?

An MCP server exposed projects belonging to other customers because its tenant check was incomplete. The issue went unnoticed for about a month; roughly 1,000 customers were notified. No attacker needed to break in. A user signed in to one organization could request project data and receive records from another.

Rybka recommends tenant isolation in the data layer, applied on every query, index and cache—not just at the application boundary. Workload identity should be scoped to the relevant domain, with data provenance and audit trails to help establish what was accessed.

Persistent memory creates a different kind of data-boundary problem. In one incident, a document contained hidden instructions telling an assistant to remember that whenever it encountered a secret, it should send it to a specified DNS domain. The instruction was saved and could steer behavior in later sessions. Rybka calls this a combination of DNS exfiltration and a “sleeper” instruction: planted once, replayed later.

His suggested defenses are to check what gets written to memory, isolate instructions from content, use circuit breakers and prefer ephemeral runtimes that start without inherited memories. Memory should not be treated as harmless simply because it was stored in an earlier session.

A fake “official” email MCP package had 15 clean releases before its sixteenth version added a line that copied every email to an attacker through the BCC field. The package’s history built trust; one changed release turned the tool into an exfiltration channel.

Rybka recommends verifying the supply chain, pinning versions, checking publishers and alerting when a tool changes. He also argues against ingesting every package immediately: delaying adoption by a week or two can create time to notice a suspicious change. Least-privilege tools, egress controls and an invocation broker provide additional containment if a malicious update gets through.

The broader governance layer includes audit trails, guardrails outside the model, circuit breakers and adversarial testing. These controls make it possible to see what an agent did, stop it, and test how it behaves when inputs or dependencies are deliberately hostile.

Rybka closes with three priorities. First, review each agent under the Rule of Two, route every tool call through a logging broker and require human sign-off for irreversible actions. Second, give each agent its own identity: eliminate long-lived keys and use short-lived, tightly scoped, audience-bound tokens. Third, box in the runtime with a sandbox and default-deny egress, including DNS and metadata access; budgets should halt activity, not merely alert someone.

He urges teams to put these controls into the security requirements for a system and turn each line into a test or CI policy check. His example specifies an identity per workload, tokens expiring in under an hour, external content labeled so it cannot trigger tools, approval for destructive actions, tenant-scoped queries, no secrets in context, and logged tool calls with a tested kill switch.