Building an isolated sandbox
for autonomous remediation
How I designed and implemented a disposable AWS environment that gave an autonomous coding agent the freedom to mutate data, restart services, and validate changes without putting shared systems at risk.
The automation was useful
because it was destructive.
A large database remediation effort required repeatedly inspecting application behavior, modifying generator logic, exercising API paths, validating database state, and iterating when results were wrong.
The work was repetitive and systematic — a good fit for an autonomous coding agent.
But the agent also needed capabilities that would be unacceptable in a shared development environment:
- Mutate database state
- Truncate and reseed data
- Run and restart application services
- Execute API validation repeatedly
- Iterate without waiting for operator intervention
The problem was therefore not whether the agent could perform the work.
The problem was where it could perform the work safely.
Autonomy required
containment.
An autonomous agent only saves engineering time if it can continue through failures without requiring a human to reset the environment after every mistake.
That meant the execution environment needed to tolerate:
- Broken application state
- Corrupted test data
- Repeated process restarts
- Destructive database operations
- Failed experiments
- Complete environment resets
The shared development environment could not provide that freedom without creating risk for other engineers.
Production was never an acceptable execution target.
The architecture therefore needed to make destructive behavior ordinary inside the sandbox and impossible to propagate beyond it.
The safest place for destructive automation
is an environment designed to be destroyed.
Freedom inside the boundary.
No trust outside it.
I designed the environment around containment rather than attempting to restrict every action the agent could perform inside the sandbox.
Within the isolated environment, the agent could operate the application stack and its MariaDB database freely.
Outside that environment, access was deliberately constrained.
The architecture centered on four principles:
Isolation
The sandbox lived in its own AWS VPC, with the application and database on EC2 in private subnets, separated from production and shared development networks.
Controlled access
Administrative and agent access entered through a bastion and defined, restricted paths rather than exposing the workload directly.
One-way data
A database clone could be seeded into the sandbox without establishing a write path back into shared environments.
Disposability
The entire environment could be recreated from infrastructure code when its state became unreliable.
Contain the blast radius
instead of pretending failures will not happen.
Disposable only works
when rebuild is deterministic.
The sandbox was provisioned with Terraform rather than assembled manually.
The VPC and subnets, security groups, EC2 compute, IAM roles, KMS encryption resources, SSM parameters, storage, and supporting infrastructure were all represented as code.
That mattered because the environment was expected to drift.
The agent could corrupt its database, break the application stack, or leave the runtime in an unknown state. Recovery could not depend on remembering which console settings had been changed.
A clean environment needed to be reproducible from the declared infrastructure state.
Destroy and rebuild became
a recovery mechanism.
Separate the ability to operate
from the ability to escape.
The agent required broad permissions inside the sandbox, but those permissions did not need to extend into the surrounding environment.
I designed the access model around separation of duties, scoped IAM credentials, secrets held in SSM Parameter Store and encrypted with KMS, and deliberately constrained trust boundaries.
- Controlled entry into the sandbox through a bastion
- Private-subnet workload execution behind security groups
- Scoped IAM credentials for the agent
- Encrypted credential storage in SSM Parameter Store with KMS
- No production credentials inside the environment
- No production network path
- One-way test-data seeding from a database clone
- Infrastructure-level ability to destroy and rebuild
The goal was not to claim that the sandbox was impossible to compromise.
The goal was to ensure that compromise or destructive behavior remained contained within a disposable environment.
A sandbox is valuable because
its failure is cheap.
The environment became
an execution loop.
Once provisioned, the sandbox gave the agent a repeatable workflow:
- Start from a known application and data state.
- Inspect the next remediation target.
- Modify the relevant application logic.
- Run the services.
- Exercise the relevant API path.
- Verify the resulting database state.
- Correct failures and repeat.
- Reseed or rebuild when the environment became unreliable.
The important change was not simply automation.
It was removing the shared-environment constraint that previously made aggressive automation unsafe.
The agent could continue iterating because failure no longer carried the same organizational cost.
Containment changed
the economics of iteration.
250
Tables validated
All remediation targets in scope
<2h
Validation cycle
approx. 1 weekunder 2 hours
Zero
Shared-environment disruption
Destructive iteration stayed inside the sandbox
<$100/mo
Sandbox infrastructure
under $100/month
All remediation targets in scope were processed through the autonomous workflow. A validation cycle that previously consumed approximately one week of engineering effort could be executed in under two hours, and destructive iteration remained contained inside the dedicated sandbox.
The architecture enabled
the automation.
The largest productivity improvement did not come from giving the AI agent a better prompt.
It came from giving the agent an environment where it could act.
Without an isolated execution surface, every destructive action would have required additional approval, operator coordination, cleanup, or recovery.
The infrastructure changed that constraint.
It made experimentation cheap enough, isolated enough, and reproducible enough for autonomous remediation to become practical.
Agent capability is only useful
when the environment permits action.
Three principles for
autonomous infrastructure.
- Lesson 01
Design the blast radius first.
Autonomous systems should be given freedom only after the environment defines where failure is allowed to propagate.
- Lesson 02
Disposability is a reliability feature.
When an environment can be recreated predictably, recovery becomes simpler than repairing unknown state.
- Lesson 03
AI infrastructure is still infrastructure.
Agents do not remove the need for networking, IAM, secrets management, reproducibility, and operational controls. They make those boundaries more important.