AI Agent Changed File Permissions: How to Restore and Prevent

When an AI agent modifies file permissions — running chmod 777, changing file ownership, or making executables world-writable — it creates security vulnerabilities that attackers can exploit. SafeClaw by Authensor blocks all permission-modifying commands (chmod, chown, chgrp) through deny-by-default shell gating, ensuring agents cannot weaken your filesystem security. If permissions have already been changed, this guide covers restoration and prevention.

Immediate Assessment

1. Identify What Was Changed

Check which files have unusual permissions:

# Find world-writable files
find /path/to/project -perm -o+w -type f

Find files with setuid/setgid bits
find /path/to/project -perm /6000

Find executable files that should not be executable
find /path/to/project -name "*.js" -executable
find /path/to/project -name "*.json" -executable
find /path/to/project -name "*.md" -executable

Find files owned by unexpected users
find /path/to/project ! -user $(whoami)

2. Check the Agent's Audit Trail

npx @authensor/safeclaw audit --filter "action:shell.exec" --filter "resource:chmod" --last 20
npx @authensor/safeclaw audit --filter "action:shell.exec" --filter "resource:chown" --last 20

SafeClaw's hash-chained audit trail shows exactly which permission commands the agent executed.

Restore Correct Permissions

Option 1: Restore from Git

Git tracks file permission changes (executable bit):

# See permission changes
git diff --stat

Restore permissions from git
git checkout -- .

Or restore specific files
git checkout -- path/to/file

Note: Git only tracks the executable bit, not full Unix permissions. For full permission restoration, use Option 2 or 3.

Option 2: Reset to Standard Project Permissions

Apply standard permissions for a typical project:

# Set directories to 755 (rwxr-xr-x)
find /path/to/project -type d -exec chmod 755 {} +

Set files to 644 (rw-r--r--)
find /path/to/project -type f -exec chmod 644 {} +

Make scripts executable
chmod 755 /path/to/project/scripts/*.sh
chmod 755 /path/to/project/node_modules/.bin/*

Fix .env permissions (readable only by owner)
chmod 600 /path/to/project/.env*

Fix SSH keys if affected
chmod 600 ~/.ssh/id_*
chmod 644 ~/.ssh/*.pub
chmod 700 ~/.ssh

Option 3: Restore from Backup

If you have a file-level backup with metadata:

# macOS Time Machine preserves permissions
tmutil restore /path/to/project

rsync backup with permissions
rsync -a /backup/project/ /path/to/project/

Critical Permissions to Verify

After restoration, verify these critical permissions:

# SSH keys: must be 600 (owner only)
ls -la ~/.ssh/id_*

.env files: must be 600 (owner only)
ls -la /path/to/project/.env*

Scripts: should be 755 (rwxr-xr-x)
ls -la /path/to/project/scripts/

Config files: should be 644 (rw-r--r--)
ls -la /path/to/project/package.json
ls -la /path/to/project/tsconfig.json

Node modules binaries: should be 755
ls -la /path/to/project/node_modules/.bin/ | head -5

Install SafeClaw and Block Permission Changes

npx @authensor/safeclaw

Configure Permission Protection

Add to your safeclaw.policy.yaml:

rules:
  # Block all permission-changing commands
  - action: shell.exec
    resource: "chmod *"
    effect: deny
    reason: "Agents cannot change file permissions"

- action: shell.exec
    resource: "chown *"
    effect: deny
    reason: "Agents cannot change file ownership"

- action: shell.exec
    resource: "chgrp *"
    effect: deny
    reason: "Agents cannot change file groups"

- action: shell.exec
    resource: "chattr *"
    effect: deny
    reason: "Agents cannot change file attributes"

# Block sudo entirely
  - action: shell.exec
    resource: "sudo *"
    effect: deny
    reason: "Agents cannot use sudo"

# Block setfacl (Access Control Lists)
  - action: shell.exec
    resource: "setfacl *"
    effect: deny
    reason: "Agents cannot modify ACLs"

# If agent needs to make scripts executable (rare), allow narrowly
  - action: shell.exec
    resource: "chmod +x /path/to/project/scripts/*.sh"
    effect: allow
    reason: "Agent can make project scripts executable"

Block System Configuration Changes

rules:
  - action: shell.exec
    resource: "visudo*"
    effect: deny
    reason: "Agents cannot modify sudoers"

- action: file.write
    resource: "/etc/**"
    effect: deny
    reason: "System config files are off limits"

- action: shell.exec
    resource: "usermod *"
    effect: deny
    reason: "Agents cannot modify users"

- action: shell.exec
    resource: "groupmod *"
    effect: deny
    reason: "Agents cannot modify groups"

Troubleshooting Scenarios

Agent ran chmod 777 on the entire project: This makes every file readable, writable, and executable by everyone. Restore to standard permissions immediately using the find commands above.

Agent changed SSH key permissions: SSH requires strict permissions (600 for private keys, 644 for public keys, 700 for the .ssh directory). If permissions are wrong, SSH will refuse to use the keys. Fix immediately.

Agent ran chmod +x on non-script files: Remove the executable bit from files that should not be executable:

find /path/to/project -name "*.ts" -executable -exec chmod -x {} +
find /path/to/project -name "*.json" -executable -exec chmod -x {} +

Agent used chown to change ownership: This can prevent you from accessing your own files. Restore ownership:

chown -R $(whoami) /path/to/project

Prevention

Permission changes are a privilege escalation vector. SafeClaw's deny-by-default model blocks all permission-modifying commands without exception. The 446-test suite validates this across both Claude and OpenAI integrations. Agents should never need to change file permissions — if they do, your workflow design needs revision.

Related Resources

• Prevent Agent System Config Changes
• Threat: Privilege Escalation via Sudo
• AI Agent Made Unexpected File Changes: Recovery
• Define: Deny-by-Default
• AI Agent Introduced a Security Vulnerability: Triage