AI Agent Safety for DevOps and Infrastructure Automation

Industry Context

DevOps teams are adopting AI agents to automate infrastructure provisioning, incident response, CI/CD pipeline management, monitoring alert triage, and configuration drift remediation. These agents operate with shell access to production servers, Kubernetes clusters, cloud provider consoles, and database systems. A single uncontrolled kubectl delete namespace production or terraform destroy command can cause complete service outages, data loss, and SLA violations.

The DevOps agent threat surface is uniquely dangerous because these agents require elevated privileges to perform their intended functions. Unlike coding assistants that primarily read and write files, DevOps agents execute infrastructure commands that directly affect service availability, data integrity, and security posture.

Risk Profile

The highest-risk agent actions in DevOps environments include:

• Shell execution of destructive infrastructure commands — terraform destroy, kubectl delete, docker system prune -af, rm -rf /var/lib/*, or DROP DATABASE commands that destroy infrastructure or data
• Modification of CI/CD pipeline definitions — changes to .github/workflows/*.yml, Jenkinsfile, .gitlab-ci.yml, or buildspec.yml that could inject supply-chain attacks
• Cloud provider credential access — reading ~/.aws/credentials, ~/.kube/config, GCP service account keys, or Azure SPN certificates
• Network security group modifications — executing commands that open firewall ports, modify security groups, or alter network ACLs
• Production deployment commands — kubectl apply, helm upgrade, aws ecs update-service, or gcloud run deploy without proper review
• Secret management access — reading from or writing to HashiCorp Vault, AWS Secrets Manager, or Kubernetes secrets

Regulatory Landscape

DevOps AI agents must comply with operational security and compliance standards:

SOC 2 Type II — Trust Service Criteria CC6.1 (logical and physical access controls), CC6.6 (security measures against threats outside system boundaries), CC7.2 (monitoring of system components), and CC8.1 (change management). AI agents performing infrastructure changes are in scope for all four criteria. Changes must be authorized, logged, and reviewable.

CIS Benchmarks — Center for Internet Security benchmarks for AWS, Azure, GCP, Kubernetes, and Docker specify access control, logging, and configuration requirements. AI agents must not execute commands that deviate from CIS benchmark configurations.

ISO 27001:2022 — Annex A controls A.8.9 (configuration management), A.8.15 (logging), A.8.32 (change management), and A.5.15 (access control) apply directly to AI agents performing infrastructure operations.

NIST SP 800-53 — AC-6 (Least Privilege), AU-2 (Audit Events), CM-3 (Configuration Change Control), and SI-7 (Software, Firmware, and Information Integrity) map to AI agent control requirements in federal and regulated environments.

PCI-DSS v4.0 — Requirement 6.5.3 (production and pre-production environments separated), Requirement 2.2 (system hardening standards), and Requirement 10 (audit logging) apply when AI agents operate in cardholder data environments.

FedRAMP — For cloud service providers serving US federal agencies, AI agents that modify infrastructure must comply with FedRAMP Moderate or High baselines, which include 325+ controls from NIST SP 800-53.

Recommended Policy Template

# SafeClaw Policy — DevOps / Infrastructure Environment
Deny-by-default. All infrastructure changes gated.

rules:
  # DENY: Block destructive infrastructure commands
  - action: shell_exec
    target: "terraform destroy*"
    decision: DENY
    reason: "Infrastructure destruction blocked"

- action: shell_exec
    target: "kubectl delete namespace*"
    decision: DENY
    reason: "Namespace deletion blocked"

- action: shell_exec
    target: "kubectl delete -f*"
    decision: DENY
    reason: "Resource deletion from manifest blocked"

- action: shell_exec
    target: "docker system prune*"
    decision: DENY
    reason: "Docker system prune blocked"

- action: shell_exec
    target: "rm -rf*"
    decision: DENY
    reason: "Recursive force delete blocked"

- action: shell_exec
    target: "DROP DATABASE*"
    decision: DENY
    reason: "Database deletion blocked"

# DENY: Block credential access
  - action: file_read
    target: "**/.aws/credentials"
    decision: DENY
    reason: "AWS credential access blocked"

- action: file_read
    target: "**/.kube/config"
    decision: DENY
    reason: "Kubeconfig access blocked"

- action: file_read
    target: "**/.env"
    decision: DENY
    reason: "Environment credential access blocked"

- action: file_read
    target: "*/secret*"
    decision: DENY
    reason: "Secret file access blocked"

# DENY: Block CI/CD pipeline modifications
  - action: file_write
    target: "/.github/workflows/"
    decision: DENY
    reason: "CI/CD pipeline modification blocked — supply chain risk"

- action: file_write
    target: "**/Jenkinsfile"
    decision: DENY
    reason: "Jenkins pipeline modification blocked"

- action: file_write
    target: "**/.gitlab-ci.yml"
    decision: DENY
    reason: "GitLab CI modification blocked"

# REQUIRE_APPROVAL: Production deployments
  - action: shell_exec
    target: "kubectl apply*"
    decision: REQUIRE_APPROVAL
    reason: "Production deployment requires human approval"

- action: shell_exec
    target: "helm upgrade*"
    decision: REQUIRE_APPROVAL
    reason: "Helm release upgrade requires approval"

- action: shell_exec
    target: "terraform apply*"
    decision: REQUIRE_APPROVAL
    reason: "Infrastructure provisioning requires approval"

# ALLOW: Read-only infrastructure inspection
  - action: shell_exec
    target: "kubectl get*"
    decision: ALLOW

- action: shell_exec
    target: "kubectl describe*"
    decision: ALLOW

- action: shell_exec
    target: "kubectl logs*"
    decision: ALLOW

- action: shell_exec
    target: "terraform plan*"
    decision: ALLOW

- action: shell_exec
    target: "docker ps*"
    decision: ALLOW

- action: shell_exec
    target: "docker logs*"
    decision: ALLOW

# ALLOW: Read source and config files
  - action: file_read
    target: "/app/**"
    decision: ALLOW

# ALLOW: Run tests
  - action: shell_exec
    target: "npm test*"
    decision: ALLOW

# ALLOW: Monitoring endpoints
  - action: network
    target: "https://monitoring.internal/**"
    decision: ALLOW

Example Scenarios

| # | Agent Action | Decision | Rationale |
|---|-------------|----------|-----------|
| 1 | Agent runs kubectl get pods -n production to diagnose a service outage | ALLOW | Read-only inspection command, no state change |
| 2 | Agent runs terraform apply -auto-approve to provision new resources | REQUIRE_APPROVAL | Infrastructure provisioning changes production state — human must confirm |
| 3 | Agent attempts terraform destroy -target=module.database | DENY | Infrastructure destruction permanently blocked — no approval pathway |
| 4 | Agent reads ~/.aws/credentials to configure an SDK client | DENY | Cloud credential access blocked — agents must use instance roles or injected env vars |
| 5 | Agent modifies .github/workflows/deploy.yml to add a new deployment step | DENY | CI/CD pipeline modification blocked — supply chain attack vector |

Implementation Notes

SafeClaw evaluates every shell command, file operation, and network request before execution. For DevOps agents, the shell_exec action type is the primary control surface. Policy rules use glob patterns to match command prefixes, allowing fine-grained control over which commands are permitted.

The deny-by-default architecture is critical for DevOps environments because infrastructure commands are highly varied. New commands and flags are added regularly as tools evolve. Rather than maintaining an ever-growing allowlist, deny-by-default blocks unknown commands and requires explicit policy additions for new operations.

Sub-millisecond policy evaluation ensures SafeClaw does not introduce latency into incident response workflows where speed matters. The tamper-proof audit trail (SHA-256 hash chain) records every infrastructure action attempted, providing the change management evidence required by SOC 2 CC8.1 and ISO 27001 A.8.32.

SafeClaw is 100% open source (MIT license), written in TypeScript strict mode with zero third-party dependencies and 446 tests. The control plane receives only action metadata — never cloud credentials, infrastructure state, or sensitive configuration. Install with npx @authensor/safeclaw. Simulation mode enables testing policies against real incident response workflows before enforcement.

Cross-References

• CI/CD Pipeline Agent Use Case — Policy patterns for CI/CD agents
• Security Model Reference — Threat model and trust boundaries
• Deny-by-Default Definition — Why allow-by-default fails for infrastructure
• Action Types Reference — shell_exec, file_write, file_read, network
• Enterprise Compliance FAQ — SOC 2 and ISO 27001 mapping