Skip to main content
A code execution agent generates code from natural language and runs it in a sandbox. The risk profile is unlike a traditional application: the agent decides what to write and execute, the “threat actor” and “authorized user” can be the same process, and static analysis doesn’t apply to code that doesn’t exist yet. Governance treats every execution as a first-class, authorizable event. The gateway restricts which tools the agent can call, Cedar rules bound the surfaces it can reach, response filtering strips sensitive data before it flows back to the model, and every call lands in an immutable audit trail.

Threat Model

Governance Approach

Implementation

1

Register the agent with capabilities

Register the code execution agent with the capability it needs:
2

Configure the sandbox backend

Add the code execution sandbox as a backend with field classifications on sensitive output fields:
--gateway makes the connection reachable through a Gateway; the agent also needs a grant to that Gateway.
3

Define Cedar authorization rules

Write rules that permit the agent to call only sandbox tools and forbid access to production infrastructure:
See the Policy Example below for the Cedar rule content.
4

Simulate before deploying

Test the rules against historical events to verify they do not break existing workflows:
Review the DecisionDiffs to confirm that only the intended changes occur.
5

Enable audit streaming

Stream audit events for real-time monitoring of code execution activity:
Every tool call, authorization decision, and field redaction action appears in the audit stream.

Policy Example

code-exec-rules.cedar
Cedar evaluates all rules against every request. If any forbid matches, the request is denied regardless of permit rules. The default decision when no rule matches is deny.

Next steps