On May 4, 2026, AWS quietly open-sourced a piece of infrastructure that should change how security teams architect agentic AI deployments… and it should do so in a more specific way than most early coverage suggested.
The project, Trusted Remote Execution — “Rex” for short — gates every system operation an AI-generated script attempts, against a Cedar policy defined by the host owner rather than the agent. The runtime achievement is real. The data security problem it leaves untouched is also real and the most important one.
What AWS solved
The mechanics are clean.
Scripts run in Rhai, a lightweight embedded language that has no built-in access to the operating system. Every read, write, or open is intercepted by a Rex SDK call, which evaluates a Cedar policy before permitting the underlying system call. If the policy denies the action, the script receives an `ACCESS_DENIED_EXCEPTION` and the operation never reaches the kernel.
The script and the policy are versioned separately. The host owner — not the developer who wrote the script, not the agent that may have generated it — defines what is allowed.
The targeted use case is explicit. AWS describes Rex as designed to contain three specific failure modes in agentic AI: hallucinated code, prompt injection, and overly eager task interpretation.
None of those is hypothetical.
Each is a documented attack class, and each has been publicly conceded as unsolvable by the labs building the underlying models. OpenAI stated in late 2025 that prompt injection “is unlikely to ever be fully ‘solved.’” Anthropic acknowledged in research that “prompt injection is far from a solved problem, particularly as models take more real-world actions.”
The architectural inversion is real. Most agentic sandboxes are designed to bound the agent’s behavior. Rex inverts that: rather than trying to bound what the agent generates, it bounds what any host operation the agent invokes can actually accomplish. That is not a refinement — it is a shift in where trust is allowed to live, encoded in production code.
The pattern is the right pattern. AWS’s announcement amounts to a hyperscaler endorsement of an architecture that treats prompts as instructions rather than access controls, and that treats the agent’s claimed identity as something to be verified rather than trusted. Vendor security questionnaires, internal architecture reviews, and audit evidence packages can now reference a working open-source implementation of that pattern.
That is the runtime layer. Adopt it.
What AWS did not solve
Now the part that should change how every security and compliance leader reads this announcement.
Rex governs system calls. It does not govern data security. That distinction is not a footnote. It is the difference between protecting the host from the agent and protecting the data from misuse, and it is the difference between passing a runtime audit and passing a regulatory one.
A Cedar policy can permit `file_system::Action::”read”` on a customer-records file. That is the right policy at the kernel layer. It is the wrong policy — and an inadequate one — at the data layer, which has to ask a different set of questions:
- Is this read happening on behalf of a specific human user with the right authorization, or is the agent acting on its own claimed identity?
- Is the requester operating within the scope of the engagement that authorized access to this data in the first place?
- Are the records returned minimum-necessary for the task, or is the agent pulling more context than the prompt actually requires?
- Are any of the records subject to a deletion request, a legal hold, or a jurisdictional restriction that has not yet propagated to the file system?
- Is the access being logged in a tamper-evident form, with sufficient detail to reconstruct who authorized what — three years from now, when the model that generated the request has been retired and replaced twice?
Rex does not answer those questions. Cedar policies on system calls cannot answer them. They live one layer below the runtime, where the data lives, and that layer is where data security has to be enforced.
Without it, an organization can run every agentic workload through Rex, prove that no script ever exceeded its host permissions, and still be unable to demonstrate to a regulator that the right person authorized the right access to the right data for the right purpose.
This matters operationally and legally. GDPR Article 5 demands purpose limitation, data minimization, storage limitation, and accountability. HIPAA’s minimum-necessary standard requires controls on which data the agent is permitted to access, not just which system calls the agent’s script is allowed to make. CMMC Level 2 access control families assume enforced authorization for AI access to controlled unclassified information.
None of those frameworks is satisfied by runtime gating alone, and none of them is addressed by Rex.
The numbers make the gap concrete
Kiteworks Data Security and Compliance Risk: 2026 Forecast Report found that 63% of organizations cannot enforce purpose limitations on AI agents.
Sixty percent cannot quickly terminate a misbehaving agent. Fifty-five percent cannot isolate AI systems from broader network access. 54% cannot validate AI inputs. Some of those gaps are exactly what Rex closes at the runtime layer — termination, isolation, input validation. Others are not. Purpose limitation is a data-semantics control. It cannot be enforced on a system call. It must be enforced on the data.
Only 43% of organizations have a centralized AI data gateway. The remaining 57% are running agentic AI through fragmented or partial data-layer controls. Adding Rex to that 57% closes the runtime gap and leaves the data gap where it was. The audit-defensible layer is not the kernel. It is the data.
The Five Eyes joint advisory on agentic AI released April 30 and May 1 names five risk categories: privilege, design and configuration, behavior, structural, and accountability. Rex addresses parts of two. It does not address structural risks across multi-agent systems. It does not address the accountability category — the one that auditors and regulators will care about most — because accountability is evidence about who accessed what data, on whose behalf, for what purpose.
A system call audit log does not produce that evidence. A data-layer audit log does.
Must-read security coverage
The architecture data security actually requires
The architecture that holds up under regulatory enforcement is layered, and the layers are not interchangeable.
Runtime controls like Rex enforce what the host will permit. Identity controls enforce who the agent is acting on behalf of. Data-layer controls — attribute-based access control evaluated against classification, jurisdiction, consent, and purpose — enforce what data the agent is allowed to touch. Each layer addresses a different failure mode. None of them substitutes for the others.
The data layer is where data security lives. It is the layer where every access is authenticated against the human user the agent is acting for, where every authorization decision is evaluated against attribute-based policies that respect classification, jurisdiction, and consent, and where every operation produces a tamper-evident audit record that outlives the model that initiated it.
AWS does not provide that layer in the Rex release. It is the architect’s responsibility, and it has to be built explicitly.
What this means for security and compliance leaders
The right operational response to the AWS announcement has three parts.
- First, adopt the runtime pattern. Rex is open-source under Apache 2.0, hosted at github.com/trusted-remote-execution, and runs on Linux and macOS. There is no procurement obstacle.
- Second, do not treat runtime gating as the whole answer. Map current controls against the Five Eyes advisory’s five risk categories and identify where the architecture stops at the kernel and where the data layer is still ungoverned.
- Third, build the audit trail at the layer that survives model lifecycle changes. The model can be retired. The runtime can be replaced. The data layer is the only place where the evidence outlasts the agent that produced it.
AWS solved part of the problem. Data security — the part that actually shows up in audits, regulatory inquiries, breach notifications, and litigation discovery — requires governance at the data layer, and AWS did not address it. The runtime layer just got easier. The data layer is still the architect’s responsibility, and it is the layer that decides whether the next agentic AI audit succeeds or fails.
Also read: AWS’s agentic AI push now extends into hiring, healthcare, supply chains, and customer service.
