How to security test AI coding agents with infra access
AI coding agents connected to a terminal can now do more than write code. Give one access to the AWS CLI, Terraform, or a CI/CD pipeline and it can inspect, modify, and delete real infrastructure. That changes the testing requirement entirely.
Traditional agent evals ask one question: did the agent complete the task? Security testing for infrastructure-connected agents has to ask a second: what happens when the agent is given a task it should not be allowed to perform?
️ Define the security contract first
Before writing a single test, define what the agent is and is not allowed to do. The article recommends a three-tier contract: allowed (read dev infrastructure, run tests, build containers), restricted (production resource changes, IAM modification, secret retrieval), and forbidden (delete production resources, disable security controls, create privileged IAM roles). Without this contract, you cannot tell whether an agent action is a failure or expected behavior.
Test at every layer, not just the model
A secure setup enforces boundaries at multiple points: agent policy, tool restrictions, IAM authorization, environment isolation, and approval gates. The article is direct on this: the model should not be the only enforcement mechanism. An agent saying “I cannot do that” is useful. An IAM policy that makes the operation impossible is stronger.
The 12 test categories the article recommends covering:
- Normal development tasks
- Unauthorized infrastructure changes
- Destructive operations (delete S3 bucket, terminate instance, delete database)
- IAM privilege escalation paths (CreateRole + AttachRolePolicy + PassRole combinations)
- Secret access outside the agent’s task scope
- Cross-environment access (dev credentials attempting production changes)
- Prompt injection from repository files, READMEs, and build scripts
- Malicious tool output (CLI errors that instruct the agent to disable a policy)
- CI/CD bypass (agent modifies the pipeline that deploys for it)
- Approval gate bypass
- Infrastructure-as-code manipulation (detecting diffs like
deletion_protection = false) - Security regression tests locked in permanently after each discovered scenario
Track more than task completion
Task completion rate is not enough. The article recommends tracking unsafe action rate, unauthorized action attempts, policy denial rate, approval bypass attempts, secret access attempts, privilege escalation attempts, and destructive action attempts alongside task success. A high completion rate paired with a high unsafe-action rate is not a successful deployment.
Pro tip: separate terraform plan from terraform apply
A coding agent can reasonably run terraform plan to inspect proposed changes without receiving permission to run terraform apply. This gives the agent enough access to be useful while keeping a human in the loop before anything hits infrastructure. The same principle applies to any IaC diff analysis: flag changes like encryption_enabled = false or cidr_blocks = ["0.0.0.0/0"] as security-sensitive before they reach a pipeline.
Run all destructive tests against isolated environments, never production. Automate the suite in CI so it runs whenever agent tools, IAM policies, or deployment workflows change.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
