Governed AI Agent Sandbox on AWS: Architecture, MCP, and Controls

AI agents are moving from chat to execution. They are no longer just answering questions. They are running code, calling tools, reading repositories, querying internal systems, opening tickets, analyzing files, and taking action across business workflows.

That changes the architecture problem. If an agent can act, it needs a governed place to act from.

For AWS-first organizations, the question is not only which model to use. The harder question is where agent execution happens, what the agent can reach, which credentials it receives, how tools are exposed, where human approval is required, and how every action is audited.

In other words: agents need a perimeter. Models provide the reasoning. Tools create the impact. The sandbox defines the blast radius.

What is a governed AI agent sandbox?

A governed AI agent sandbox is a controlled execution boundary where agents can run code, call approved tools, access scoped data, and interact with internal systems under explicit identity, network, logging, policy, and approval controls.

It is not a prompt template, a chatbot wrapper, or a container with a broad API key. It is an operating pattern for deciding what an agent is allowed to do, which tools it can call, which identity it acts under, which network paths it can reach, what gets logged, and when a human must approve the next step.

Who this is for

Good fit	Probably not the first priority
Teams giving agents access to repositories, CI logs, files, data stores, tickets, internal APIs, or AWS resources	Simple chat assistants that answer questions without tool execution or private data access
Platform, security, and AI teams standardizing how multiple agent workflows should run on AWS	One-off experiments where the agent has no credentials, no write path, and no persistent workflow role
Organizations that need auditability, least privilege, private connectivity, and human approval before agents touch production workflows	Teams still deciding whether agents have enough business value to justify controlled execution

Why Claude's sandbox update matters

Claude's Managed Agents update is a useful market signal because it separates the agent loop from tool execution. Anthropic describes customer-controlled sandboxes and private MCP connectivity so tools can execute inside infrastructure the customer controls. The announcement also notes that self-hosted sandboxes are in public beta and MCP tunnels are in research preview, so teams should treat those capabilities as emerging infrastructure, not a finished enterprise standard.

The AWS lesson is broader than Claude. Enterprise agent execution, tool access, identity, observability, and approval paths need to be designed as part of the governed cloud environment.

The six control layers

Layer	Question to answer	AWS-native direction
Runtime	Where does the agent run, scale, and stop?	AgentCore Runtime, ECS, EKS, Fargate, Lambda, or a custom runtime
Tools	Which actions can the agent call?	AgentCore Gateway, MCP servers, API Gateway, Lambda, approved action catalogs
Identity	Who or what does the agent act as?	IAM, Identity Center, Cognito, AgentCore Identity, scoped service roles
Network	What can the runtime reach?	VPC design, private subnets, egress controls, PrivateLink, security groups
Data and secrets	Which files, datasets, and credentials can enter the workflow?	S3 policies, Secrets Manager, KMS, short-lived credentials, isolated filesystems
Evidence and approval	What is logged, evaluated, reviewed, and blocked?	CloudWatch, CloudTrail, OpenTelemetry, AgentCore Observability, evaluations, policy gates

Amazon Bedrock AgentCore fits this conversation because AWS positions it as an agentic platform for building, deploying, operating, monitoring, and evaluating agents with capabilities such as Runtime, Gateway, Policy, Memory, Identity, Evaluations, Observability, Code Interpreter, and Browser. AgentCore Gateway can expose APIs, Lambda functions, and existing services as MCP-compatible tools. AgentCore Code Interpreter gives agents a sandboxed environment for writing and executing code.

Which sandbox pattern fits?

Pattern	Use when	Watchouts
AgentCore Runtime plus AgentCore Gateway	You want managed agent deployment, MCP-compatible tool access, identity integration, observability, and policy controls	Verify region availability, pricing, quotas, service maturity, and fit for your framework and data residency requirements
AgentCore Code Interpreter	The agent needs controlled code execution, analysis, file processing, or generated scripts	Validate filesystem behavior, network mode, package installation, logging, and isolation against your risk model
ECS or Fargate sandbox	You need custom containers, package control, repeatable images, and familiar AWS operations	Requires platform engineering for isolation, lifecycle, identity, and egress controls
EKS sandbox	You already standardize workloads on Kubernetes and need advanced isolation or platform policies	Operational complexity can exceed the value of an early pilot
Lambda tools	The agent only needs narrow, deterministic actions behind approved function calls	Not ideal for long-running, stateful, or package-heavy agent work
Hybrid pattern	You want one agent runtime but separately governed tools, sandboxes, and approval paths	More moving parts, but often the strongest control model for enterprise workflows

Agent demo vs governed agent system

Agent demo	Governed agent system
Runs on a developer laptop or SaaS connector	Runs in an approved AWS runtime
Uses broad user or service credentials	Uses scoped, auditable, purpose-specific credentials
Calls tools directly	Calls approved actions through a gateway or MCP interface
Has unclear egress and network reach	Uses explicit VPC, PrivateLink, security group, and egress rules
Logs the final answer	Logs tool calls, arguments, approvals, failures, and side effects
Works for one experiment	Becomes a reusable platform pattern for many workflows
Relies on trust in the model	Relies on architecture, policy, logging, and human approval

A practical first pilot

Start with one workflow, not a platform program. A strong first candidate is a developer agent that reviews failed CI jobs, inspects a repository, proposes a fix, runs tests in a sandbox, and opens a pull request for human review.

Resource	Access needed	Risk	Control
Git repository	Read plus branch write	Code modification	Scoped token, branch policy, PR-only changes
CI logs	Read	Sensitive build output	Read-only role, log filtering, retention policy
Package registry	Read and install	Supply chain exposure	Approved registries, lockfiles, egress control
Secrets	Ideally none	Credential leakage	No direct secret access; brokered access only when justified
Internal APIs	Limited actions	Business side effects	Tool gateway, allowlisted operations, approval rules
Runtime filesystem	Temporary files	Persistence or exfiltration	Ephemeral workspace, cleanup policy, file logging

MCP is an interface, not a governance model

MCP is useful because it gives agents a standard way to discover and call tools. It does not, by itself, decide whether the tool is safe, who approved it, which identity is used, what arguments are allowed, or how the action is audited.

Pattern	Risk	Better control
Agent receives broad credentials and calls services directly	Credential exposure, over-permissioning, weak audit trail	Avoid for production workflows
Agent calls MCP tools that wrap internal systems	Tools can still be too broad or poorly logged	Use scoped tools, typed schemas, argument validation, and per-tool permissions
Agent calls approved actions through a governed gateway	More design work	Best default for sensitive workflows: explicit identity, policy, logging, approvals, and failure modes

Do not give agents broad credentials. Expose approved actions through a controlled interface with scoped identity, an audit trail, and clear permission boundaries.

Failure modes to design for

Failure mode	Control to design
Prompt injection asks the agent to ignore policy or leak data	Tool-level authorization, output filtering, scoped data access, evaluation tests
The agent chooses the wrong tool or wrong arguments	Typed tool schemas, semantic tool filtering, argument validation, dry-run modes
The runtime inherits broad developer permissions	Dedicated service roles, short-lived credentials, permission boundaries
Generated code reaches the public internet or unknown package sources	Egress controls, approved registries, network logging, isolated package cache
The agent loops, retries, or runs expensive tasks	Budgets, timeouts, concurrency limits, circuit breakers, token and compute metrics
A tool changes production state without review	Human approval gates, PR-only changes, rollback paths, CloudTrail evidence

What to validate before production

• Which roles the agent assumes and which resources each role can touch.
• Whether credentials are temporary, rotated, and auditable.
• Which private and public endpoints the runtime can reach.
• How tool calls, arguments, files, prompts, outputs, and approvals are logged.
• Where human approval is required for writes, deletion, money movement, customer data, or regulated records.
• How failures, loops, cost spikes, package risk, and rollback are handled.
• Which data can enter prompts, tools, logs, temporary files, and model-provider contexts.
• Whether the selected AWS services are available in the required Regions. The AgentCore FAQ lists current regional availability; teams with Canadian or Brazilian data residency requirements should verify fit before designing around any one managed capability.
• Whether pricing, quotas, preview/beta status, and compliance claims have been checked against current AWS and vendor documentation.

How Elevata helps

Elevata helps AWS-first teams design the runtime, tool gateway, identity model, network controls, observability plan, approval gates, and pilot path before agent prototypes become shadow infrastructure.

A practical architecture review should leave you with a candidate workflow, a resource-access map, a sandbox pattern recommendation, an IAM and tool-access model, a logging and evidence plan, a production-readiness checklist, and the risks that need security review before launch.

Planning an agent workflow on AWS? Book an Agent Sandbox Architecture Review and bring one workflow you want to govern: a coding agent, data analysis agent, support agent, security triage agent, finance workflow, or internal process agent.

FAQ

Is a code execution sandbox enough to make AI agents safe?

No. Code isolation is necessary, but production safety also depends on scoped identity, restricted network access, approved tool interfaces, secrets handling, audit logs, human approval for risky actions, rollback plans, and continuous evaluation.

Should we use AgentCore or build on ECS, EKS, Fargate, or Lambda?

Use managed AgentCore capabilities when they fit your region, framework, identity, observability, and tool-access requirements. Use ECS, Fargate, EKS, Lambda, or a hybrid pattern when you need custom runtime images, platform-standard controls, or narrower deterministic tools.

Where does MCP fit?

MCP is a useful interface for exposing tools to agents. It should sit inside a governance model that controls identity, allowed actions, argument validation, logging, network reach, and approval paths.

What is the safest first use case?

A developer agent that proposes changes through pull requests is often a good pilot because it has real utility, clear audit trails, existing review gates, and a natural rollback path.