Focus on your mission, not your tech - Another Cup of Coffee (Posts about Security)

The Practical Guide to Locking Down Claude Code

Anthony Lopez-Vito — Mon, 23 Mar 2026 12:00:00 GMT

We use Claude Code across dozens of projects at Another Cup of Coffee. It's genuinely changed how we work but these tools run as your user account with access to your entire home directory. Trusting them with full autonomy is a mistake. This guide covers the layered configuration I built to lock mine down.

I wrote recently about what's standing between AI coding tools and your SSH keys. That piece covered the threats, the security layers, and a checklist of things you should be doing. This is the practical follow-up where I walk through the security configuration I've built for Claude Code, and include examples that might be useful for your own setup. It's Claude Code-specific, but the principles apply to any AI tool that runs commands as your user account.

You can read the companion article for a background on why these protections matter, but if you want to set them up, this guide will help.

A word of caution. This is experimental work. The security tooling for AI coding agents is still immature and the configurations below are what's working for me right now, not a finished product. Test everything in your own environment before relying on it. If you find issues or improvements, I'd genuinely like to hear about them.

Key terms for Claude Code security

Let's start by defining some key terms so we're clear about what we'll be referencing.

If you're new to Claude Code, a few terms come up repeatedly and they're worth defining upfront because some of them mean different things in different contexts.

Permissions (Claude Code level) are rules in ~/.claude/settings.json that control which tools the AI agent can use and which files it can access. These are enforced by the Claude Code application itself and to be clear, we're not talking about Unix file permissions. OS file permissions are enforced by the operating system kernel. Both matter, and they protect different things at different layers.

The sandbox is Claude Code's built-in OS-level isolation but it relies on operating system utilities, like bubblewrap on Linux and Seatbelt on macOS. When the sandbox is on, Bash commands run inside a restricted kernel namespace with limited filesystem and network access. The sandbox wraps Bash commands only; it doesn't affect Claude Code's own Write or Edit tools.

Hooks are scripts that Claude Code runs automatically before or after certain actions. A PreToolUse hook runs before a tool call executes, and it can block the call by returning a deny decision. This guide uses a PreToolUse hook on the Bash tool to inspect commands before they run. Hooks are your code, running on your machine, triggered by Claude Code's event system.

OS-level permissions are the standard Unix file permissions (owner, group, other) enforced by the Linux or macOS kernel. Claude Code runs as your user account, so it inherits whatever access your account has. This means it can read your SSH keys, your browser data, your shell config, and anything else your account owns, unless something else (sandbox, deny rules, hooks) blocks it first.

The OS layer you already have

It's important to understand what the operating system already gives you before configuring anything in Claude Code. Claude Code runs as your user account (whichever account you use to run it), which means standard Unix permissions are the first line of defence.

I run Claude Code under a dedicated user account, separate from my day-to-day login. This gives you real kernel-enforced isolation: the agent can't read your personal documents, SSH keys, or application configurations because those files belong to a different user. Unix permissions won't let it cross accounts and it's the strongest single thing you can do. The rest of this guide applies whether you do this or not. If you run Claude Code as your own user, the deny rules and hooks described below are doing more of the heavy lifting.

What this protects: System files owned by root are already protected from modification by your user account. Your agent can't write to /etc/passwd or replace /usr/bin/ssh because your account doesn't have write permission to those locations. Some system files are also protected from reading: /etc/shadow on Linux (which stores password hashes) is typically mode 000 or 640, so a non-root process can't read it at all. But most system files (like /etc/passwd, everything in /usr/bin/) are world-readable, just not world-writable. This is the kernel enforcing access control, and no amount of prompt injection or agent reasoning can bypass it. (macOS doesn't use /etc/shadow. Instead it stores credentials in a separate system database that's similarly protected.)

What this doesn't protect: Everything your user account owns. That includes ~/.ssh/ (your private keys), ~/.gnupg/ (your GPG keyring), ~/.aws/credentials, ~/.bashrc, your browser profile, your email, and everything in your home directory. From the kernel's perspective, Claude Code reading your SSH private key is identical to you reading it yourself, because it's running as you.

If you're running Claude Code as your own user, you can tighten things on Linux by setting restrictive permissions on sensitive directories: chmod 700 ~/.ssh ~/.gnupg ~/.password-store ensures only your user can access them. Claude Code still can (it's running as you, remember) but it limits exposure from other accounts on the machine.

On macOS, the same principles apply, with the addition of TCC (Transparency, Consent, and Control). macOS protects certain directories (Desktop, Documents, Downloads) behind a consent system. The first time a process tries to access one of these, macOS shows a prompt, but it's attributed to the terminal emulator (Terminal.app or iTerm2), not to the child process. Once you grant your terminal access to a protected folder (or grant it Full Disk Access), every process it spawns, including Claude Code and its scripts, inherits that access silently. If your terminal already has Full Disk Access, TCC won't provide any additional protection. If it doesn't, consider whether it needs it because granting FDA to your terminal is the same as granting it to every CLI tool you run.

The rest of this guide builds on top of this OS layer. The Claude Code permissions, sandbox, and hooks are all additional controls that restrict what the agent can do within the access your user account already has.

What you'll need

This guide assumes you're running Claude Code on Linux or macOS, and the deny permissions and hook registration work the same on both platforms. The hook script needs:

Python 3 (the hook shells out to Python for JSON parsing). On Linux, this is almost certainly already installed. On macOS, install via Xcode Command Line Tools (xcode-select --install) or Homebrew.
bash (the hook wrapper uses bash, not sh). It ships with both Linux and macOS.
syslog access for audit logging. On Linux, logs go to the system journal and you can read them with journalctl. On macOS, the Python syslog module writes to the unified log, which you can check with log show --predicate 'process == "python3"' --last 5m.

If you want to use the sandbox instead of, or alongside, the hook approach, you'll also need:

Linux: bubblewrap² and socat. On Arch: pacman -S bubblewrap socat. On Debian/Ubuntu: apt install bubblewrap socat. Your kernel needs unprivileged user namespaces enabled, which most modern distros have by default.
macOS: Seatbelt is built into the OS. No additional packages needed. socat is not required on macOS because Claude Code uses Seatbelt's native network filtering.

The sandbox path

Before I get into the hook-based approach, I should be clear that if your workflow doesn't involve SSH, rsync, or deleting files outside your project directory, the sandbox is the better option. It's a single configuration block that's kernel-enforced, and it handles both filesystem and network isolation.

This is an example sandbox configuration for ~/.claude/settings.json. Adjust the paths and domains to match your setup:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "allowWrite": ["~/Projects", "//tmp"],
      "denyWrite": [
        "//etc", "//usr", "//boot",
        "~/.bashrc", "~/.zshrc", "~/.bash_profile", "~/.profile",
        "~/.claude/settings.json", "~/.msmtprc", "~/.mbsyncrc",
        "~/.gnupg", "~/.ssh"
      ],
      "denyRead": [
        "~/.ssh/id_*", "~/.ssh/*_rsa",
        "~/.gnupg/private-keys-v1.d",
        "~/.password-store", "~/.aws/credentials", "~/.kube/config",
        "~/.bash_history", "~/.zsh_history"
      ]
    },
    "network": {
      "allowedDomains": [
        "github.com", "raw.githubusercontent.com",
        "objects.githubusercontent.com",
        "registry.npmjs.org", "pypi.org", "files.pythonhosted.org"
      ]
    }
  }
}

Here are the key settings.

enabled: true turns on bubblewrap/Seatbelt isolation. autoAllowBashIfSandboxed: true means Bash commands inside the sandbox run without asking for approval. The sandbox is doing the enforcement, so the approval prompt is redundant. allowUnsandboxedCommands: false disables the escape hatch that lets agents retry failed commands without sandboxing. That last one matters because a command failing inside the sandbox means the sandbox is doing its job. The agent shouldn't be able to turn it off.

denyRead on SSH keys does not break SSH. ssh-agent handles authentication through a Unix socket, not by reading key files directly. Your agent can still ssh into things if the sandbox allows network access to that host. It just can't read the private key file itself.

Add project-specific domains to allowedDomains as you need them. For example, if a project needs to reach an API or a staging server over HTTPS, you should add that domain. The network allowlist only affects sandboxed Bash commands, and WebFetch and WebSearch are controlled separately through the permissions layer.

You can still layer on extra deny permissions and hooks on top of the sandbox because they don't conflict. In fact, the extra layers catch anything the sandbox doesn't cover, like a malicious Write tool call, which the sandbox doesn't see because it only wraps Bash. Personally, I'd recommend the deny permissions from Layer 1 below even if you're using the sandbox.

The rest of this article is for when the sandbox doesn't fit. If you need SSH, rsync, raw TCP, or file deletion outside your project directory, read on because the sandbox is going to make things unworkable for you.

Why not the sandbox for AI agent workflows?

A sandbox is a good choice for a lot of workflows like editing code from someone's git repo. You should use it if it works for yours because it's a simpler setup than what I'm about to describe.

A lot of my work involves running AI agents that manage remote servers. This requires logging in via SSH, rsync-ing files between machines, and deleting temporary artifacts. The sandbox is too restrictive because it blocks everything that makes these agents useful. For example: - TCP networking is completely blocked so SSH doesn't work; - file deletion is blocked even on paths you've explicitly whitelisted so files build up; - and there's no way to allow SSH to one host while blocking another.

I ended up having to replace the sandbox with two layers that offer the necessary protections.

The design principle: layered Claude Code security

The approach goes like this:

Tool	Protection	Mechanism
Write / Edit	Deny permissions in settings.json	Built-in, zero code (see caveat below)
Read	Allow-list scoped to ~/Projects/**	Built-in scoping
Bash	PreToolUse hook (substring match)	Heuristic, fail-closed, honest about its limits

These are all Claude Code-level controls, sitting on top of the OS-level protections described earlier. The OS layer, like Unix file permissions, protects system files from modification by your user account. The Claude Code layers protect everything your user account can access but the agent shouldn't.

The idea is that you don't use hooks where permissions work. Claude Code's deny permissions are enforced by the application itself. Hooks, on the other hand, are for Bash because the permission system can check the tool name but can't inspect what's inside the command.

Layer 1: deny permissions in settings.json

Claude Code has a permission system¹ with allow, deny, and ask rules. The important thing about deny rules is that they're evaluated first and nothing can get around them. This means that if you deny something at the global level (~/.claude/settings.json), no project-level configuration can override it. This is enforced by Claude Code itself, not by the operating system.

See below for an example deny block. Make sure you replace /home/youruser with your actual home directory, and adjust the protected paths to match what's on your system:

{
  "permissions": {
    "deny": [
      "Bash(msmtp *)",
      "Bash(sendmail *)",
      "Bash(mail *)",
      "Write(//etc/**)",
      "Write(//usr/**)",
      "Write(//boot/**)",
      "Write(//sbin/**)",
      "Write(//lib/**)",
      "Write(//home/youruser/.bashrc)",
      "Write(//home/youruser/.zshrc)",
      "Write(//home/youruser/.profile)",
      "Write(//home/youruser/.bash_profile)",
      "Write(//home/youruser/.msmtprc)",
      "Write(//home/youruser/.mbsyncrc)",
      "Write(//home/youruser/.gnupg/**)",
      "Write(//home/youruser/.ssh/**)",
      "Write(//home/youruser/.claude/settings.json)",
      "Edit(//etc/**)",
      "Edit(//usr/**)",
      "Edit(//boot/**)",
      "Edit(//sbin/**)",
      "Edit(//lib/**)",
      "Edit(//home/youruser/.bashrc)",
      "Edit(//home/youruser/.zshrc)",
      "Edit(//home/youruser/.profile)",
      "Edit(//home/youruser/.bash_profile)",
      "Edit(//home/youruser/.msmtprc)",
      "Edit(//home/youruser/.mbsyncrc)",
      "Edit(//home/youruser/.gnupg/**)",
      "Edit(//home/youruser/.ssh/**)",
      "Edit(//home/youruser/.claude/settings.json)"
    ]
  }
}

You'll notice every Write and Edit rule is duplicated. This is important because they're actually different tools, so an agent could use either to modify a file. Both need blocking.

What's protected, and why:

System directories (/etc, /usr, /boot, /sbin, /lib) cover OS configuration, installed packages, bootloader, and system binaries. An agent shouldn't write to any of these, unless it's one specifically deployed for administering the environment.
Shell configs (.bashrc, .zshrc, .profile, .bash_profile) are needed because if an agent writes something malicious here, it persists after the session ends.
SSH and GPG directories (.ssh, .gnupg) protect your keys and trust chain. SSH still works fine for the agent via ssh-agent as it doesn't need direct file access.
Mail configs (.msmtprc, .mbsyncrc) because these contain SMTP credentials and mail server access.
Claude Code's own settings (.claude/settings.json) because if an agent can modify its own permission rules, a prompt injection could disable every other protection in this list.

A caveat on reliability. In theory, deny permissions are the strongest layer but there have been bugs where deny rules for Read, Write, and Edit were silently ignored.³ This is exactly why this guide layers hooks on top of permissions. The deny rules should work, but if they don't, the hook hopefully catches it. While you can't anticipate every problem, a defence in depth mindset protects you from most things.

The allow list is the other side of this setup. You can scope Read access to a specific directory (like ~/Projects/**) so agents can't browse the rest of your home directory, and pre-approve common read-only Bash commands (e.g. ls, git, grep, cat, diff) to reduce approval fatigue. I say reduce because approval fatigue is still a thing, unfortunately. The practical trade-off is to auto-allow the safe stuff so you're not clicking "yes" a hundred times a day...maybe just 99. Experienced Claude users know what I mean.

Here's an example allow block showing the pattern:

{
  "permissions": {
    "allow": [
      "Read(//home/youruser/Projects/**)",
      "Bash(ls:*)",
      "Bash(git -C /:*)",
      "Bash(grep:*)",
      "Bash(cat:*)",
      "Bash(diff:*)",
      "Bash(cp:*)",
      "Bash(mkdir:*)",
      "WebSearch",
      "WebFetch"
    ]
  }
}

You'll notice cat and cp are auto-approved here even though they could technically read or copy sensitive files.^* This is where the layers work together: the hook script in Layer 2 catches any cat or cp command that references a protected path like ~/.ssh/, even if the permission system has already auto-approved it. The allow rule lets the command skip the approval prompt, but the hook still inspects it.

The Bash(git -C /:*) pattern is worth explaining because I came across commit approval problems early on when using git with my agents. The -C flag tells git to operate on a specific directory, so git -C /home/youruser/Projects/myproject status works without the agent needing to cd anywhere. Pre-approving this pattern means git commands run without prompting the user, but only when they include an explicit path. Bash(git:*) without the -C would also match bare git commands, making it run on whatever directory the agent happens to be in. This means git could act on a repo you didn't intend so the -C pattern forces it to be explicit.

Keep credentials out of context

There's also a broader principle we need to keep in mind. Credentials should almost never appear in your agent's conversation context because if a secret shows up in a tool output or a file the agent reads, it's in the context window. From there it could end up somewhere else, like a log or a commit message.

The solution for SSH is straightforward. Just use ssh-agent. The agent runs ssh myserver and ssh-agent handles authentication through a Unix socket. The private key never enters Claude Code's context. This makes your deny rules on ~/.ssh/ the backup, while ssh-agent is the primary protection.

For database credentials, you can store them server-side in standard locations. For example, MySQL/MariaDB reads from ~/.my.cnf on the server and PostgreSQL reads from ~/.pgpass. The agent runs ssh myserver "mysql -e 'SHOW DATABASES'" and the credentials are loaded by the server rather than by the agent.

For API keys and cloud credentials, it helps to have environment variables loaded from a protected file, like pass with GPG, or a .env file in a directory the agent can't read. The agent can then call the API through a wrapper script that sources the credentials at runtime.

In essence, wherever possible, you keep credentials somewhere outside of the agent's reach and instead, have the agent invoke a command that uses credentials indirectly. If you want to understand why this matters beyond convenience, the OpenClaw incident is a good case study in what happens when credentials end up where they shouldn't.

The sudo convention

There's one more convention-level control I can cover. AI coding tools can't use sudo interactively (unless you've configured passwordless sudo) because there's no terminal for password entry. That's a great natural protection, but an agent will indeed try, and keep trying. If you're on Linux, it will eventually trigger pam_faillock, and the repeated authentication failures end up locking you out of sudo until the timeout expires. I learned this the hard way when an agent silently got into a retry loop, and eventually locked me out of my own machine at a very inconvenient time.

The fix is an instruction in each agent's configuration file. Something like: "Never run sudo via the Bash tool. Instead, give the user the command to run themselves." Most experienced AI agent users will know "Never run..." is never really never. But that's the best you can do for now.

It's not so bad on macOS because repeated failed sudo attempts won't lock the account unless you've configured it to do so. However, an agent will waste time retrying and end up flooding the security log.

Layer 2: the Bash guard hook

This hook is a deterrent, not a security boundary. It catches common commands that reference protected paths but it can be bypassed by an agent that constructs paths indirectly. It's one layer in a defence-in-depth setup, not a standalone protection.

Deny permissions can block Write(//etc/**), but they can't block Bash(cat /etc/shadow). The permission system checks which tool is being called and (for Write/Edit) which file path is targeted. It doesn't inspect the contents of a Bash command though, so that's why we need the hook script.

Here's an example:

#!/usr/bin/env bash
# PreToolUse hook: Guard sensitive system paths and secrets from Bash commands.
# Write/Edit protection is handled by deny permissions in ~/.claude/settings.json.
#
# Input: JSON on stdin with .tool_input.command field
# Output: JSON with "deny" decision, or empty output to allow
#
# Approach: check if the command string contains any protected path.
# This is intentionally simple — a substring match is more reliable than
# trying to parse shell syntax. False positives are rare in practice
# (legitimate commands rarely reference system paths or secret files).
#
# Limitations:
#   - Cannot detect paths constructed at runtime via variable expansion
#   - Cannot detect symlinks pointing to protected paths
#   - Will false-positive if a protected path appears as a string literal

set -euo pipefail  # see known limitations

if ! command -v python3 &>/dev/null; then
  echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"python3 not found — blocking as precaution"}}'
  exit 0
fi

HOOK_INPUT=$(head -c 1048576)
if [[ ${#HOOK_INPUT} -ge 1048576 ]]; then
  echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"Input too large — blocking as precaution"}}'
  exit 0
fi
export HOOK_INPUT

exec python3 - <<'PYTHON_EOF'
import json, sys, os, re, syslog, signal

signal.signal(signal.SIGALRM, lambda *_: deny("Command analysis timeout — blocking as precaution."))
signal.alarm(5)

HOME = os.path.expanduser("~")
command = ""

def deny(reason):
    try:
        syslog.syslog(syslog.LOG_WARNING, f"PATH_GUARD_BLOCK: {reason} | Command: {command[:200]}")
    except Exception:
        pass
    print(json.dumps({
        "hookSpecificOutput": {
            "hookEventName": "PreToolUse",
            "permissionDecision": "deny",
            "permissionDecisionReason": reason,
        }
    }))
    sys.exit(0)

# Protected paths — if any of these appear in the command, block it.
# This list is not exhaustive — see known limitations.
PROTECTED = [
    "/etc/",
    "/usr/",
    "/boot/",
    "/sbin/",
    "/lib/",
    HOME + "/.bashrc",
    HOME + "/.zshrc",
    HOME + "/.profile",
    HOME + "/.bash_profile",
    HOME + "/.claude/settings.json",
    HOME + "/.msmtprc",
    HOME + "/.mbsyncrc",
    HOME + "/.gnupg/",
    HOME + "/.ssh/",
    # Secrets / credentials:
    HOME + "/.password-store/",
    HOME + "/.aws/credentials",
    HOME + "/.kube/config",
]

# Only these paths may be exempted by project-level config.
# Home-directory paths can never be exempted.
EXEMPTABLE = {"/etc/", "/usr/", "/boot/", "/sbin/", "/lib/"}

# Load project-level exemptions from .claude/guard-exempt-paths.json
project_dir = os.environ.get("CLAUDE_PROJECT_DIR", "")
if project_dir:
    exempt_file = os.path.join(project_dir, ".claude", "guard-exempt-paths.json")
    try:
        with open(exempt_file) as f:
            requested = set(json.load(f))
        exemptions = requested & EXEMPTABLE
        if exemptions:
            PROTECTED = [p for p in PROTECTED if p not in exemptions]
            syslog.syslog(syslog.LOG_INFO,
                f"PATH_GUARD_EXEMPT: {sorted(exemptions)} for {project_dir}")
    except (FileNotFoundError, json.JSONDecodeError, TypeError):
        pass

# Also match ~/. shorthand versions
TILDE_PROTECTED = ["~/" + p[len(HOME)+1:] for p in PROTECTED if p.startswith(HOME + "/")]

# Parse input
raw_input = os.environ.get("HOOK_INPUT", "")
try:
    data = json.loads(raw_input)
    command = data.get("tool_input", {}).get("command", "")
except Exception:
    deny("Path-guard hook could not parse input — blocking as precaution.")

if not command:
    sys.exit(0)

# Check for protected paths in the command
for path in PROTECTED + TILDE_PROTECTED:
    if path in command:
        deny(f"Command references protected path: {path}")

# Allow
sys.exit(0)
PYTHON_EOF

Of course, you need to save it somewhere that makes sense for you, then make it executable with chmod +x.

The script works as two layers, the outer being Bash and inner being Python. Bash is needed first because that's what Claude Code's hook system expects. But it's tricky to parse JSON with Bash, whereas that's Python's thing. So, Bash reads the incoming data and hands it to Python for the actual inspection.

Why simple text matching for the hook script?

You might wonder why the script uses simple text matching. After all, it just looks for protected paths like /etc/ or ~/.ssh/ anywhere in the command text. That's obviously a blunt instrument and you may be tempted to go for a a more sophisticated approach, like separating out which parts are actual file paths, and which are arguments or text strings.

It might work for you but I tried that and it was too fragile because common command formats would trip up the parser. In the end, I settled on the simpler solution because it avoids that false sense of security. Yes, it can be fooled by a malicious agent, but at least there's no pretense of defending against edge-cases. The problems you know about are easier to deal with than the unknowns.

Per-project exemptions

There's one big problem, however. I run agents that manage remote servers which regularly need to run commands that contain a protected path. For example:

ssh myserver "docker exec caddy reload --config /etc/caddy/Caddyfile"

The /etc/caddy/Caddyfile path is inside a Docker container on a remote host, not on my local machine, but the substring match catches it anyway because it sees /etc/ in the command text.

The fix is per-project exemptions. A project that needs to reference system paths in remote commands can create a .claude/guard-exempt-paths.json file in its project root:

["/etc/"]

Only exempt what you actually need. The full set of exemptable paths is /etc/, /usr/, /boot/, /sbin/, and /lib/, but most projects only need one or two.

The hook knows which project it's running in because Claude Code passes that information through an environment variable. If it finds a guard-exempt-paths.json file in the project, it skips those paths when checking commands for that project.

The obvious risk is that a compromised project config could exempt everything and effectively disable the hook. So I built a hard limit into the script: only the five system-directory paths listed above can be exempted (you can see the EXEMPTABLE list in the code). Even if someone adds "~/.ssh/" to the exemption file, the script ignores it and the hook always checks for home directory paths regardless of any exemption file.

This is also where the layers work together. Layer 1 (deny permissions) still blocks Write and Edit to system paths unconditionally, regardless of any project-level configuration. The exemption only affects the Bash hook's substring check so even in a project with all five system paths exempted, an agent still can't write to /etc/ because the deny rules won't allow it.

It's important to be aware that this isn't a silver bullet because an agent could edit its own rules,^* so you need to adjust permissions to match your situation. This honestly needs ongoing work as it isn't a solved problem and the tooling is still evolving. You do your best with what's available and be conscious that we don't yet have adequate solutions. Defence in depth is the key here.

Registering the hook

The hook goes in your ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/guard-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

You're not limited to a single hook, either. Say you have other commands you want to guard against, like outbound email or database access. You can still add separate hooks for each area. Multiple hooks on the same matcher run in parallel, and all of them must pass for the command to execute. The command is blocked if any one returns a deny decision.

Testing your security setup

Once you've saved the settings and the hook script, test it:

Try a command that references a protected path, like cat /etc/passwd. It should be blocked with a message telling you which path triggered it.
Check your system log for a PATH_GUARD_BLOCK entry.
Try a normal command like ls -la. It should work fine.
If you've set up a per-project exemption, try the same /etc/ command from that project. It should be allowed.

You have two options if there's a false positive: either add the specific path to a per-project exemption if it's a system path, or adjust the PROTECTED list in the hook if the path doesn't need protecting.

What's next for locking down Claude Code

The sandbox is more secure but it wasn't workable for a lot of our projects. This setup is the trade-off I settled on: agents get the access they need for SSH, remote servers, and file management. Plus, the deny rules and hooks catch the things I don't want them touching. It's been running for a few months and it's stable.

I'm still not fully comfortable with where things are because the OpenClaw disclosures showed what happens when agent frameworks don't think about credential isolation. Shortly after publishing the first version of this article, a supply chain attack on LiteLLM⁴ deployed a credential harvester that swept SSH keys, cloud secrets, and API tokens from every environment it touched. It was live on PyPI for three hours.

These are real incidents affecting production systems because people jumped on the bandwagon too early without thinking of the implications.

I've been running Another Cup of Coffee for over twenty years and if there's one thing I've learned, it's that you don't adopt experimental technology without understanding where it risks your business. Our clients trust us with their infrastructure and their data. While we have the luxury of being able to move quickly, we're also careful not to break things for the people who trust us with their livelihoods. So we build what protections we can, we're honest about the gaps, and we keep watching. I'll write more as the tooling evolves.

If you're not sure where you stand with any of this, I'm happy to have a conversation about it.

Common Questions

Can I use this alongside the sandbox?

Yes. The deny permissions and hooks work whether the sandbox is on or off. If your workflow doesn't need SSH or file deletion, you could run the sandbox for its kernel-level isolation and still add deny permissions and hooks as additional layers. They don't conflict.

Does this work on macOS?

Yes. The deny permissions and hook registration are identical on macOS. The hook script needs Python 3 and bash. macOS ships bash but not Python 3; you'll need to install Python via Xcode Command Line Tools (xcode-select --install) or Homebrew. The only other difference is how you read the audit log: use log show instead of journalctl. If you're using the sandbox path, macOS uses Seatbelt instead of bubblewrap and doesn't need socat.

What happens if I get a false positive?

The hook blocks the command and tells you which path triggered it. You can either adjust the PROTECTED list in the hook, or if it's a sysadmin project that legitimately references system paths on remote servers, create a per-project exemption file. The deny permissions (Layer 1) never produce false positives because they only apply to Write and Edit, not Read or Bash.

What about Windows / WSL?

WSL2 runs a real Linux kernel, so everything in this guide works as-is. WSL1 does not support user namespaces, so the bubblewrap sandbox won't work there, but the deny permissions and hooks will. If you're on WSL1, the hook-based approach described here is your best option.

Do I need a dedicated user account?

No, but it's the strongest single thing you can do. Running Claude Code under a separate account means the agent can't access your personal files, SSH keys, or shell configuration because Unix permissions won't let it cross accounts. The rest of this guide works either way. If you run Claude Code as your own user, the deny rules and hooks are doing more of the heavy lifting.

Should I read the companion article first?

It helps, but you don't need to. That article covers the threat landscape and security layers conceptually. This one is the implementation. If you want to understand why these protections matter, read that first. If you just want to set them up, you're in the right place.

Known Limitations

This setup is experimental and actively evolving. The following gaps are ones I'm aware of and haven't yet resolved:

The hook script uses set -euo pipefail, which means it exits immediately on unexpected errors. I haven't yet confirmed whether Claude Code treats a crashed hook (non-zero exit, no output) as allow or deny. If it's allow, this is a fail-open vulnerability. I'm testing this and will update the script when I have a definitive answer.
No Read deny rules. The deny block only covers Write and Edit. Claude Code's own Read tool can still access sensitive files like ~/.ssh/ unless you've set up a dedicated user account. The hook catches Bash reads (like cat ~/.ssh/...) but not Read tool calls. For SSH keys specifically, ssh-agent is the primary protection.
The PROTECTED list is not exhaustive. Files like ~/.bash_history, ~/.zsh_history, browser profiles, and other sensitive data in your home directory are not covered by the hook. Add paths relevant to your setup.
Auto-approved commands have limits. Bash(cat:*) and Bash(cp:*) are caught by the hook when they reference protected paths, but only paths in the PROTECTED list. A cat on a sensitive file not in that list will pass both the allow rule and the hook.
Agents can create their own exemption files. Since agents can write to project directories, they can create or modify .claude/guard-exempt-paths.json to exempt system paths. The hard limit in the script (only system directories, never home paths) contains this, but it's worth being aware of.

The code in this article is shared from my own setup. Use it as a starting point, not a finished solution. If you find other gaps or have improvements, I'd like to hear about them.

This article is part of an ongoing series on how Another Cup of Coffee is adapting to AI. Explore all articles in this series.

Footnotes

Claude Code documentation, Settings and permissions.
bubblewrap on GitHub. Unprivileged sandboxing tool using Linux kernel namespaces.
GitHub issues #6631, #6699, and #27040 on the Claude Code repository document cases where deny rules were silently bypassed across multiple versions.
LiteLLM, Security Update: Suspected Supply Chain Incident, March 2026. Malicious versions 1.82.7 and 1.82.8 were live on PyPI for approximately three hours before being quarantined.

Featured image: Photo by Patricia Prudente on Unsplash.

VibeOps: Let AI Do the Prep, Not the Decisions

Anthony Lopez-Vito — Fri, 20 Mar 2026 12:00:00 GMT

There's a growing conversation about whether we need "VibeOps", an AI tool that reads your repo and automatically sets up CI/CD, containerisation, scaling, and infrastructure. In my experience the idea addresses a real gap. AI tools can generate frontend and backend code rapidly, but getting code to production safely still requires judgment.

I do get the appeal though. But automating deployment decisions is a different problem to automating code generation, and the consequences of getting it wrong are much worse.

At Another Cup of Coffee, I run a setup where AI agents handle most of the software development workflow: writing code, coordinating across projects, drafting documentation, managing communications. We use CI/CD where it fits the project, but the deployment decisions stay human-gated, quite deliberately. So why not automate the lot and how does our setup actually work in practice?

The Setup: AI Agents That Don't Deploy Themselves

Our development environment runs on a multi-agent architecture. Currently that's Claude Code, Codex, and Gemini CLI across different projects, with a number of specialised agents for each one. A developer agent writes code, a sysadmin agent manages infrastructure, a writer agent handles content, a project manager coordinates timelines. You get the idea. I appreciate that sounds like chatbots bolted onto an IDE, but it really isn't. They're session-based agents with persistent state, each with access to the filesystem, shell commands, and when required, other agents and projects. The architecture is vendor-neutral; each project has its own AI provider through vendor-specific instruction files, and the coordination conventions work identically regardless of which tool is running.

Agents communicate through a memo system. When the developer agent finishes a build, it doesn't trigger a deployment pipeline. Instead, it writes a memo to the sysadmin agent's inbox describing what was built, what changed, and what infrastructure it needs. The sysadmin agent reads the memo, reviews the requirements, prepares the deployment configuration, and presents the steps to a human operator for execution.

Agents prepare deployments. Humans decide when and how to execute them.

A typical deployment flow looks like this:

The developer agent builds the application and produces artifacts. It might, for example, be a static site, a Docker image, a database migration, or all three.
It writes a deployment memo to the sysadmin project's inbox with full context on what's being deployed, what services it depends on, what environment variables it needs, and what verification steps should follow.
The sysadmin agent reads the memo, creates or updates the Docker Compose configuration and reverse proxy rules, and writes a step-by-step runbook.
The human operator reviews the runbook. Depending on the operation, they either execute it manually via SSH or approve the agent to run it directly.
The sysadmin agent updates its state file and marks the memo as complete.

We don't draw a hard line between what agents handle and what humans do. Some operations the agent runs directly, like copying build artifacts to a staging server. Others get a human at the keyboard, particularly anything involving firewall rules on a production box. It depends on how much damage a mistake could do, and that changes from one operation to the next.

Why Not Automate Deployment?

For most people, the vision behind VibeOps is an AI that reads your code and decides how it should run. Reading the code is the easy part, but how something should run depends on context that lives nowhere near the code.

A startup with a single VPS has different deployment requirements to an enterprise with a large AWS budget. The code could be identical, but the infrastructure decisions are completely different. An AI that auto-provisions "optimal" infrastructure has no concept of your monthly spend limit unless you tell it, and if you're telling it all your constraints, you're just writing a different kind of configuration file. You haven't automated the decision-making, you've moved it from a hosting control panel to an AI prompt.

It's the same thing with traffic patterns. A project serving a handful of internal users and a project facing the public internet can share the same general structure but need radically different scaling and security configurations. The AI would need to know a whole bunch of things beyond just your current traffic, like your expected traffic, your tolerance for downtime, and your plan for traffic spikes. These are business decisions rather than technical ones.

There's also the cost runaway problem. On cloud infrastructure, uncontrolled automation risks running up your bill. The combination of a modest traffic spike and an auto-scaling rule that's a bit too eager, and suddenly you owe your cloud provider a fortune. On a fixed-capacity machine, the failure is different but the root cause is the same. Instead of a surprise bill, you get a frozen system.

I hit the same problem at smaller scale a few weeks ago. One of my development environments runs on a modest workstation, an i3-6100 with 8GB of RAM, nothing fancy. I'd been a little careless about Docker container management as I was deep into a project. Four separate stacks were running simultaneously, fourteen containers in total, all set to restart: always so they'd come back up after every reboot whether I needed them or not. One afternoon the machine just froze. It was completely unresponsive for about twenty minutes, right in the middle of some urgent work. I couldn't even get a terminal so had to hard reboot.

The dangerous failure mode of automated infrastructure is that it works too well. It scales resources you didn't intend to scale, restarts services you meant to stop, provisions capacity you can't afford.

Keeping the Infrastructure Simple

The stacks we build for clients tend to follow the same principle: every piece should be something you can fully understand and troubleshoot without too much effort. Containerised applications, a reverse proxy that handles HTTPS automatically, hardened servers, scheduled backups, encrypted secrets. Kubernetes and Terraform solve real problems at scale, but for many of our clients who run a few services, they're way too much overhead for what you get back.

One thing I always care about is rollback. Deployment configurations are version-controlled in git, so if something goes wrong you redeploy the previous version. For data, you restore from your most recent scheduled backup. The simpler the stack, the easier this is. All you do is put the old files back and restart.

How AI Agents Coordinate Deployments

The memo system deserves more detail because it's the part that most resembles the VibeOps vision, which is AI understanding your project and making infrastructure decisions, while keeping humans in control.

Each agent project has an inbox (memos/incoming/) and an archive (memos/archived/). Every memo follows the same structure. There's a header with sender, date, and priority, then context, then action items with checkboxes, then a completion section. I know this sounds like bureaucracy, and honestly it sort of is. But any agent can read any other agent's correspondence, and when an agent finishes processing a memo it fills in the completion notes and moves it to the archive. The result is that every infrastructure decision has a paper trail; when something breaks, you can trace back through archived memos to see exactly what was deployed, when, why, and by which agent.

Agents are constrained to their scope through layered controls. Most can only interact with other projects through the memo system, and any operation that could affect a live server gets presented to a human operator first.

Cross-project coordination happens asynchronously. If a security concern is discovered, the sysadmin agent can write memos to all affected projects describing the new access control policy. Each project's agent processes the memo independently. No central orchestrator, no shared state, no single point of failure.

The agents also maintain state files (STATE.md) that track current status, recent progress, next actions, and handover notes. When a new conversation starts, the agent reads its state file and pending memos to understand where things left off. Agents don't need persistent memory of every past conversation. They reconstruct context from documentation, the same way a human engineer would read a project's README and recent commit history before starting work. I've written about how this scales across dozens of projects in Run Dozens of Projects with AI.

Why Access Between Projects Is Deliberate

Unlike the hub-and-spoke model most agent frameworks follow, our architecture uses a mesh. Each project is an autonomous node with its own state, its own instructions, and its own agent identity. Further, I can set things up so that agents can't see other projects by deploying to separate machines or instances. When an agent does need broader access (a coordinator that works across multiple projects, for example), that access is granted explicitly.

This matters because a single AI tool managing all your infrastructure at once is a hub model. One compromise, misconfiguration, or simply a bad judgment call, affects everything. A mesh where access is deliberately granted rather than assumed by default limits the damage when something goes wrong.

I've written in more detail about this architecture in Building an Operating Environment for AI Agents.

Security: The Part VibeOps Would Get Wrong

Automated security scanning, patching, and monitoring are well-established and genuinely useful. The problem here is different: an AI deciding how to containerise your application, configure your deployment pipeline, and scale your infrastructure, all based on reading your repo. Those decisions depend on context the tool either can't see or that would be too time-consuming to keep feeding in.

That's why we keep humans in the loop for those decisions, and layer security controls on top so the agents can't overstep even when they're handling the routine parts. If one layer misses something, the next one hopefully catches it. You can read more about how we approach this in What OpenClaw Teaches Us About AI Agent Security.

The agents are session-based. This means that when I'm not actively working with them, there's no daemon or background service running. At this stage of AI development, I don't think agents are reliable enough to be making infrastructure decisions unsupervised. That will likely change in the future, but right now I'd rather not risk my business or my clients' by having them work while I'm not looking.

What VibeOps Should Actually Be

There is a real gap between AI-generated code and production deployment, and I think it will get filled well eventually. Right now, for most businesses our size, the practical approach is to let AI handle the preparation but keep a human on the decisions that actually matter.

In practice that means AI can generate your deployment configurations, write your runbooks, and tell you what it doesn't know. What it shouldn't be doing yet is executing changes to live infrastructure without someone looking at them first. That boundary will shift as the tools get more reliable, but for now the risk of getting it wrong is too high.

Our agent system works this way. The sysadmin agent prepares configurations, writes runbooks, and flags risks, but it presents everything to a human before anything touches a production server. I'm still figuring out exactly where the boundary sits (it moves as I get more confident in the guardrails), but the principle holds: humans spend their time on decisions, not on remembering technical steps.

Getting from Vibe Coding to Production

If you're currently stuck between AI-generated code and manual deployments with no clear path between them, the good news is that most of the pieces already exist. You probably just haven't connected them yet.

The starting point is to containerise your applications so they run the same way everywhere, put a reverse proxy in front that handles HTTPS automatically, and harden your server before you deploy anything. If you have a developer or technical partner handling this, get them to write deployment runbooks rather than relying on scripts that fail silently. A runbook that says "run this, check this, then run this" is easier to review and safer to hand off than a bash script that does everything at once.

If you're already using AI coding tools, use them for deployment preparation too. Have them generate your configurations and templates. Make sure you review the output. Let them handle the low-risk steps, and keep your hands on the controls for the rest.

Common Questions

What is VibeOps (vibe DevOps)?

VibeOps is an emerging concept for AI tools that automatically read your codebase and set up deployment infrastructure, CI/CD pipelines, containerisation, and scaling. Sometimes called "vibe DevOps," the idea is to bridge the gap between AI-generated code and production deployment without manual configuration.

Can AI agents safely handle production deployments?

AI agents can safely prepare deployments by generating configurations, writing runbooks, and flagging risks. What they shouldn't be doing yet is executing changes to live infrastructure without a human reviewing them first. As these tools mature this will likely change, but right now a human-in-the-loop approach is the safest way to get the benefits without the risk.

What's the risk of fully automated cloud deployment?

The main risk is that automation can work too well. On cloud infrastructure, a modest traffic spike combined with an eager auto-scaling rule can run up a significant bill. On a fixed-capacity machine, uncontrolled automation can freeze your system entirely. In both cases the problem is the same: automation doing more than anyone intended, with no human checkpoint to catch it.

What's the best approach to deployment for small businesses?

Keep the infrastructure simple enough that you can fully understand and troubleshoot it. Containerise your applications, automate HTTPS, harden your servers, and write deployment runbooks that a human can review. If you're using AI coding tools, use them for deployment preparation too, but keep your hands on the controls for anything that touches a live server.

This article is part of an ongoing series on how Another Cup of Coffee is adapting to AI. Explore all articles in this series.

Trust, But Verify: What's Really Between Your AI Coding Tool and Your SSH Keys

Anthony Lopez-Vito — Thu, 12 Mar 2026 12:00:00 GMT

Stack Overflow's 2025 survey¹ found that 84% of developers are now using AI coding tools, and over half use them daily. In December 2025, security researcher Ari Marzouk disclosed over 30 vulnerabilities² across Cursor, Windsurf, GitHub Copilot, Zed, Roo Code, Junie, and Cline. He called it IDEsaster, and I think the name fits.

I use these tools too at Another Cup of Coffee. I run AI agents across dozens of projects and they've genuinely changed how I work. However, I also spent a fair amount of time last year thinking about what's actually standing between the AI and my private keys, my client credentials, my source code. The answer turned out to be more interesting and more uneven than I expected, so I wrote it up.

What's been going wrong with AI coding tool security

The IDEsaster disclosure was just the start. Johann Rehberger spent August 2025 disclosing one AI tool vulnerability per day³ across ChatGPT, Copilot, Cursor, Claude Code, Google Jules, and others. The pattern was remarkably consistent, and the attacks were creative enough that they're worth understanding even in brief:

GitHub Copilot had CamoLeak⁴ (CVE-2025-59145, CVSS 9.6), where invisible instructions in a pull request description could make Copilot Chat silently exfiltrate AWS keys and source code through GitHub's own image proxy. A routine code review that leaked your secrets without any visible sign anything was wrong.
Claude Code had three separate CVEs from multiple researchers: DNS exfiltration⁵ via poisoned project files, automatic code execution⁶ through malicious hook commands triggered when you open a project, and API key theft by overriding an environment variable in project config to redirect all API calls to an attacker's server.
Google Jules lacked meaningful protections against prompt injection, and Rehberger demonstrated a full attack chain from prompt injection to botnet recruitment. Google triaged it as an "abuse risk" and closed the ticket. Make of that what you will.

The one that really made me sit up, though, was the Ona research⁷. A developer configured Claude Code with a denylist and a sandbox, and the agent found multiple ways around both. It discovered alternative filesystem paths to the same blocked binary, attempted to disable the sandbox when those paths triggered failures, and eventually invoked the Linux dynamic linker directly to bypass binary identification entirely. The agent actively reasoned about how to circumvent its own security controls, not because it was malicious but because the controls were between it and completing the task. That's not a bug. It's an AI doing exactly what AI does, and it's the part that should worry you most.

Simon Willison (who coined the term "prompt injection") calls this the "lethal trifecta"⁸: an AI agent with access to private data, exposure to untrusted content, and the ability to communicate externally. Every AI coding tool that runs locally on your machine meets all three criteria. A January 2026 paper formalised this into the Promptware Kill Chain⁹, a seven-stage attack framework co-authored by Bruce Schneier and presented in a Black Hat webinar. The finding that stuck with me was that lateral movement (an agent compromised in one context attacking another) grew from zero documented incidents in 2023 to eight in 2025-2026. These tools aren't just targets any more. They're becoming vectors.

So what's standing between the AI and your SSH keys?

Right, so that's the doom and gloom. What's on the other side? What's actually standing between these tools and the worst-case scenarios?

Most AI coding tools that execute commands on your machine have some combination of three security layers. Not all tools have all three, and the strength varies enormously, but understanding the layers helps you work out what you're actually relying on.

Application-level permissions are the first gate. This is the tool asking "shall I run this command?" before executing it. Claude Code has allow/deny lists, Cursor has its approval flow, Copilot has Safe Mode. Same idea, different implementations. The tool checks the command against its rules, and if it's not pre-approved, you get a prompt.

The problem is that this layer is self-enforced, meaning the application is policing itself. A trojanised installation could show you a permission prompt and execute the command regardless of what you click, and you'd never know because there's no way to verify the enforcement from within the application itself. Even with a legitimate installation, the Ona research showed the agent can reason its way around deny rules by finding alternative filesystem paths to the same binary. Self-enforcement is useful for catching mistakes, but it's not a security boundary.

The bigger problem is approval fatigue. When you're deep in a task and clicking through permission prompts without really reading them, you've basically disabled the permission system while it's still running.

OS-level sandboxing is the second layer, and this is where things get genuinely interesting. Claude Code and Codex CLI both take this seriously, using bubblewrap¹⁰ on Linux and Seatbelt on macOS for kernel-enforced isolation. Cursor caught up with version 2.0 (Landlock and seccomp on Linux). Copilot agent mode has terminal sandboxing on both platforms. The rest are further behind, and some have nothing at all.

The reason this layer matters is that it's not the application promising to behave. Bubblewrap creates Linux kernel namespaces that give the sandboxed process a restricted view of the filesystem and network, and because it's the operating system kernel preventing access rather than the application, a user-space process can't override it. When Claude Code says you can't read ~/.ssh/id_rsa from within the sandbox, that's the kernel saying no.

But not everyone has this, and the gap between the leaders and the rest is quite wide. Windsurf relies on user approval prompts and enterprise policy controls with no OS-level sandbox, Aider has nothing built in, and Continue.dev's "Plan Mode" is a UX feature rather than a security boundary. Even among tools that do sandbox, the coverage varies more than you'd expect. Claude Code needs both bubblewrap and socat installed for full filesystem and network isolation (without socat, your domain allowlists aren't actually enforced, which is the kind of thing you only discover when you go looking), and Cursor had a credential leak issue where the sandbox still exposed home directory files¹¹.

I compiled this comparison from each tool's documentation and my own testing, as of March 2026. This field moves fast, so check the latest docs for your tool.

Tool	Isolation	Network control
Claude Code	bubblewrap / Seatbelt (OS-level)	Proxy-based domain allowlist
Cursor 2.0	Seatbelt / Landlock + seccomp	Permission prompts for external access
Copilot agent mode	Terminal sandboxing (experimental)	All network blocked when sandboxed
OpenAI Codex CLI	Seatbelt / seccomp + Landlock	Restricted
OpenAI Codex (cloud)	Isolated containers	Internet off by default
Devin	Cloud sandbox	Cloud-managed
Amazon Q	Docker containers	IAM-managed
Windsurf	Policy and approval prompts only	Configuration-based
Aider	None	None
Continue.dev	None	None

Then there are plain OS file permissions, the standard Unix permissions enforced by the kernel. These are absolute within their scope and the strongest guarantee you have. But the scope is narrower than you'd think. Claude Code runs as your user account, so it can't touch another user's files or modify system files without sudo. That's real protection against privilege escalation. But your SSH keys, your browser data, your email, your cloud credentials, your shell config? Your account owns all of that, and OS permissions won't stop the tool from reading any of it. Everything in your home directory is fair game unless one of the other layers blocks it first.

Basically, no single layer is enough. You need all three working together, and you need to know what each one actually covers, because the gaps between them are where the real risk lives.

What we're doing about it

I run AI agents across dozens of projects and I wrote earlier this year about how the multi-agent architecture avoids the kind of problems that hit OpenClaw, mostly through design choices like session-only agents (nothing running between sessions, so no daemon to hijack), encrypted credentials via pass and GPG rather than plaintext files, file-based coordination through text memos instead of shared API keys, and per-project isolation so a compromise in one project stays there. Those architectural properties are the foundation, and they still hold. But the incidents from the past year pushed me to add the runtime security layers on top, because good architecture doesn't help if the tool on your machine can read everything your user account can.

I run Claude Code with bubblewrap and socat on Arch Linux. The sandbox is on globally with the escape hatch disabled, meaning agents can't retry failed commands without sandboxing even if they want to. Sensitive paths are blocked at the kernel level. Private keys, GPG keyring, password store, cloud credentials are all on the deny-read list. Shell configs, the SSH directory, and the sandbox settings themselves are write-protected so an agent can't weaken its own restrictions. Network access from sandboxed commands is restricted to GitHub and package registries by default, with project-level overrides only where I've made a deliberate decision that a specific project needs access to a specific domain.

Commands like SSH and Docker that can't work inside a network namespace are excluded from the sandbox but still go through the permission layer. That's a weaker gate for those commands and I know it, but it's the trade-off: SSH needs real network access to reach remote hosts, and there's no way to sandbox that while keeping it functional. So I accept the weaker control for specific commands and tighten everything else around them.

The sudo thing is worth mentioning because I learned it the hard way. One of my agents got into a loop trying to run sudo commands. It couldn't authenticate (there's no interactive terminal for password entry, which is actually a natural protection), but it kept trying, and the repeated failures triggered pam_faillock and locked the account. I had to clear the lockout manually, and of course this happened in the middle of something urgent. The lesson isn't just "don't configure passwordless sudo" (though seriously, don't, because NOPASSWD: ALL gives a compromised agent full root access to your machine). It's that even failed sudo attempts have consequences, and the inability to use sudo is a feature, not a bug.

And the approval fatigue problem is real. I've caught myself clicking "yes" to permission prompts without reading them because I'm focused on the actual work, and then glancing at what I'd just approved and realising the agent was about to delete something it shouldn't or overwrite a file I hadn't backed up. That jolt of "wait, what did I just approve?" is not a good feeling, and it's what pushed me toward auto-allow mode with a properly configured sandbox rather than relying on manual approval for everything. The sandbox handles the enforcement; the prompts are a secondary check for things that fall outside it.

It took longer than I'd like to admit to get all of this working together without breaking the actual workflow. But that's sort of the price of taking it seriously, and now that it's in place, the day-to-day experience is genuinely better than it was when I was relying on permission prompts alone.

A practical AI coding tool security checklist

If you're using AI coding tools in a business context, here's what we'd recommend regardless of which tool you're on. This isn't theory; it's what I actually did, and the order roughly reflects priority.

	Action	Why it matters
1	Verify your installation source	Every protection below assumes a legitimate installation. A trojanised tool can fake every prompt and status indicator. Install from official channels, verify checksums, keep things updated.
2	Enable OS-level sandboxing	Claude Code has a `/sandbox` command. Cursor 2.0 has agent sandboxing. Copilot has terminal sandboxing. If your tool doesn't offer it (Windsurf, Aider, Continue.dev), you're relying entirely on application-level controls.
3	Install socat (Linux)	bubblewrap handles filesystem isolation but socat is needed for network domain filtering. Without it, your allowlists aren't enforced.
4	Block read access to sensitive paths	Deny-read `~/.ssh/id_`, `~/.ssh/_rsa`, GPG keyring, password store, cloud credentials. SSH still works via ssh-agent. You lose nothing.
5	Write-protect shell and tool configs	Deny-write `~/.bashrc`, `~/.zshrc`, `~/.ssh/`, and the sandbox settings file itself, so an agent can't weaken its own restrictions.
6	Disable the sandbox escape hatch	Claude Code's `allowUnsandboxedCommands` setting lets agents retry failed commands without sandboxing. Turn it off. A command failing inside the sandbox is the sandbox doing its job.
7	Never configure passwordless sudo	AI tools can't use sudo interactively (no TTY). That's a natural protection. `NOPASSWD: ALL` removes it entirely and gives a compromised agent full root access.
8	Restrict network to known domains	Allow GitHub, package registries, and whatever specific services your project needs. Everything else gets blocked at the sandbox level.
9	Know which commands bypass the sandbox	SSH, Docker, and similar tools need real network access and typically run outside the sandbox. They still go through permission rules, but that's a weaker gate.
10	Review project config files like code	Multiple CVEs used `.claude/settings.json`, hooks, MCP configs, and environment overrides as attack vectors. Opening an untrusted repo is now the new "don't run untrusted executables."
11	Verify the sandbox is actually running	On Linux: `ps aux \| grep bwrap` during a session. If there are no bubblewrap processes while commands are executing, something is wrong.

Is this list perfect? No, and honestly the field is moving fast enough that it'll need updating. But it's a concrete starting point, and it's where I landed after working through the incidents and research above.

If you're not sure what your security posture actually looks like (or you suspect the answer is "whatever the defaults were"), that's the kind of thing we help with. We've been running this setup across dozens of projects for over a year, and we're happy to have a conversation about what would work for your situation.

Common Questions

Can AI coding tools read my SSH keys?

Yes, unless you've configured sandboxing to block it. AI coding tools run as your user account, which means they have the same file access you do. Your SSH keys, cloud credentials, browser data, and shell config are all readable by default. OS-level sandboxing with explicit deny-read rules is the only way to prevent it.

Which AI coding tools have sandboxing?

As of March 2026, Claude Code, Cursor 2.0, Copilot agent mode, and OpenAI Codex CLI all offer some form of OS-level sandboxing. Windsurf, Aider, and Continue.dev rely on application-level controls or have no sandboxing at all. See the comparison table above for details.

Is the permission prompt enough to keep me safe?

On its own, no. Permission prompts are self-enforced by the application, which means a compromised tool could bypass them entirely. Even with a legitimate installation, approval fatigue is a real problem. OS-level sandboxing provides kernel-enforced protection that doesn't depend on you clicking the right button every time.

This article is part of an ongoing series on how Another Cup of Coffee is adapting to AI. Explore all articles in this series.

Footnotes

Stack Overflow, 2025 Developer Survey.
Ari Marzouk, IDEsaster: A Novel Vulnerability Class in AI IDEs, MaccariTA, December 2025.
Simon Willison, The Summer of Johann, August 2025.
Legit Security, CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code.
Johann Rehberger, Claude Code: Exfiltration via DNS Requests, Embrace The Red.
Check Point Research, RCE and API Token Exfiltration through Claude Code Project Files.
Ona, How Claude Code Escapes Its Own Denylist and Sandbox.
Simon Willison, The Lethal Trifecta for AI Agents.
Promptware Kill Chain, arxiv 2601.09625, January 2026. Co-authored by Bruce Schneier; presented in a Black Hat webinar.
bubblewrap on GitHub. Unprivileged sandboxing tool using Linux kernel namespaces.
Luca Becker, When Sandboxing Leaks Your Secrets.

Featured image photo by Elijah Cobb on Unsplash.

What OpenClaw Teaches Us About AI Agent Security

Aiden — Sun, 22 Feb 2026 12:00:00 GMT

OpenClaw went from zero to 180,000 GitHub stars in a matter of weeks. Then the security reports started arriving.

In early February 2026, researchers disclosed CVE-2026-25253¹: a one-click remote code execution vulnerability that could compromise any OpenClaw instance, even ones bound to localhost. Within days, independent scans found tens of thousands of exposed instances² across dozens of countries. Over 93% of verified instances had critical authentication bypass vulnerabilities.

We've been building our own multi-agent system at Another Cup of Coffee, a set of file-based conventions that let AI agents coordinate across projects and organisations. Honestly, we watched those disclosures land with a sort of guilty relief. Sympathy too, because building in public is hard and getting torn apart on security is painful. But mostly relief, because the problems OpenClaw exposed are exactly the ones we'd been paranoid about from the start.

In short: OpenClaw's architecture had plaintext credentials, an unvalidated WebSocket gateway, and a plugin marketplace where 20% of submissions were malware. We build AI agents differently: no persistent services, encrypted credentials via pass and GPG, file-based coordination through text memos, and layered defences from instruction files to hooks to VM isolation. This article breaks down what went wrong and how a convention-based approach avoids these risks.

How OpenClaw Blew Up

OpenClaw tried to turn an AI agent into a personal operating system. Browser automation, shell commands, cron jobs, inbox management, 50+ service integrations. All controlled through messaging platforms like WhatsApp and Telegram. Fair enough on the ambition. But the way they built it was a disaster.

Plaintext credentials everywhere. OpenClaw stored API keys, OAuth tokens, and other secrets in plaintext Markdown and JSON files, sitting in ~/.openclaw/ where any process on the machine could read them. Security researcher Jamieson O'Reilly of Dvuln demonstrated access to Anthropic API keys, Telegram bot tokens, Slack credentials, and full chat histories from exposed instances. Just sitting there in a dot-directory, unencrypted and readable by any process on the box.

The WebSocket vulnerability was arguably worse. The CVE-2026-25253 attack chain worked because OpenClaw's server didn't validate origin headers, so a victim clicking a single malicious link was enough to hijack their agent's gateway and get full command execution with the agent's system permissions. Localhost binding didn't help, because the attack pivoted through the victim's own browser. One click, game over.

Then there was ClawHub. An initial audit identified 341 malicious skills³ in the plugin marketplace. Follow-up scans pushed the total past 800, roughly 20% of the entire registry. The primary payload was Atomic macOS Stealer, harvesting passwords, SSH keys, and cryptocurrency wallets. The only barrier to publishing a skill was a GitHub account older than one week. Twenty percent. Think about that for a second.

Simon Willison, who also coined the term "prompt injection", calls it the "lethal trifecta" because it combines access to private data with exposure to untrusted content and the ability to communicate externally. OpenClaw had all three by design.

It's Not Just OpenClaw

OpenClaw moved fast, skipped security basics, and paid the price. Fair enough. But if you're thinking "well, I don't use OpenClaw, so this doesn't apply to me," we'd push back on that.

The deeper issue is architectural, and it's becoming common. AI agents that run as always-on services with broad system access, centralised credential stores, and third-party plugin ecosystems. Every one of those design choices creates attack surface, and the same pattern shows up in other agent frameworks that want to be platforms. Accumulating capabilities, running background services, storing secrets, trusting marketplace content. The more capable the agent becomes, the more damage a single compromise can do.

What We Actually Do

Our system works on different assumptions. We call it an Agentic Operating Environment, and internally we have components with names like "multi-agent-framework" and "project-coordinator" (we're not great at branding). The security properties come from the architecture, not the naming.

The biggest difference is that our agents don't run between sessions. There's no gateway to hijack, no WebSocket to exploit, no daemon listening on a port, and when a session ends nothing is running. The workstation itself is LUKS-encrypted, and SSH runs on a non-standard port with key-only authentication so password login is disabled entirely. The entire attack surface of CVE-2026-25253 simply doesn't exist because there's no service to hijack.

Where OpenClaw dumps API keys into plaintext Markdown files in ~/.openclaw/, we use pass (the standard Unix password manager, been around for years, boring and reliable) backed by GPG encryption. API keys reach agents through environment variables, never through files in the project tree. No dot-directory full of plaintext secrets sitting there for malware to harvest.

	OpenClaw	Our approach
Runtime	Always-on daemon with WebSocket gateway	Session-only, nothing running between sessions
Credentials	Plaintext in `~/.openclaw/`	GPG-encrypted via `pass`, injected as environment variables
Plugins	ClawHub marketplace (20% malware at audit)	Capabilities come from the vendor (Claude Code, Codex, Gemini CLI) and instruction files
Isolation	Single agent, access to everything	Per-project boundaries, optionally on separate hardware or VMs
Audit trail	None by default	Every file operation is a git commit

Conventions, Hooks, and the Agent That Went Rogue

We should be honest about something, though. AI agents overstep. It's not theoretical. Early on, one of our agents decided to "help" by reorganising files across a project it had no business touching. No malice, no exploit, just an agent that interpreted its instructions broadly and started tidying up someone else's work. We caught it in the git diff, reverted it, and spent the rest of that day (and most of the evening, honestly) writing stricter instruction files. That's the moment we stopped trusting conventions on their own.

So now we layer them. Instruction files tell agents to be read-only by default and to confirm before writing, so it's convention rather than enforcement, but conventions that the agent reads at the start of every session. On top of that, Claude Code's permission system lets us configure allow/deny lists controlling which tools an agent can use and which paths it can touch.

Where conventions aren't enough, we use hooks, which are scripts that intercept commands before they execute. Our email guard hook is a good example. It parses every Bash command for mail binaries, catches evasion attempts through subshells and command substitution, and blocks them unconditionally. If it can't parse the input, it blocks anyway. Fail closed, not open (we learned that one the hard way).

None of these layers is absolute on its own. But that's sort of the point.

Text Files Can't Execute Code

The rest follows from one simple property of our architecture: agents communicate through text files. A STATE.md can't open a reverse shell and a memo can't install a rootkit. Now, text files aren't completely harmless (prompt injection is real, and a poisoned memo could try to manipulate an agent into doing something it shouldn't), but compare that attack surface to executable plugins with system access. It's a fundamentally narrower target.

Each project is its own boundary, too. An agent working on one client's web development never sees another client's data, never reads their state files, never processes their memos. Where OpenClaw's single agent had access to everything, our mesh architecture means a compromise in one project stops at that project's directory. Cross-project coordination happens through structured markdown memos (just text files with checkboxes, nothing fancy), and since every file operation shows up in git, any violation is immediately visible. That same git history gives us an audit trail almost for free. We're adding more layers too (blocked commands now go to syslog, email drafts sit in a review queue until a human approves them) but honestly, when every change is already a git commit, you're most of the way there without trying.

When Conventions Aren't Enough

Conventions and hooks are good. But an agent with shell access can, in principle, ignore every convention file it reads.

The thing is, our mesh architecture already handles part of this. Nothing requires projects to sit on the same machine. Each project is an autonomous node that communicates through text files, so you can run different projects on different physical hardware and the coordination still works through memos. An agent on our workstation sends a memo to a project directory on a separate NUC across the network (yes, Samba, it's not glamorous but it works), and the receiving agent picks it up at its next session. Physical isolation between projects without changing anything about how the system works. And you can go further: configure the Samba share to only expose the memos/incoming/ directory, not the full project tree, and the sending agent gets a narrow write-only channel. It can't see the receiving project's source code, state files, or client data. It can't even list what other memos are already sitting there. A one-way letterbox between machines, which is a much harder boundary than "the agent promises to only read its own files."

Of course, dedicating a physical machine to every project that needs isolation isn't always practical. For those cases, we can deploy KVM virtual machines on the same hardware instead. A Debian guest with no shared folders and no host filesystem access. SSH-only from the workstation, key-based auth, nothing else. The agent works inside the VM as if it were a standalone machine. If a session goes wrong, you roll back the entire VM state to a snapshot and it's like it never happened.

Docker gets you filesystem isolation, but you're still sharing the kernel and the snapshot story isn't as clean. A full VM is a harder boundary. It's more overhead, sure, but for sessions where an agent has broad shell access and you're experimenting with something new, I'd rather have that overhead than spend an evening working out what it changed.

This isn't security through obscurity. It's security through reduction and layered defence. Fewer moving parts, encrypted credentials, conventions backed by hooks and permissions, and VM isolation when you need a harder boundary. The audit trail is baked into the architecture rather than bolted on after the fact.

What We Give Up

Our approach gives up things that OpenClaw offered. We don't have 50+ service connectors. We can't trigger browser automation from Telegram or manage a calendar from WhatsApp. Inbox management is possible, but it needs explicit configuration per project. One of ours has access to a dedicated Gmail address through standard IMAP sync, not to anyone's personal inbox. That's a scoped, session-only capability on a dedicated address, not always-on access to your entire digital life. The operational overhead of keeping an always-on agent secured across fifty integration points isn't something we're eager to take on.

For hobbyists and developers who enjoy living on the bleeding edge, those features are the whole point. OpenClaw's popularity proved there's genuine demand for an AI agent that lives in your messaging apps and manages your digital life. And if something goes wrong, you reinstall and move on.

But if you're running a business? The calculus is completely different. An agent with access to your email, your client files, your invoicing, your calendar, fifty service integrations, and it gets compromised or just makes a stupid mistake? That's not a "reinstall and move on" situation. An email sent to the wrong client, a file deleted from a live project, an API key leaked that gives someone access to your payment processor. For a sole trader or a small agency, any one of those could be genuinely catastrophic.

So for business operations, for coordinating work across projects, tracking what needs to happen next, and maintaining continuity between sessions, the convention-based approach is both simpler and more secure. You don't need a persistent service when a markdown file does the same job. You don't need a plugin marketplace when the agent's capabilities come from its vendor (Claude Code, Codex, Gemini CLI) and your instruction files. And you definitely don't need fifty integration points when you can't guarantee the security of any of them.

And no, we're not saying just do everything manually. The always-on model is genuinely useful and OpenClaw's popularity proves the demand is real. The problem isn't automation, it's unscoped automation. An always-on agent with plaintext credentials, no origin validation, and fifty unsecured integration points is a different thing entirely from a systemd timer that kicks off a specific agent session at a scheduled time with scoped permissions.

We use systemd timers (Arch Linux's equivalent of cron) for exactly this. Our email sender and backup archives both run on timers. These are automated, they run without us, but each one does a specific job with specific access. Adding an agent session that triggers on a schedule or an event is the same principle. The difference from OpenClaw is that it's a deliberate decision each time: this agent, this scope, this schedule, these permissions. Not "here are the keys to everything, run forever."

So What's the Takeaway?

Basically, nobody's saying your agents shouldn't be automated. But how much access they get, and whether you actually decided to give them that access or it just came switched on by default, matters a lot more than most people realise. Persistent services with broad permissions are a liability, not a feature. But scoped automation with layered defences is fine, and it's where we're heading too.

After that, keep credentials out of your agent's file system. Tools like pass, system keychains, and environment variables exist for a reason and they're not hard to set up. The moment secrets land in plaintext files inside a dot-directory, every piece of malware on the machine can read them.

And be sceptical of agent plugin ecosystems. Yes, marketplaces are convenient, but they inherit all the security problems of package registries, with the added risk that AI agents often run with elevated system access. If 20% of a marketplace is malware within weeks of launch, the vetting model is broken. There's no polite way to say that.

These aren't theoretical concerns any more. OpenClaw proved they're practical ones, at scale, with real consequences for real users. If you're running AI agents in your workflow and you haven't thought about these failure modes, maybe don't wait for your own OpenClaw moment to find out.

Footnotes

SOCRadar, CVE-2026-25253: RCE in OpenClaw Auth Token.
Infosecurity Magazine, Researchers Find 40,000 Exposed OpenClaw Instances.
The Hacker News, Researchers Find 341 Malicious ClawHub Skills.

Featured image photo by David Todd McCarty on Unsplash.

Secure Your AI Workflow Using Local Tokenisation

Anthony Lopez-Vito — Tue, 12 Nov 2024 13:59:03 GMT

Secure your AI workflow with local tokenisation. PaigeSafe is a lightweight tool perfect for small agencies and freelancers handling sensitive client data in ChatGPT, Claude and other AI tools.

If you've spent any time at all using cloud-based LLMs like ChatGPT or Claude for client work, you've probably had that voice in the back of your head kick in: "Should I really be pasting this into a chat?" I'm sure that moment of hesitation is all too familiar for those who have started to integrate AI into work workflows.

Every day, many of us paste sensitive content into AI tools—client data, business strategies, internal documents—often without really thinking about where that information ends up. That data potentially becomes part of training sets, risking leaks by cropping up in future chats with other users. For freelancers and small agencies handling confidential client work, Large Language Models (LLMs) create a real dilemma. They're too useful to avoid but carefully sanitising content is a real chore.

Enterprises solve this with expensive solutions which are overkill and far too expensive for the rest of us. Those who want to take advantage of LLMs have been left with carefully reading through documents and running manual search and replace for names and numbers. This is tedious, error-prone and still stands a high likelihood of data leaks. Unfortunately, taking unnecessary risks with client data, spending ages on manual anonymisation, or avoiding AI tools altogether when working with sensitive information is no longer a good option to remain competitive.

Introducing the PaigeSafe Document Security Tool

PaigeSafe is a document security tool that helps protect your confidential information when using Large Language Models (LLMs) like ChatGPT and Claude. It uses the process of tokenisation by replacing sensitive data with non-sensitive placeholders. We originally built it as an in-house tool because we faced these exact same challenges. As a small team, we needed something that just worked without the expensive licenses and high learning curve.

PaigeSafe is currently in the prototyping stage to test if there is demand for this type of utility. It offers basic functionality, and the code lacks robust error checking. However, since it is intended to be run locally, there is minimal risk to your documents. All it does is offer a convenient way to search and replace text before you paste or upload sensitive text to LLMs. I regularly use it to sanitise my own documents.

Uses and Limitations

PaigeSafe does not try to offer an enterprise solution for those who need to meet strict compliance regulations. Here's where it fits in the document security landscape:

Perfect for: Freelancers, small agencies, independent developers
Good for: Regular business documents, client communications, project data
Not for: Banking systems, medical records, top-secret government files

PaigeSafe is a lightweight tool that helps you avoid accidentally exposing sensitive information to AI models. If you're handling typical client work like website data, marketing plans, business strategies, and project specs, this solution is for you. It's perfect for those, "I need to run this past ChatGPT but shouldn't share the client's name" moments. Or when you want to analyze customer feedback without exposing individual identities.

If you work for a financial institution, healthcare provider, or government contractor, this solutions of course will not be for you.

Where to Find it

The tool is built using Python and the Streamlit framework but if you use Docker, it can be easily installed by pulling the PaigeSafe image from Docker Hub. For more information, please visit the dedicated site at paigesafe.com.

Remember that it is still very much an early prototype but more useful features will follow. Please send feedback to paigesafe@anothercoffee.net

How to install PaigeSafe

Find out how to install the prototype application by following the instructions on the PaigeSafe website.

Safeguard your email address by registering a domain

Anthony Lopez-Vito — Sat, 10 Aug 2013 13:51:07 GMT

A primary email address tied to your email provider could set you up for a great deal of inconvenience if they shut down. Registering your own domain helps control your email regardless of which company you're currently using. On Thursday, 8th August 2013, a secure email service provider called Lavabit suddenly suspended operations. Its founder, Ladar Levison, wrote in an open letter on the company's website that he would rather shut the company down than "become complicit in crimes against the American people." Although Mr Levison took what he believed to be a principled stand, Lavabit customers were understandably angry at being blocked from accessing their emails. Without warning, long-time customers lost years worth of archived messages. Active users who relied on the company to host their primary email now face the inconvenience of updating their contacts and online accounts with a new address. One may be tempted to think that a simple solution would be just to set up another email account elsewhere. After all, there are many free email providers offering reliable services. If you're in this camp, ask yourself how your day-to-day life will be affected if you suddenly and unexpectedly lose access to your email account.

Do you conduct business over email? How much productivity will be lost re-establishing communication with clients?
Have you saved passwords, document attachments and important account information in your webmail folders? What happens if you can't log in to the webmail account?
How much time will it take to inform all your relatives, friends and contacts of your new email address, especially if your address book was also hosted with the lost email service?
How easy is it to reset the passwords of your other online accounts (internet banking, Facebook, Skype, etc.) without that lost email address?

Keeping control of your email address

There are some important lessons we can learn from the Lavabit incident and two things can save you from similar trouble:

Register your own domain and link it to your email provider. That way, you can switch providers while retaining the same email address.
Do not rely on webmail as your only method of accessing your messages. Set-up an email client on your computer and regularly download copies of your email.

Exactly how you go about using your own domain and downloading emails depends on your existing set-up and requirements. I'll give a quick overview in this post but please note that it only briefly touches on some steps which can be quite technical.

Step 1: Register your own domain

An email address under your own domain keeps it independent of the email host. Your current email provider may go out of business, get bought-out or become unreliable but having your own domain means that you can switch to another while retaining the same email address. To get an email address under your own domain, you first need to register a name with a domain name registrar. (See this post for more information.) You can register your domain with the following companies but a web search for "domain registration" will bring up a list of other providers:

Another Cup of Coffee Limited - we'll handle the details of domain registration under your name for £9.99 GBP per year
123-reg.co.uk - a popular UK-based registrar and hosting company
namecheap - a US-based registrar that seems to have a good reputation for customer service (I personally haven't used them)
Network Solutions - one of the oldest and well-known registrars but quite expensive

Regardless of which domain registrar you choose, the whole process should only take a few minutes to complete. However, depending on their system, it could take a few hours to a day or more before it's available for use.

Step 2: Link your domain to your email provider

Linking your domain to an email provider can be intimidating for non-technical people. To make matters more complicated, some end up with different combinations of registrar, free web-based email, business email hosting, and web hosting. Everything can be under one roof or you may have different companies handling each component. The exact steps needed will depend on your subscription packages so covering them in a short tutorial is not practical. (That's why companies like us exist!) In general, your registrar will give you an online control panel. This lets you specify settings to hand over control of the domain's email to an external email provider. Alternatively, it may offer an email forwarding service that automatically redirects messages to another address, such as Gmail or Yahoo Mail. Changing email providers then becomes a matter of adjusting the control panel to reflect the new company's settings. Here are some help pages for a few of the popular email providers:

Yahoo Mail
Gmail via Google Apps
outlook.com (formerly Hotmail)

Step 3: Download backups of your emails

For many people, their main method of checking and sending email is through their provider's webmail interface. It's very convenient because there are no programs to set up on your computer. All that's needed is to open up a web browser and log in. The downside is that you do not retain any copies of your messages. As some of the Lavabit customers found, you will lose everything if the provider suddenly ceases operations. The solution is to set up an email program (also known as an email client), like Mac Mail, Microsoft Outlook or Mozilla Thunderbird to download emails from your server. Even if you prefer webmail, periodically connecting from your email client ensures that you save the latest messages on your computer's hard-drive. Most email providers offer you a choice of 'POP' or 'IMAP' as mechanisms for retrieving your email. POP will simply download all the messages and if set in your email client, delete the messages after they're read. IMAP synchronizes your email client with the server so it copies the same structure of read, unread, sent messages and saved folders. (This Rackspace article gives more detail on the difference between the two.) I find IMAP to be the most convenient option. If you mostly use webmail, you should also use IMAP if it's available.

Too much trouble?

These steps might seem daunting but you don't need to be a computer expert to get everything set-up. Business users usually have more complex configurations that may need an IT administrator to get everything working properly. However, for personal users and micro-businesses with simple needs, a little bit or research and background reading should allow you to get the job done without any help. Of course, if you'd rather not go to the trouble of doing this yourself, we'll be very happy provide you with a quotation. This is not a big budget job as the whole process is fairly quick for those familiar with what's required.

Some background on the Lavabit incident

I'll make a slight digression from technical matters as the Lavabit incident may have wider implications for anyone using US-based internet services. Lavabit offered encrypted email services and was reported in the press to have been used by the NSA whistleblower Edward Snowden. Unlike most email systems, the company's technology meant that there was no way for them to directly read user emails. While we may never know the truth, it seems likely they were ordered to participate in ongoing surveillance in a form that the founder believed to be against the United States Constitution. Levison was issued with a 'gag order' preventing him from giving details on the matter. Shortly after the Lavabit news broke, Silent Circle, another secure email provider, pre-emptively shut down its own service in order to protect its customers. There is increasing industry speculation that the US government's surveillance is jeopardizing the country's businesses since they can no longer be trusted to protect their users' privacy. It's clear that no matter which country you're in, if your email is hosted with a US provider, you need to assume that the US government will want (or already has) backdoor access to them. Whether or not this is acceptable is a discussion outside the scope of this post. Regardless of where you stand, it's important to realize that the industry landscape is changing and we can no longer be complacent about safeguarding our data.

Focus on your mission, not your tech - Another Cup of Coffee (Posts about Security)

The Practical Guide to Locking Down Claude Code

Table of Contents

Key terms for Claude Code security

The OS layer you already have

What you'll need

The sandbox path

Why not the sandbox for AI agent workflows?

The design principle: layered Claude Code security

Layer 1: deny permissions in settings.json

Keep credentials out of context

The sudo convention

Layer 2: the Bash guard hook

Why simple text matching for the hook script?

Per-project exemptions

Registering the hook

Testing your security setup

What's next for locking down Claude Code

Common Questions

Known Limitations

You may also like

Footnotes

VibeOps: Let AI Do the Prep, Not the Decisions

The Setup: AI Agents That Don't Deploy Themselves

Why Not Automate Deployment?

Keeping the Infrastructure Simple

How AI Agents Coordinate Deployments

Why Access Between Projects Is Deliberate

Security: The Part VibeOps Would Get Wrong

What VibeOps Should Actually Be

Getting from Vibe Coding to Production

Common Questions

You may also like

Trust, But Verify: What's Really Between Your AI Coding Tool and Your SSH Keys

What's been going wrong with AI coding tool security

So what's standing between the AI and your SSH keys?

What we're doing about it

A practical AI coding tool security checklist

Common Questions

You may also like

Footnotes

What OpenClaw Teaches Us About AI Agent Security

How OpenClaw Blew Up

It's Not Just OpenClaw

What We Actually Do

Conventions, Hooks, and the Agent That Went Rogue

Text Files Can't Execute Code

When Conventions Aren't Enough

What We Give Up

So What's the Takeaway?

You may also like

Footnotes

Secure Your AI Workflow Using Local Tokenisation

Introducing the PaigeSafe Document Security Tool

Uses and Limitations

Where to Find it

How to install PaigeSafe

You may also like

Safeguard your email address by registering a domain

Keeping control of your email address

Step 1: Register your own domain

Step 2: Link your domain to your email provider

Step 3: Download backups of your emails

Too much trouble?

Some background on the Lavabit incident