DEV Community

Cover image for What Should Stop an AI Coding Agent From Running terraform destroy?
AWS Safebox
AWS Safebox

Posted on AI-assisted

What Should Stop an AI Coding Agent From Running terraform destroy?

#ai #security #aws #devops

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
Enter fullscreen mode Exit fullscreen mode

what prevents the same agent from executing:

terraform destroy
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Most of the commands it might execute are harmless:

terraform plan
aws ec2 describe-instances
kubectl get pods
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The Community Edition currently understands commands involving:

terraform
aws
kubectl
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

For example:

safebox check "terraform plan"
Enter fullscreen mode Exit fullscreen mode

returns an allow decision.

While:

safebox check "terraform destroy"
Enter fullscreen mode Exit fullscreen mode

is blocked by policy.

SafeBox can also create executable proxies for supported tools.

The idea is that an AI coding agent calling:

terraform
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

or:

FOO=bar terraform destroy
Enter fullscreen mode Exit fullscreen mode

or:

/usr/local/bin/terraform destroy
Enter fullscreen mode Exit fullscreen mode

or:

bash -c "terraform destroy"
Enter fullscreen mode Exit fullscreen mode

Commands may also be chained:

terraform plan && terraform destroy
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

A policy could then deterministically conclude:

BLOCK

Reason:
Production policy prohibits AI-initiated destruction
of persistent data resources.
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (4)

Collapse
 
techdevfun profile image
TECHDEV •

Your fail-closed rule — either the guard understands the command well enough to evaluate it, or it blocks it — is the part I'd keep whatever layer you pick. A guard that silently allows what it can't parse is worse than no guard, because it teaches the agent the boundary is negotiable.

On your closing question, I'd put the real boundary at the plan, with credentials as the backstop, and keep the command layer only as a cheap first filter. The reason is spelling: the same destruction arrives under many command strings. terraform apply -destroy destroys without ever saying destroy; aws s3api delete-bucket is not aws s3 rm --recursive; a kubectl apply --prune can delete by omission. A denylist of dangerous strings will always lag the next verb or flag.

A plan, by contrast, gives you a deterministic blast radius before anything runs: resource addresses plus create/update/delete, independent of how the agent spelled the command. That's where a production rule like "no AI-initiated deletion of persistent data" can actually be checked.

The command layer alone can't be the backstop either, for the reason you note: an agent that can reach the cloud API directly via SDK or curl walks around any CLI proxy. So the credential layer has to be the floor — a short-lived role that simply cannot delete persistent data, whatever path the agent takes. Does that ordering match how you're thinking about SafeBox's next step, or do you see the plan layer as too Terraform-specific to generalize to kubectl and the AWS CLI?

Collapse
 
aws-safebox profile image
AWS Safebox •

Thanks — this is exactly the kind of feedback I was hoping to get.

I agree that the command layer by itself can't be the final security boundary. I see it more as an inexpensive first filter, especially for obvious destructive operations.

The plan/intent layer is particularly interesting. One of the problems I'm trying to think through is exactly what you pointed out: the same infrastructure outcome can be reached through many different commands, so continuously expanding a command denylist doesn't seem like the right long-term solution.

The credential layer also seems like the strongest backstop to me. If the agent never receives credentials capable of performing certain classes of operations, bypassing the CLI guard doesn't bypass the actual security policy.

Where I'm less certain is how to generalize the "plan" concept beyond Terraform. Terraform gives us a convenient representation of intended changes, but AWS CLI and kubectl don't necessarily provide the same clean intermediate artifact.

That's one of the reasons I released this early rather than building much further. I'm trying to understand whether the useful direction is command filtering + infrastructure intent analysis + credential enforcement, or whether teams would solve this primarily at the credential/authorization layer and skip the other layers.

Really appreciate the detailed feedback.

Collapse
 
robertpaschal profile image
Odinaka Robert Nnamani •

the stop has to live outside the agent, otherwise it just talks itself past it.

Collapse
 
aws-safebox profile image
AWS Safebox •

That's exactly the principle I'm exploring. I don't want the agent itself to be the final authority on whether its proposed action is safe. The enforcement decision should happen outside the agent.