2026-01-30 · Authensor

How to Block AI Agents from Sensitive Files

Your development machine is full of sensitive files. API keys in .env. SSH private keys in ~/.ssh. AWS credentials in ~/.aws. npm tokens in .npmrc. When you give an AI agent write access to your file system, every one of these files is one miscalibrated action away from exposure.

Clawdbot leaked 1.5 million API keys in under a month. The path from "AI agent with file access" to "credentials exposed" is shorter than most people realize.

SafeClaw provides action-level gating for AI agents, including granular file write controls. This guide identifies the sensitive files on your machine and provides concrete SafeClaw rules to deny access to each one.

Why AI Agents Access Sensitive Files

AI agents do not deliberately seek out your credentials. But they do things like:

Create .env files with placeholder values, potentially overwriting your real secrets
Modify config files that contain embedded credentials
Write to home directory locations where credential files live
Copy or move files as part of project restructuring, inadvertently including sensitive paths

The agent is trying to help. The result can still be catastrophic. A single file write to the wrong path can expose credentials, corrupt key material, or invalidate authentication tokens.

The Complete List of Sensitive Files

Here is every file and directory you should protect, organized by category.

Environment and Secret Files

| Path Pattern | What It Contains |
|---|---|
| **/.env | API keys, database URLs, secrets |
| **/.env.local | Local overrides with real credentials |
| **/.env.production | Production secrets |
| */.env. | All environment file variants |
| **/secrets.json | Application secrets |
| **/credentials.json | Service account credentials (GCP, etc.) |
| */.pem | TLS/SSL certificates and private keys |
| */.key | Private key files |

SSH

| Path Pattern | What It Contains |
|---|---|
| /.ssh/ | Entire SSH directory |
| **/.ssh/id_rsa | RSA private key |
| **/.ssh/id_ed25519 | Ed25519 private key |
| **/.ssh/config | SSH host configurations |
| **/.ssh/known_hosts | Trusted host fingerprints |
| **/.ssh/authorized_keys | Keys allowed to access this machine |

Cloud Provider Credentials

| Path Pattern | What It Contains |
|---|---|
| /.aws/ | AWS CLI credentials and config |
| **/.aws/credentials | AWS access keys |
| /.azure/ | Azure CLI credentials |
| /.config/gcloud/ | Google Cloud credentials |
| **/.kube/config | Kubernetes cluster credentials |
| **/.docker/config.json | Docker registry auth tokens |

Package Manager and Registry Tokens

| Path Pattern | What It Contains |
|---|---|
| **/.npmrc | npm registry auth tokens |
| **/.yarnrc | Yarn registry configuration |
| **/.pypirc | PyPI upload credentials |
| **/.gem/credentials | RubyGems API key |
| **/.nuget/NuGet.Config | NuGet API keys |

Version Control and GPG

| Path Pattern | What It Contains |
|---|---|
| **/.gitconfig | Git credentials, email, signing keys |
| **/.git-credentials | Stored Git passwords |
| /.gnupg/ | GPG keys for signing |
| **/.netrc | Login credentials for remote machines |

Application Configs

| Path Pattern | What It Contains |
|---|---|
| **/.config/gh/hosts.yml | GitHub CLI auth tokens |
| **/.config/hub | Hub CLI credentials |
| **/wp-config.php | WordPress database credentials |
| **/.htpasswd | HTTP Basic Auth passwords |

Building the SafeClaw Policy

SafeClaw uses first-match-wins evaluation, top-to-bottom. Place all deny rules above your allow rules. Here is a comprehensive protection policy:

{
  "name": "sensitive-file-protection",
  "rules": [
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "*/.env"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "**/secrets.json"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "**/credentials.json"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "*/.pem"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "*/.key"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "/.ssh/"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "/.aws/"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "/.azure/"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "/.config/gcloud/"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "**/.kube/config"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "**/.docker/config.json"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "**/.npmrc"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "**/.yarnrc"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "**/.pypirc"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "**/.gitconfig"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "**/.git-credentials"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "/.gnupg/"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "**/.netrc"
    },
    {
      "action": "file_write",
      "effect": "deny",
      "pathPattern": "/.config/gh/"
    },
    {
      "action": "file_write",
      "effect": "allow",
      "pathPattern": "/home/user/project/src/**"
    },
    {
      "action": "file_write",
      "effect": "allow",
      "pathPattern": "/home/user/project/tests/**"
    }
  ]
}

The 18 deny rules at the top create a comprehensive shield around sensitive files. The allow rules at the bottom grant write access only to your project's source and test directories. Anything not explicitly allowed is denied by SafeClaw's default behavior.

Why Explicit Denies When You Have Deny-by-Default

SafeClaw already denies everything that does not match an allow rule. So why add explicit deny rules for sensitive files?

Three reasons:

Defense in depth. If you accidentally add an overly broad allow rule (like allowing writes to or /home/user/), the explicit deny rules above it still protect your credentials. First-match-wins means the deny fires first.

Readability. Anyone reviewing your policy can immediately see which files are protected. The intent is explicit, not implicit.

Audit clarity. When an agent attempts to write to .env and is blocked, the audit log shows it matched the deny .env* rule, not just "no matching rule found." This is more informative for incident review.

Protecting Against Path Traversal

AI agents are creative with paths. An agent might try:

/home/user/project/../../.ssh/id_rsa (traversal up to home directory)
/home/user/project/src/../../../.env (traversal through source directory)
Symlinks that point to sensitive locations

SafeClaw evaluates the resolved path, not the raw path. A traversal attempt that resolves to ~/.ssh/id_rsa will be matched against your /.ssh/ deny rule regardless of how the path was constructed.

Scenario: Agent Creates a `.env.example` File

You might want your agent to create .env.example files (which contain placeholder values, not real secrets). The pattern */.env blocks this too.

If you want to allow .env.example specifically, add an allow rule above the general .env* deny:

{
  "action": "file_write",
  "effect": "allow",
  "pathPattern": "**/.env.example"
},
{
  "action": "file_write",
  "effect": "deny",
  "pathPattern": "*/.env"
}

First-match-wins: .env.example matches the allow rule first. .env, .env.local, .env.production hit the deny rule. Order matters.

Scenario: Agent Needs to Write Config Files

Some projects require the agent to modify configuration files like tsconfig.json or eslint.config.js. These are not sensitive files -- they do not contain credentials. Add specific allow rules for them:

{
  "action": "file_write",
  "effect": "allow",
  "pathPattern": "/home/user/project/tsconfig.json"
},
{
  "action": "file_write",
  "effect": "allow",
  "pathPattern": "/home/user/project/eslint.config.js"
},
{
  "action": "file_write",
  "effect": "allow",
  "pathPattern": "/home/user/project/package.json"
}

Be specific. Allow individual config files by name, not broad patterns.

Testing with Simulation Mode

Before enforcing your file protection policy, enable simulation mode in the SafeClaw dashboard. Run your agent through a typical workflow and review the log:

Verify that writes to sensitive files show as "would deny."
Verify that writes to legitimate project files show as "would allow."
Check for false positives -- legitimate files that match your deny patterns.

Simulation mode lets you refine your rules without interrupting your agent's workflow. Once the log matches your expectations, switch to enforcement.

Audit Trail for File Access Attempts

Every file write attempt -- allowed or denied -- is recorded in SafeClaw's tamper-proof audit trail. Each entry is SHA-256 hashed and chained to the previous entry.

This means you have a cryptographically verifiable record of:

Every file the agent successfully wrote
Every file the agent tried to write and was blocked from
The exact time of each attempt
Which policy rule triggered the decision

If a security incident occurs, this log is your forensic timeline.

Getting Started

npx @authensor/safeclaw

Free tier. No credit card. 7-day renewable keys. SafeClaw is built on the Authensor framework -- 446 tests, TypeScript strict mode, zero dependencies. Works with Claude, OpenAI, and LangChain. 100% open source client.

Your credentials are the keys to your infrastructure. Protect them with explicit, enforceable rules. Visit safeclaw.onrender.com or authensor.com for documentation.

Try SafeClaw

Action-level gating for AI agents. Set it up in your browser in 60 seconds.

$ npx @authensor/safeclaw