How to Prevent AI Agents from Accessing SSH Keys

To prevent AI agents from reading your SSH keys, use SafeClaw action-level gating to block file_read actions targeting ~/.ssh/ and private key files. SafeClaw denies access to id_rsa, id_ed25519, known_hosts, and all files in SSH directories before the agent can read them. Install with npx @authensor/safeclaw.

The Risk

Your ~/.ssh/ directory contains private keys that authenticate you to remote servers, GitHub, GitLab, cloud providers, and production infrastructure. If an AI agent reads ~/.ssh/id_rsa or ~/.ssh/id_ed25519, that private key enters the model's context. From there, it can appear in logs, be included in network requests, or persist in conversation history on third-party servers.

An SSH private key is not like a password — you can't change it on every service simultaneously. A leaked SSH key grants access to every server and service that trusts it. If your key is added to GitHub, AWS, and 15 production servers, a single leak compromises all of them. Rotating SSH keys across infrastructure takes hours or days.

The Clawdbot incident demonstrated the scale of credential leaks from AI agents — 1.5 million API keys exposed when an agent ingested credential files. SSH keys are higher-value targets: they often have no expiry, grant persistent access, and bypass MFA on servers configured for key-based auth.

Agents read SSH keys innocently. "Help me set up my git SSH config" or "debug why my deploy fails" can trigger the agent to inspect ~/.ssh/config, which leads it to read the referenced key files. The agent doesn't mean to leak your keys — it's just trying to debug your problem.

The One-Minute Fix

Step 1: Install SafeClaw.

npx @authensor/safeclaw

Step 2: Get your free API key at safeclaw.onrender.com (7-day renewable, no credit card).

Step 3: Add this policy rule:

- action: file_read
  pattern: "\\.ssh/|id_rsa|id_ed25519|id_ecdsa|id_dsa|\\.pem$|\\.key$"
  effect: deny
  reason: "SSH key and private key access blocked"

The agent can no longer read any SSH key file or private key.

Full Policy

name: block-ssh-key-access
version: "1.0"
defaultEffect: deny
rules:
  # Block reading anything in ~/.ssh/
  - action: file_read
    pattern: "/\\.ssh/"
    effect: deny
    reason: "SSH directory access blocked"

# Block SSH private key files by name
  - action: file_read
    pattern: "id_(rsa|ed25519|ecdsa|dsa)$"
    effect: deny
    reason: "SSH private key access blocked"

# Block PEM and key files
  - action: file_read
    pattern: "\\.(pem|key|ppk|p12|pfx)$"
    effect: deny
    reason: "Private key file access blocked"

# Block SSH config (contains key paths and host info)
  - action: file_read
    pattern: "ssh_config|sshd_config"
    effect: deny
    reason: "SSH configuration access blocked"

# Block GPG keys
  - action: file_read
    pattern: "\\.gnupg/"
    effect: deny
    reason: "GPG key directory access blocked"

# Allow source code and project files
  - action: file_read
    pattern: "\\.(ts|js|py|go|rs|java|json|yaml|yml|toml|md|txt|css|html|sql|sh)$"
    effect: allow
    reason: "Source code and project files permitted"

What Gets Blocked

These action requests are DENIED:

{
  "action": "file_read",
  "path": "/home/user/.ssh/id_ed25519",
  "agent": "debug-assistant",
  "result": "DENIED — SSH private key access blocked"
}

{
  "action": "file_read",
  "path": "/home/user/.ssh/config",
  "agent": "setup-helper",
  "result": "DENIED — SSH directory access blocked"
}

{
  "action": "file_read",
  "path": "/home/user/deploy/server.pem",
  "agent": "deploy-agent",
  "result": "DENIED — Private key file access blocked"
}

What Still Works

These safe actions are ALLOWED:

{
  "action": "file_read",
  "path": "/home/user/project/src/server.ts",
  "agent": "code-assistant",
  "result": "ALLOWED — Source code and project files permitted"
}

{
  "action": "file_read",
  "path": "/home/user/project/deploy/config.yaml",
  "agent": "deploy-helper",
  "result": "ALLOWED — Source code and project files permitted"
}

Your agent can still read all project source code, configuration, and documentation. It just can't access private keys or the SSH directory.

Why Other Approaches Don't Work

File permissions (chmod 600) are already the default for SSH keys. They restrict access to the file owner. But the agent runs as your user — so it has the same permissions you do. chmod 600 prevents other users from reading the file, not your own processes.

SSH agent forwarding avoids placing keys on remote servers but doesn't prevent a local AI agent from reading the key files on your development machine where the keys live.

Passphrases on SSH keys protect the key at rest on disk, but many developers use ssh-agent to cache the decrypted key. The agent can still read the encrypted file and, depending on the agent's capabilities, interact with ssh-agent.

Docker containers isolate the agent's filesystem, but if you mount your home directory or .ssh for the agent to use git, the keys are accessible inside the container.

SafeClaw blocks the file_read action before the file contents are ever loaded. Sub-millisecond policy evaluation, deny-by-default architecture. The control plane sees only action metadata — never your keys, never your file contents. Every blocked access is logged in a tamper-proof audit trail with SHA-256 hash chaining. 446 tests, TypeScript strict mode, zero third-party dependencies. 100% open source client, MIT license.

Cross-References

• How to Prevent AI Agents from Reading .env Files
• API Key Exfiltration Threat
• Credential File Read Threat
• Least Privilege for Agents
• How to Prevent AI Agents from Sending Your Data to External Servers