Home > Security and Compliance Blog > Cybersecurity Risk Management > AWS Rex Open-Sources the Runtime Layer of Agentic AI Security

AWS Rex Open-Sources the Runtime Layer of Agentic AI Security

by Danielle Barbour updated May 28, 2026 Cybersecurity Risk Management

Reading Time: 7 minutes

On May 4, 2026, AWS published Introducing Trusted Remote Execution: Policy-Enforced Scripts for AI Agents and Humans, open-sourcing Rex under the Apache 2.0 license. The architecture is straightforward: scripts are written in Rhai, a lightweight embedded language with no built-in OS access. The only way for a script to reach the host is through a purpose-built SDK. Every operation is authorized against a Cedar policy before the system call is permitted. If the policy denies the action, the script receives an ACCESS_DENIED_EXCEPTION and the operation never reaches the kernel.

AWS is conceding, in production code, what the security research community has argued for two years: code review, approval workflows, and allowlisted commands cannot govern code generated at runtime by an AI system. The traditional safety nets stop working when the agent is the author.

Table of Contents

5 Key Takeaways

1. AWS introduced runtime policy enforcement as a category.

Trusted Remote Execution (Rex) gates every system operation an AI-generated script attempts, against a Cedar policy defined by the host owner — not the agent. This is the first major hyperscaler-backed acknowledgement that the runtime layer of agentic AI security cannot be left to the agent itself. When AWS ships production infrastructure on the assumption that prompt injection will not be solved, the implication for enterprise architects is unambiguous: design as if the agent will misbehave.

2. The threat model is explicit and uncomfortable.

AWS names hallucinated code, prompt injection, and overly eager task interpretation as the specific failure modes Rex is designed to contain. OpenAI has stated prompt injection “is unlikely to ever be fully ‘solved.'” Anthropic has acknowledged it remains far from solved “particularly as models take more real-world actions.” Rex ships on those concessions — and so should your AI governance architecture.

3. Rex constrains the host, not the agent.

Most agentic sandboxes try to bound what the model produces. Rex inverts that: regardless of what the agent generates, the system call cannot exceed what the policy permits. This architectural inversion — shifting the enforcement perimeter to what the agent can do against the host — is not an incremental refinement. It is a shift in where trust is allowed to live. Trust moves from the agent’s outputs to the host’s policy engine.

4. Runtime gating is necessary. It is not sufficient.

Cedar policies on system calls cannot tell an agent which document it should not have asked for, which fields satisfy minimum-necessary, or whether a retrieval crosses a jurisdictional boundary the data classification flags as out-of-bounds. These are the controls GDPR Article 5, HIPAA‘s minimum-necessary standard, and CMMC Level 2 access control families require. Rex does not answer them.

5. The audit-defensible layer is below the runtime.

Regulators, auditors, and plaintiffs will ask for evidence of who authorized what data access. That evidence has to live where the data lives — in tamper-evident audit trails covering every AI interaction with regulated content. A policy permitting a system-call read is the right policy at the runtime layer. It is the wrong policy at the data layer, and those are different instruments.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

What AWS Is Conceding About Agentic AI

Three architectural concessions in the AWS announcement matter as much as the code.

The first is the threat model. Hallucinated code, prompt injection, and overly eager task interpretation are named explicitly — not as theoretical edge cases but as the specific failure modes Rex is built to contain. When a hyperscaler ships infrastructure on the assumption these problems will not be solved, enterprise architects should design accordingly.

The second is the architectural inversion. Rex shifts the enforcement perimeter to what the agent can do against the host, rather than trying to bound the agent’s outputs. That phrasing is precise: constraining the agent assumes its outputs can be reliably bounded. Shifting to the host assumes those bounds are unreliable and moves enforcement to where the system actually executes. This is a trust architecture decision, not a feature decision.

The third is in the policy model. Cedar — open-sourced by AWS in May 2023 and now a CNCF Sandbox project — supports both RBAC and ABAC. The host owner, not the agent, defines the policy. The script and the policy are versioned separately. This is policy-as-code applied to the system call layer — the right layer for that pattern, and also the only layer Rex addresses.

Why Runtime Gating Is Necessary

Rex solves a real problem. Most script execution environments give scripts whatever permissions the execution context has — a script intended to read a log file can just as easily delete one. When that script is generated by an AI agent at runtime, traditional review controls never get a chance to operate. A misbehaving agent in such an environment is one badly-interpreted task away from production damage.

The Kiteworks 2026 Forecast quantifies this exposure. 63% of organizations cannot enforce purpose limitations on AI agents. 60% cannot quickly terminate a misbehaving agent. 55% cannot isolate AI systems from broader network access. 54% cannot validate AI inputs. Rex-style runtime policy enforcement materially closes the first and last of those gaps. There is also a regulatory dimension: organizations under EU AI Act pressure are building the runtime, identity, and policy infrastructure Rex represents faster than peers operating outside that perimeter. The advisory environment is closing that gap quickly across all jurisdictions.

Why Runtime Gating Is Not Sufficient

Rex is a runtime control. It governs system calls. It cannot tell an agent which document it should not have asked for in the first place. It cannot enforce that a returned record contains only the fields the human user is authorized to see. It cannot assess whether a retrieval crosses a jurisdictional boundary that the data classification flags as out-of-bounds.

These are not theoretical edge cases. They are the controls GDPR Article 5 demands — purpose limitation, data minimization, storage limitation, accountability. They are what HIPAA’s minimum-necessary standard requires. They are what CMMC Level 2 access control families assume. They are what the CISA, NSA, and Five Eyes joint advisory on agentic AI named explicitly in its accountability and privilege risk categories.

A policy permitting file_system::Action::"read" on /var/data/customer-records.csv is the right policy at the runtime layer. It is the wrong policy at the data layer. The data layer has to ask different questions: Is this read happening on behalf of a user with the right authorization? Is the requester operating within the scope of the engagement that authorized them? Are the records minimum-necessary for the task? Are any subject to a deletion request that has not yet propagated? Is the access being logged with sufficient detail to reconstruct who authorized what three years after the model has been retired? Rex does not answer those questions.

The Architectural Picture That Actually Works

The pattern that works is layered. 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 controls evaluated against classification, jurisdiction, and consent — enforce what data the agent is allowed to touch. Each layer addresses a different failure mode, and no single layer is sufficient.

The Kiteworks Secure MCP Server and AI Data Gateway implement the data-layer component of this architecture: every AI operation is authenticated via OAuth 2.0, evaluated against ABAC policy in the Kiteworks Data Policy Engine, encrypted with FIPS 140-3 validated cryptography, and logged in a tamper-evident audit trail feeding existing SIEM infrastructure. The Kiteworks Private Data Network extends that governance across email, file sharing, MFT, SFTP, web forms, and APIs under one policy engine and one consolidated audit log.

AWS just shipped strong infrastructure for the runtime layer. The identity layer and data layer still have to be built — and the Kiteworks 2026 Forecast confirms that only 43% of organizations have a centralized AI data gateway in place.

What Security and Compliance Teams Should Take Away

First, take the AWS announcement seriously as a signal. When a hyperscaler open-sources a runtime gating every system call against a policy independent of the agent, runtime policy enforcement is no longer optional in serious AI deployments. Rex closes a meaningful runtime-layer gap that most organizations have left open.

Second, do not confuse runtime enforcement with data governance. Rex addresses what an agent can do on a host. It is silent on what data the agent is allowed to touch. Adding runtime control without data-layer governance does not close the audit gap — it documents one layer while leaving the other open.

Third, design the layered architecture explicitly. Map runtime controls (Rex), identity controls (OAuth, short-lived credentials), and data-layer controls (ABAC, classification, jurisdiction, consent) to the specific failure modes each addresses. Each layer asks different questions; each is necessary for a complete answer.

Fourth, treat policy version control as audit evidence. Cedar’s separation of policy and code produces artifacts auditors can inspect. Pair Rex’s runtime artifacts with tamper-evident data-layer audit logs to produce a complete evidence package — the gap between visibility into what ran and visibility into what data was touched is where most audit findings originate.

Fifth, use the Five Eyes joint advisory as the architectural test. Apply the CISA “Careful Adoption of Agentic AI Services” five risk categories — privilege, design and configuration, behavior, structural, accountability — to your current AI deployment. Rex addresses parts of privilege and behavior. Structural and accountability categories require data-layer governance that no runtime alone can provide.

To learn more about governing sensitive data while optimizing AI agents, schedule a custom demo today.

Frequently Asked Questions

Rex addresses script-level system call enforcement — the layer where an agent-generated script is gated by a Cedar policy before any read, write, or open reaches the kernel. It does not replace identity controls, network segmentation, or data-layer governance. Only 43% of organizations have a centralized AI Data Gateway per the Kiteworks 2026 Forecast. Adding Rex without that data layer closes one gap and leaves a broader one open.

Cedar’s policy-as-code model produces versioned artifacts that satisfy SOC 2 CC6 access controls and ISO 27001 A.5/A.8 access management — but is not sufficient evidence of authorization at the data layer. Pair Rex’s runtime audit trail with data-layer ABAC enforcement and tamper-evident logs to produce a complete evidence package. Auditors increasingly request containment evidence — proof that a misbehaving agent can be terminated and isolated quickly.

No. HIPAA‘s minimum-necessary standard requires controls on which data the agent is permitted to access on behalf of an authorized user — not just which system calls the script is allowed to make. Purpose limitation is a data-semantics control. 63% of organizations cannot enforce it on AI agents per the Kiteworks 2026 Forecast. Runtime controls and data-layer ABAC enforcement work together; neither replaces the other.

Rex addresses parts of two of the five risk categories in the CISA advisory: privilege risks (enforcing least privilege on system operations) and behavior risks (containing hallucinated or injected code). It does not address structural or accountability risk categories. The accountability category — which auditors and regulators scrutinize most — requires a data-layer audit trail that runtime gating alone cannot produce.

There is some overlap and clean separation. Rex enforces policy at the system-call boundary inside a host. Identity-aware proxies and service mesh policies enforce policy at network and request boundaries. Both are runtime controls at different stack layers. Network isolation of AI systems — a gap that mesh policies address but Rex does not — remains an industry-wide deficiency. Layered enforcement is the architectural answer; treating any single layer as sufficient is the architectural mistake. The Kiteworks Private Data Network provides the data-layer component this stack needs.

Additional Resources