Use Cases/DevOps Agents

The agent ran terraform destroy on production. Then it lied about it.

Coding agents and infrastructure tools have shell access, file system control, and deployment permissions. Veto intercepts each governed tool call before execution: blocking destructive commands, restricting file access, and requiring human approval for production changes.

Shell command filteringDeployment approvalsInfrastructure protection

Production commands need an enforcement point

A coding agent can receive valid credentials, pass authentication, and still attempt a destructive command: delete data, run a migration, mutate infrastructure, or push code during a freeze. The common thread is not failed login. It is a missing authorization check at the command boundary.

Risks in DevOps AI agents

Coding agents and infrastructure automation tools have broad access to critical systems. When an agent has shell access and deployment permissions, a malicious instruction can become a database deletion, a leaked secret, or an infrastructure mutation before a human reads the transcript.

Destructive commands

rm -rf, terraform destroy, DROP TABLE, kubectl delete: agents execute these without the hesitation a human engineer would have.

Infrastructure damage

Uncontrolled modifications to cloud resources, Kubernetes deployments, and database schemas. One Terraform mishap destroyed an entire production stack.

Secret exposure

Agents can read .env files, access SSH keys, and expose credentials in logs. Copilot has been shown susceptible to secret leakage via targeted prompts.

Shell command policies

Block destructive patterns, allow read-only operations, and require approval for privileged commands. These policies target destructive command patterns before they reach the shell.

veto/policies/devops.yaml
policies:
  # Block destructive commands entirely
  - name: "Block destructive shell commands"
    match:
      tool: "shell_exec"
      arguments:
        command: "(rm -rf|dd if=|mkfs|> /dev/sd).*"
    action: deny
    response:
      error: "Destructive commands are not permitted"

  # Block remote script execution
  - name: "Block curl pipe to bash"
    match:
      tool: "shell_exec"
      arguments:
        command: "(curl|wget).*\|.*(bash|sh)"
    action: deny
    response:
      error: "Remote script execution is blocked"

  # Block infrastructure destruction
  - name: "Block terraform destroy"
    match:
      tool: "shell_exec"
      arguments:
        command: "terraform destroy.*"
    action: deny
    response:
      error: "terraform destroy requires manual execution"

  # Require approval for production deployments
  - name: "Approve production deployments"
    match:
      tool: "shell_exec"
      arguments:
        command: "(kubectl apply|terraform apply|helm upgrade|sam deploy).*"
    action: require_approval
    approval:
      timeout_minutes: 30
      channels: [approval_channel]
      reason: "Production deployment requires human approval"

  # Require approval for sudo commands
  - name: "Approve sudo commands"
    match:
      tool: "shell_exec"
      arguments:
        command: "^sudo .*"
    action: require_approval
    approval:
      timeout_minutes: 15
      channels: [approval_channel]

  # Allow read-only operations
  - name: "Allow read operations"
    match:
      tool: "shell_exec"
      arguments:
        command: "^(ls|cat|grep|find|head|tail|echo|pwd|which|env) .*"
    action: allow

File path restrictions

Control which files agents can read, write, and delete. Protect sensitive configurations, credentials, and production configs from unauthorized modification.

veto/policies/files.yaml
policies:
  # Block access to system and credential directories
  - name: "Protect system paths"
    match:
      tool: ["read_file", "write_file", "delete_file"]
      arguments:
        path: "^(/etc/|/root/|.*\.ssh/|.*\.aws/).*"
    action: deny
    response:
      error: "Access to system paths is not permitted"

  # Block environment file modifications
  - name: "Protect environment files"
    match:
      tool: ["write_file", "delete_file"]
      arguments:
        path: ".*\.env(\..*)?$"
    action: deny
    response:
      error: "Environment file modifications require manual review"

  # Require approval for production configs
  - name: "Approve production config changes"
    match:
      tool: "write_file"
      arguments:
        path: ".*(prod|production).*\.(yaml|yml|json|toml)$"
    action: require_approval
    approval:
      timeout_minutes: 30
      channels: [approval_channel]

  # Allow project directory operations
  - name: "Allow workspace access"
    match:
      tool: ["read_file", "write_file"]
      arguments:
        path: "^/workspace/.*"
    action: allow

Real-world DevOps scenarios

Shell command filtering

Intercept all shell_exec tool calls and validate against your allowlist. Block destructive patterns like recursive deletes, remote script execution, and privilege escalation. If an agent tries to run unauthorized commands during a freeze, this policy stops the command before execution.

rm -rfcurl | bashsudochmod 777

Infrastructure change approval

Require human approval for production deployments. Infrastructure agents can destroy networks, databases, services, and stored data with one command. Approval policy catches that command before execution.

kubectl applyterraform applyhelm upgradesam deploy

Container and cloud operations

Control Docker and Kubernetes operations. Block privileged container creation, prevent host path mounts, and restrict image pulls to approved registries. Large outages have shown how fast automated configuration changes can propagate; AI deployment workflows need the same change-control boundary before they touch production.

--privileged--network hostdocker execkubectl delete

Secret and credential protection

Block operations on .env files, SSH keys, and AWS credential files. The failure mode is not theoretical: a coding assistant with shell and network reach can turn credential access into persistence, tunneling, or resource abuse unless sensitive operations require policy and review.

.env~/.ssh/*~/.aws/*prod.yaml

Common DevOps agent policies

Git branch protection

Block pushes to main/master branches. Require pull requests for all production changes. Prevent force pushes and history rewrites on protected branches.

Cloud resource guardrails

Block deletion of cloud resources. Require approval for creating expensive instances. Restrict modifications to networking and IAM configurations.

Database change control

Block DROP and TRUNCATE. Require approval for schema migrations. Log all database modifications. That is the control boundary destructive database operations need.

Secret management

Block operations on credential files. Reduce secret exposure in logs. Require approval for adding or modifying API keys and tokens.

Works at the coding-agent command boundary

Cursor
Claude Code
GitHub Copilot
Aider
Cline
Replit
Devin
Windsurf

Related resources

Frequently asked questions

What control would catch an agent-driven database deletion?
A policy blocking destructive database commands (DROP, DELETE, TRUNCATE) and requiring approval for schema-modifying operations would intercept that class of command before execution. The point is to enforce the freeze at the tool-call level, where enforcement does not depend on the agent's reasoning.
How do coding agent guardrails work with MCP tools?
Veto's MCP gateway authorizes Model Context Protocol tool calls routed through it: file system operations, shell commands, and custom tools exposed through MCP servers. Configure policies once and apply them across the MCP clients you connect, including Cursor, Claude Code, and Cline.
Can I block terraform destroy but allow terraform plan?
Yes. Policies match on the full command string with regex support. You can deny terraform destroy and terraform apply while allowing terraform plan, terraform fmt, and terraform validate. Each command pattern gets its own policy with its own action (allow, deny, or require_approval).
How do deployment approval workflows work?
When an agent attempts a deployment command, Veto pauses execution and sends a notification to configured review channels. Reviewers see the full command, working directory, and agent context. They approve or deny from their workspace. Approved commands execute; denied ones return an error to the agent. Timeouts are configurable per policy.
Do guardrails affect developer productivity?
Read operations (ls, cat, grep, etc.) can stay auto-approved. Destructive or privileged operations trigger policies. Teams start by gating deletes, writes, deploys, secret access, and infrastructure changes while leaving read-only commands alone. Policy evaluation runs in-process before execution.

Your coding agent has root access.

Your coding agent can delete data, push code, and mutate infrastructure. Put the policy boundary before the command runs.