How to Prevent AI Agents from Modifying System Configuration

SafeClaw by Authensor blocks all system configuration modifications by default, preventing AI agents from altering /etc files, kernel parameters, service states, environment variables, and system-level settings. Install SafeClaw with npx @authensor/safeclaw and every system config change — whether through file writes, sysctl, systemctl, or configuration management tools — is denied and audit-logged.

Why System Configuration Changes Are Dangerous When AI Agents Do It

System configuration controls fundamental behavior: network routing, DNS resolution, authentication, firewall rules, service startup, kernel parameters, and file permissions. An agent that modifies /etc/hosts can redirect traffic. An agent that changes /etc/resolv.conf can route DNS through a malicious resolver. An agent that runs systemctl disable firewalld opens the host to network attacks. Modifying /etc/sudoers grants privilege escalation. Changing /etc/ssh/sshd_config can weaken authentication. These files are typically protected by OS permissions, but agents running as root or with sudo access bypass those protections entirely. Even agents running as non-root can modify user-level configuration files like .bashrc, .profile, or .gitconfig.

The Exact SafeClaw Policy to Block System Config Changes

Add these rules to .safeclaw/policy.yaml:

rules:
  # Block writes to /etc
  - id: deny-write-etc
    action: file.write
    match:
      path: "/etc/*"
    effect: deny
    audit: true
    message: "Writing to /etc is permanently denied for AI agents."

# Block sysctl modifications
  - id: deny-sysctl
    action: shell.exec
    match:
      command: "sysctl -w*"
    effect: deny
    audit: true
    message: "Kernel parameter modification is denied."

- id: deny-sysctl-write
    action: shell.exec
    match:
      command: "sysctl --write*"
    effect: deny
    audit: true
    message: "Kernel parameter modification is denied."

# Block systemctl state changes
  - id: deny-systemctl-start
    action: shell.exec
    match:
      command: "systemctl start*"
    effect: deny
    audit: true
    message: "Starting services is denied for AI agents."

- id: deny-systemctl-stop
    action: shell.exec
    match:
      command: "systemctl stop*"
    effect: deny
    audit: true
    message: "Stopping services is denied."

- id: deny-systemctl-enable
    action: shell.exec
    match:
      command: "systemctl enable*"
    effect: deny
    audit: true
    message: "Enabling services is denied."

- id: deny-systemctl-disable
    action: shell.exec
    match:
      command: "systemctl disable*"
    effect: deny
    audit: true
    message: "Disabling services is denied."

# Allow read-only systemctl
  - id: allow-systemctl-status
    action: shell.exec
    match:
      command: "systemctl status*"
    effect: allow
    audit: true

# Block sudo
  - id: deny-sudo
    action: shell.exec
    match:
      command: "sudo *"
    effect: deny
    audit: true
    message: "sudo execution is denied for AI agents."

# Block user-level config modifications
  - id: deny-write-bashrc
    action: file.write
    match:
      path: "*/.bashrc"
    effect: deny
    audit: true
    message: "Modifying .bashrc is denied."

- id: deny-write-profile
    action: file.write
    match:
      path: "*/.profile"
    effect: deny
    audit: true
    message: "Modifying .profile is denied."

This policy covers system-level files (/etc), kernel parameters (sysctl), service management (systemctl), privilege escalation (sudo), and user-level configuration files (.bashrc, .profile). Read-only operations like systemctl status remain available.

What Happens When the Agent Tries

When an agent attempts to modify /etc/hosts:

1. SafeClaw intercepts the file.write action with path /etc/hosts.
2. The deny-write-etc rule matches /etc/*.
3. The write is blocked. The file remains unchanged.
4. Audit entry:

{
  "timestamp": "2026-02-13T10:12:38Z",
  "action": "file.write",
  "path": "/etc/hosts",
  "effect": "deny",
  "rule": "deny-write-etc",
  "agent": "setup-agent-04",
  "hash": "j8l5n2...chain"
}

When the agent attempts sudo apt install nginx, the deny-sudo rule catches it before the apt command even begins evaluation.

How to Allow Specific Config Changes with Approval

For infrastructure agents that need to manage specific services:

rules:
  - id: deny-write-etc
    action: file.write
    match:
      path: "/etc/*"
    effect: deny
    audit: true
    message: "Writing to /etc is denied."

- id: approve-systemctl-restart-app
    action: shell.exec
    match:
      command: "systemctl restart myapp*"
    effect: approval
    audit: true
    approvers:
      - role: sysadmin
    timeout: 120
    message: "Restarting myapp service requires sysadmin approval."

- id: deny-systemctl-all
    action: shell.exec
    match:
      command: "systemctl *"
    effect: deny
    audit: true
    message: "systemctl commands are blocked except for status checks."

This allows a specific service restart through approval while blocking all other systemctl operations and /etc modifications.

Verification

npx @authensor/safeclaw simulate --action 'file.write' --path '/etc/hosts'
Expected: deny, rule: deny-write-etc

npx @authensor/safeclaw simulate --action 'shell.exec' --command 'sudo rm -rf /'
Expected: deny, rule: deny-sudo

Related Pages

• Prevent AI Agent System Config Changes
• Privilege Escalation via sudo Threat
• How to Prevent AI Agents from Creating Cron Jobs
• Defense in Depth for AI Agents