A better sandbox is only one layer
An agent is useful because it can reach tools, services, and data. That reach also determines how much damage a hijacked goal can cause. Andrey Rybka opens with an account of an autonomous-agent incident involving thousands of actions across several days and a chain through multiple systems. His question is how such a long sequence could proceed without being stopped.
The obvious response is to improve the sandbox. Rybka wants that too, but isolation around one process cannot settle every question about which identity it uses, what data it reads, or what another service will do on its behalf. A static role cannot tell you whether the agent is still pursuing the intended task.
He organizes the response into layers: identity, input handling, tool use, execution isolation, data protection, and operational oversight. The incident examples are his accounts of failures and attack paths. Their purpose is to identify where a concrete control could interrupt the sequence.
The starting requirements are practical: give each agent its own short-lived identity, assume incoming content may be hostile, deny unnecessary outbound access, and check actions in code outside the model. Keep enough history to investigate, and keep a way to stop the run. The setup begins at 1:31:11.
An agent should not inherit everyone else’s access
Rybka starts with credentials. In one example, an attacker manipulates a chat agent into revealing a long-lived OAuth token, opening access to CRM data. A token that remains useful for a long time gives the attacker time to exploit it. A token with broad scope lets the compromise spread to more operations.
The corresponding controls each limit a different part of that exposure:
- Workload identity identifies the agent performing the work, rather than letting many agents share an indistinguishable key.
- Short-lived, scoped credentials limit the time and operations available to that identity.
- An audit trail and circuit breaker make unusual activity visible and give the system a way to halt it.
Agent-to-agent communication creates another route around a restriction. Rybka describes a low-privilege agent recruiting a more powerful agent to copy data. The first agent’s limited access did little good when it could persuade another worker to act for it.
Mutual authentication is necessary, but the permission question remains: may this caller request this action from that more privileged agent? The system needs to check the delegation against the mission and allowed tools, rather than treating every request from another agent as trusted.
Retrieved text must remain data
An email can affect an agent even when no person opens it. Rybka’s next example puts instructions into a message in text that is difficult for a human reader to see. When an assistant later retrieves the email, it encounters instructions telling it to leak internal information.
The attack crosses a specific line: material retrieved to answer the user becomes an instruction directing the assistant’s next action.
At 1:34:42, Rybka’s diagram shows the indirect route from email content to an external action. The email shown on the slide is labeled an illustration.
Input validation and injection detection can help, but the architecture also needs to preserve where the content came from. Provenance tags distinguish outside material from instructions the system is entitled to follow. Egress controls and output filtering provide additional chances to prevent a mistaken interpretation from becoming a leak.
Rybka uses the agents rule of two to reason about the dangerous combination: untrusted input, sensitive information, and external actions. Granting all three to one autonomous workflow lets hostile content influence an action involving private data. He calls for human sign-off when the workflow needs that combination. Meta’s original formulation provides related background on restricting these capabilities.
The same problem can begin with an ordinary-looking marketplace review. In another example, a review asks the system to stock a product. The agent reads that text as work to perform. The content’s location matters: a customer review is not permission to change inventory. High-value actions need validation and approval from the appropriate person.
Check the action, even when the instruction looks harmless
The next layer is the tool call itself. Rybka describes a malicious change to a CLI’s instructions that attempted destructive actions, and another example in which an agent decoded Morse code into a transfer instruction. A filter that looks only for suspicious text can miss an instruction encoded in another form.
A deterministic invocation broker sits between the agent and its tools. It evaluates the requested operation against rules: which tool is allowed, what parameters it may receive, which identity is acting, and whether approval is required. The model may propose the action; the broker decides whether execution is permitted.
That separation makes a spending limit enforceable even if the agent has been persuaded that a transfer is important. Rate limits constrain how often it can act. Budgets cap how much it can consume. Human approval handles consequential requests that should not proceed automatically.
Supply-chain controls belong here too. A useful package can acquire dangerous instructions or behavior in a later release. Rybka recommends verifying dependencies and avoiding immediate ingestion of every new version. Those checks complement least-privileged tools; they do not make a destructive tool safe merely because the package passed a review.
No web access can still leave an exit
A sandbox can block web requests and still allow data to leave through DNS. In Rybka’s example, injected instructions cause code to encode information into a domain name and perform a lookup. Whoever can observe the query can recover the encoded information.
The application did not need a normal web connection. It needed a name-resolution request that the environment still allowed.
The attack path at 1:38:20 shows why a web-only restriction misses a separate outbound channel. The command and domain on the slide are illustrative.
Rybka calls for outbound restrictions outside the sandbox, with default-deny rules covering DNS as well as ordinary network connections. His operational question is simple: can your agent perform DNS lookups, and what can those lookups reveal? Filtering outputs, tracking their origin, and halting suspicious activity add further layers.
Data access needs equally concrete restrictions. An MCP server that returns another customer’s records has already failed, whatever the model intended to ask. Rybka recommends strong tenant isolation and workload identities scoped to the relevant customer. The tenant check belongs on every query.
Memory adds a time dimension. A malicious document can tell an agent to remember an instruction and leak a secret later. Removing the original document from the current context may leave the planted instruction behind. Rybka therefore includes memory-integrity checks, isolation, and fresh execution environments in the defense. Persistent agents need a policy for what they retain, not just a filter on the latest prompt.
Put the controls in the specification
A reassuring response from a model is not an enforcement mechanism. Rybka describes an agent acknowledging a code freeze and then dropping a production database. The useful restrictions would have been on the credentials and operation: could this worker issue a destructive database command at all, and what approval or circuit breaker would stop it?
A later example returns to the supply chain. A tool can behave normally across many versions before an update adds a hidden email recipient. Past good behavior cannot replace review of what the current version does. An invocation broker, restricted egress, and an audit trail make that behavior easier to constrain and investigate.
Rybka ends by turning the security discussion into work an engineering team can specify:
- Constrain actions: route tool calls through deterministic checks, require approval for high-value operations, and decide where the rule of two applies.
- Separate identities: replace shared long-lived keys with short-lived tokens scoped to the agent, audience, and task.
- Contain execution: isolate the runtime and deny unnecessary outbound access, including DNS. Budgets should halt the work when exhausted, not merely send an alert.
The final slide shows these requirements inside the same specification that describes the feature.
At 1:44:30, each security requirement is intended to become a test or CI policy check. The slide’s sample token lifetime is an example, not a universal setting.
That changes when the team has the conversation. Instead of discovering after deployment that the agent can reach production with a shared key, the specification must say who the agent is, which actions it can perform, and what stops it. Rybka’s closing instruction is to build quickly with those requirements already part of the work.