The Agent Was Isolated. Its Permissions Weren’t.

An AI agent can sit inside a carefully isolated machine and still possess the authority to damage systems outside it. That is the useful lesson in AgentCorruption, the research Zenity disclosed on October 8. The disclosure deserves attention because it describes a permission problem that a convincing sandbox diagram can conceal. It also deserves careful boundaries: this is newly published research about an earlier configuration, not evidence that every current Amazon agent deployment is compromised.

Zenity says it linked a public-facing agent's request capability to access to workload credentials, then used an overly broad execution role to reach other agents and related resources within the same AWS account and region. The vendor's announcement describes remediation following its disclosures. Neither that account boundary nor the historical timing is optional context. Remove them, and a useful security story becomes an inaccurate claim about a cloud-wide breach.

Two boundaries, two different jobs

A runtime boundary determines where code executes and what neighboring compute it can touch. An authorization boundary determines which operations a service will accept from that code. Those boundaries can reinforce each other, but they are not interchangeable. Imagine a contractor working in a locked office while carrying a badge that opens every records room in the building. The office lock can work perfectly. The badge remains the problem.

AWS's AgentCore Runtime security guidance explicitly says code inside the microVM can access the execution role through the metadata service. It also warns that automatically generated CLI policies are intended for development and testing, not production. These are important qualifications to any suggestion that access to workload credentials is, by itself, a broken virtualization boundary. The security question is what those credentials authorize and which actions untrusted input can induce.

The design implication is straightforward: a tool-using model should be treated as a possible initiator of unwanted operations, even when its underlying machine remains contained. A business may trust its own application code while accepting customer messages, retrieved documents, web pages or generated plans that it does not trust. The application can carry authority across that trust gap. A malicious instruction does not need to escape the machine if a legitimate API will already do the requested work.

This distinction matters when evaluating a vendor's answer. Strong runtime isolation is valuable. Restrictive permissions are valuable. Evidence for the first does not establish the second. An architecture review should ask for both: proof of the compute boundary and an inventory of the effective authority available inside it. A box labeled “isolated” cannot answer a question about which account resources an attached identity may read or change.

What the disclosure actually establishes

Zenity's research account and timeline place the initial metadata report on December 25, 2025, and the excessive-role report on January 12, 2026. The researchers say a September 29 review found substantially reduced role permissions. October 8 is the public disclosure date. Those dates describe a sequence of reporting and changes, not an October 9 incident response bulletin.

The same account says AWS pointed to metadata-service changes for newly deployed agents during the earlier disclosure process. Current documentation and a historical test are different evidence. A current control may reduce a previously demonstrated path; it does not tell us whether a particular older deployment was updated, whether a customer retained a custom role, or whether the researchers' original configuration matches another organization's environment. Those questions require inspection of the actual deployment.

The role-focused installment describes the consequence of excessive permissions: access could extend to other agents in the same account and region. That is a serious account-level exposure. It is not evidence of access to arbitrary AWS customers. An organization with separate workloads under one administrative account should care about that distinction because its internal segmentation may depend on narrower roles than the account boundary provides.

Cyberdelia has not reproduced the chain, inspected affected customer environments, or independently measured prevalence. Zenity is a security supplier with a commercial interest in agent protection. Its disclosure is a primary account of its own work, not a neutral census of the entire installed base. AWS documentation is a primary account of the platform's intended controls, not an independent demonstration that every customer configured them correctly. Readers need both kinds of evidence without confusing either with universal proof.

Memory can turn an incident into a recurring instruction

The most consequential extension concerns persistence. In its memory investigation, Zenity describes inserting short-term conversation events that configured memory strategies could process into longer-term records. That is more specific than simply claiming an attacker can overwrite any agent's permanent memory. The path depends on the memory configuration, extraction process, later retrieval and the agent's treatment of retrieved material.

The distinction is technically important and operationally uncomfortable. A later session may encounter a stored statement presented as a user preference, prior agreement or useful fact. If the application treats that record as authority, a malicious instruction can acquire a plausible history. The model need not remember the original attacker. It only needs to trust the representation that survived.

Consider a hypothetical assistant that stores a shipping preference. A legitimate record says the customer prefers deliveries after noon. A hostile record claims that invoices should always be sent to a new outside address. Both may look like ordinary personalization data once removed from the conversation that produced them. The safety question is therefore larger than whether the text sounds suspicious: who supplied it, who approved the resulting behavior, and can a downstream action be independently authorized?

Our assessment is that persistent agent memory should have an evidence trail comparable to other operational records. Applications should distinguish a user's verified preference from a model's inference and from content imported from an outside source. Sensitive actions should not gain permission merely because a retrieved sentence claims that permission already existed. These are design recommendations, not capabilities we independently verified in the affected system.

A remediation plan must outlive the demonstration

The immediate engineering task is to inspect effective permissions. Start with the role attached to each deployed workload, then follow the resources and actions it can actually reach. A friendly role name or a narrow-looking application interface is insufficient. A service can expose only two buttons while its runtime identity retains broad access behind them. Resource scope matters as much as the list of permitted API actions.

AWS's IAM guidance recommends least privilege and refining permissions toward actual needs. For agent deployments, our practical interpretation is to make the authorized task explicit before choosing a role. An assistant that summarizes one document collection should not inherit control over unrelated agents merely because both live in the same account. Development convenience should not silently become the production security policy.

Next, examine the route between untrusted input and powerful tools. Can retrieved text choose a request destination? Can a generated plan invoke administration functions? Does a service enforce the user's identity independently, or accept whatever identifier the agent supplies? These questions describe review targets, not a claim that every product has these faults. The point is to locate where a model's interpretation becomes a privileged operation.

Then test recovery. Revoking a credential may stop one access path while leaving altered configuration, newly written records or contaminated memory in place. A credible exercise should identify which logs establish what happened, which state must be reviewed, and which permissions need to be reduced before service resumes. Restoring normal output alone cannot establish that the earlier intrusion left no durable changes.

For a small team, this need not begin with an expensive new platform. Begin with one representative deployment and a written account of its authority: what it reads, what it changes, which identity it uses, and where its persistent state resides. Compare that account with the real configuration. The discrepancies are actionable even before anyone attempts an adversarial prompt. Security improves when the gap between the intended task and the available authority becomes visible.

The measurement that matters

A dramatic demonstration is useful for showing that a path exists. It is weaker evidence for how often the path exists or how much damage it permits elsewhere. Procurement teams should ask for the tested configuration, the date, the prerequisite access and the exact boundary crossed. They should also ask what changed afterward. A demonstration that predates a remediation can still teach a durable architectural lesson while no longer describing the current default.

We would evaluate a claimed fix through separate tests. First, does the original entry route still work under the supported current configuration? Second, if some other route causes an unwanted tool call, do permissions contain the outcome to the intended resource? Third, can untrusted state influence a future session without renewed authorization? These are different failure conditions. Passing one should not be reported as passing all three.

The strongest result would be an agent that remains useful even when its model makes a bad decision: a forbidden operation fails at the service boundary, the attempt is attributable, and the failure does not require the model to recognize that it was being manipulated. That is the standard we would use to judge deployment architecture. It puts the burden on enforceable controls rather than on perpetual good judgment from generated text.

What changes the story from here

Further evidence could move this assessment in either direction. Independent reproduction against a documented current configuration would strengthen concerns about remaining exposure. Clear permission comparisons and bounded regression tests would strengthen confidence in remediation. Evidence of exploitation in customer environments would establish an incident dimension that this disclosure alone does not. Until then, those categories should remain separate.

The story connects directly to our earlier analysis of AI containment on the PC. Whether an agent runs locally or in a cloud service, compute isolation answers only part of the question. The more important operational contract specifies which actions are permitted, on whose behalf, against which resources, and for how long. An agent should not receive additional jurisdiction simply because it has become more capable of using it.

AgentCorruption's durable warning is that a secure room and an overpowered key can coexist. The response is to inspect both. Treat the newly disclosed research as a reason to review current authority and persistent state, not as permission to announce a cloud-wide breach that the evidence does not establish.