AI coding agents are becoming increasingly capable of doing more than generating code.

They can open terminals, execute commands, modify infrastructure-as-code, interact with cloud environments, and perform tasks that previously required a human engineer sitting at a keyboard.

That creates an interesting security question.

If an AI agent is allowed to execute:

terraform plan

what prevents the same agent from executing:

terraform destroy

The obvious answer is permissions.

An agent should only have access to the permissions it actually needs.

That's absolutely true.

But I think there is another useful layer to consider: a deterministic enforcement boundary between an AI agent and infrastructure tools.

Instead of relying exclusively on the agent to decide whether a command is appropriate, what if commands were independently evaluated before execution?

That's the question I've been exploring with a small open-source proof of concept called AWS SafeBox.

The problem isn't that AI agents are malicious

The interesting threat model here isn't necessarily an attacker controlling an AI agent.

Consider a perfectly legitimate engineering task.

An engineer asks an agent to investigate a Terraform configuration, correct a problem, and validate the result.

The agent may have access to tools such as:

terraform aws kubectl

Most of the commands it might execute are harmless:

terraform plan aws ec2 describe-instances kubectl get pods

But the same tools expose destructive operations:

terraform destroy aws ec2 terminate-instances \ --instance-ids i-xxxxxxxx aws rds delete-db-instance \ --db-instance-identifier production-db aws s3 rm s3://production-data \ --recursive kubectl delete namespace production

The difference between those two groups of commands is enormous.

Yet from the perspective of the agent, they're all simply commands available in its environment.

Why not just ask the AI whether the command is safe?

One possible approach is to put another AI decision in the path.

The agent proposes:

terraform destroy

Another model evaluates the command and decides whether it should execute.

That could certainly provide useful context.

But for some controls, I prefer something considerably less intelligent.

A deterministic policy.

For example:

terraform plan -> ALLOW terraform destroy -> BLOCK

There is no probability involved.

There is no prompt interpretation.

There is no model deciding that perhaps destroying the environment is appropriate given the conversation.

The policy simply says that this operation isn't permitted.

This isn't a replacement for IAM, operating-system controls, sandboxing, approvals, or other security mechanisms.

It's another possible layer.

Building a small proof of concept

I built AWS SafeBox to experiment with this idea.

It's an open-source Python project that places a policy-checking layer in front of infrastructure command-line tools.

The basic model looks like this:

AI coding agent | v SafeBox execution boundary | v Deterministic policy evaluation | +------ ALLOW ------> Real CLI tool | +------ BLOCK ------> Stop execution

The Community Edition currently understands commands involving:

terraform aws kubectl

and contains default policies for destructive operations including:

terraform destroy kubectl delete aws ec2 terminate-instances aws rds delete-db-instance aws s3 rm --recursive aws cloudformation delete-stack

For example:

safebox check "terraform plan"

returns an allow decision.

While:

safebox check "terraform destroy"

is blocked by policy.

SafeBox can also create executable proxies for supported tools.

The idea is that an AI coding agent calling:

terraform

encounters the SafeBox proxy first.

SafeBox evaluates the command and only invokes the real Terraform executable when the policy allows it.

Commands aren't always simple

One interesting part of building the proof of concept was realizing that checking the first few words of a command isn't enough.

An agent might generate:

sudo terraform destroy

or:

FOO=bar terraform destroy

or:

/usr/local/bin/terraform destroy

or:

bash -c "terraform destroy"

Commands may also be chained:

terraform plan && terraform destroy

So SafeBox normalizes commands before evaluating them.

It also fails closed for shell constructs it doesn't understand sufficiently.

The principle is:

SafeBox either understands the command sufficiently to evaluate it, or blocks it.

That behavior is intentional.

For an execution guardrail, I would rather have an unknown command require investigation than silently allow something the policy engine didn't understand.

The current implementation has an important limitation

This is a proof of concept, not a hardened sandbox.

That distinction matters.

The current implementation relies on local executable proxies being placed earlier in PATH.

A capable process can bypass that mechanism.

For example, if it knows the absolute path of the real executable, a local proxy is not an OS-level security boundary.

So the current architecture should not be interpreted as:

AI agent | IMPOSSIBLE-TO-BYPASS SECURITY BOUNDARY | AWS

It is better described as a local execution guardrail.

That raises what I think is actually the more interesting architectural question.

Where should the real enforcement boundary live?

A production-grade implementation could potentially enforce policy at a stronger boundary.

For example:

 +---------------------+ | AI coding agent | +----------+----------+ | v +---------------------+ | Enforcement layer | +----------+----------+ | Policy + context | +----------+----------+ | | ALLOW BLOCK | v +------------------+ | Cloud credentials| | / execution path | +------------------+ | v AWS

One possibility is credential brokering.

Instead of giving an AI agent unrestricted AWS credentials and then trying to prevent dangerous commands locally, the enforcement system could control which credentials or permissions become available for a particular operation.

Other approaches could include:

  • isolated execution environments;
  • short-lived credentials;
  • restricted IAM roles;
  • explicit approval boundaries;
  • Terraform plan inspection;
  • AWS account awareness;
  • production vs. non-production policies;
  • organization-level policies;
  • resource metadata;
  • deletion-protection awareness;
  • estimated blast radius.

For example, imagine an agent attempting to apply a Terraform plan.

The policy engine knows:

AWS account: Production Identity: AI-Agent-Role Terraform plan: - Destroy RDS database - Delete S3 bucket - Modify 4 EC2 instances RDS deletion protection: Enabled Environment classification: Production

A policy could then deterministically conclude:

BLOCK Reason: Production policy prohibits AI-initiated destruction of persistent data resources.

That's considerably more interesting to me than maintaining an ever-growing list of dangerous command strings.

But does this solve a real problem?

That's the question I'm trying to answer before building anything more sophisticated.

It's easy for engineers to see a technical problem and immediately start designing the larger system.

Credential brokers.

Policy engines.

Terraform parsers.

AWS integrations.

Dashboards.

Approval workflows.

Before doing that, I'd rather find out whether teams actually want this additional enforcement boundary.

Maybe the correct answer is simply:

An AI agent should never receive permissions capable of performing those operations.

Maybe existing IAM controls and isolated development environments already solve the problem adequately.

Maybe companies will want agents capable of performing privileged infrastructure operations, but only behind deterministic policies.

Or perhaps the useful boundary isn't command execution at all. It might be credentials, infrastructure plans, cloud APIs, or something else.

Those are exactly the questions I'm interested in.

The experiment is open source

AWS SafeBox Community Edition is available on GitHub under the MIT License:

github.com/aws-safebox/aws-safebox

The current implementation is deliberately small.

I'm not trying to present the proof of concept as a complete security platform.

I'm using it to explore a broader question about how increasingly autonomous coding agents should interact with infrastructure.

If you work with AI coding agents, AWS, Terraform, Kubernetes, DevOps, platform engineering, or cloud security, I'd be particularly interested in your perspective:

Do AI coding agents need a deterministic enforcement boundary before they can modify infrastructure?

And if they do, where should that boundary actually live?

At the command line?

At the credential layer?

At the Terraform plan?

At the cloud API?

Or somewhere else entirely?

Even if you think the entire idea is unnecessary, I'd like to hear why.