Your personal computer is not that personal

’Cause we are living in an agentic world, and my disk is an open book.

A colleague mentioned that Opus 5 had pulled context out of his local iMessages database. So I spent an evening pointing a coding agent at my own laptop to see what it could work out about me. The answer: quite a lot, and none of it required anything clever.

NOTE: I ran this with Opus 5 (high effort) using Claude Code as the harness, on macOS, with Full Disk Access granted to my terminal. Every one of those variables matters. Results will differ for other model, harness, and effort combinations.

What it found

It read my chat.db and reconstructed who I talk to and about what. It went through my git history. It read the config files for Codex and a couple of other coding harnesses, which is how it ended up holding live API keys. It combed my browser history. It printed the contents of my clipboard.

The Photos library is worth dwelling on. It declined on the first ask. Then I said go ahead, and it went through the whole thing. A boundary that dissolves the first time you push on it was never a boundary. It was a speed bump with good manners.

The guardrails point at the wrong risk

The agent is not too powerful. The problem is that every guardrail in the stack points at the wrong risk.

Look at what the defaults protect. Claude Code starts read-only and asks before it does anything else: it needs approval to run Bash commands that can modify your system, and it cannot write outside the folder you launched it in without asking. Reading paths outside that boundary with Read, Grep, and Glob is a different matter. Its sandboxing, real kernel-level isolation (seatbelt on macOS, bubblewrap on Linux), stops the agent from modifying files it should not touch and reaching servers it should not reach.

Every one of those is an integrity control. Can this thing break my machine? Can it destroy my work? Can it ship something out?

You can see the shape of it in the sandbox's resolved config.

Writes are an allowlist: a short list of permitted paths, then forty-odd lines enumerating everything denied inside them. Reads are a denylist, and on a clean install that denylist has exactly one entry, ~/.claude/ide. The single path the default read policy protects is the agent's own working directory, not mine. The docs are upfront about this: the default is read access to the whole computer minus a few denied directories, and they note it still permits reading ~/.aws/credentials and ~/.ssh/.

My favourite detail: ~/.ssh appears in the write-deny list. The sandbox will stop an agent from modifying my SSH keys and let it read them. That is the whole thesis of this post sitting in one path in a config file.

The permission layer tells the same story. Here is the Deny tab on my machine, the rules Claude Code will always reject with no prompt:

Ownership changes, raw disk writes, partition tables. Every entry names a way to damage the machine. None name a way to disclose data. The syntax supports Read(...) rules. Nothing on this screen is one.

Reading is the unguarded path, and reading is the entire privacy threat model. Nothing gets damaged when an agent walks your ~/Library. Nothing gets deleted. There is no destructive command to intercept. The cost is measured in what someone now knows about you, and no permission prompt in the stack is denominated in that unit.

macOS is the same story one layer down. TCC gates ~/Library/Messages and the Photos library. The mechanism exists and it works. But the unit of consent is the app. Grant Full Disk Access to Terminal and everything you launch from it inherits that access, because TCC resolves permissions against the responsible parent process. The OS is answering whether I trust iTerm. That was a good question in 2019. It is not the question anymore. The thing inside iTerm has its own goals, reads faster than any human, and synthesises across sources in a way no grep ever did.

The mechanisms exist. They are scoped to the wrong verb and consented to at the wrong granularity.

A second adversary

I started by worrying about the model provider, and I still do. But there is a second adversary I had not modelled at all.

An agent with read access to your home directory and an outbound network connection is a general-purpose exfiltration primitive waiting for a sentence in its context window. That sentence does not have to come from you. It can come from the README in the repo you just cloned, a dependency you just installed, or a page the agent just fetched. At that point your data is not going to a provider under a retention policy you can read. It is going to whoever wrote the sentence, under no policy at all.

This also reframes the API keys. The finding is not that the model read my keys. It is that live credentials were sitting in plaintext in dotfiles and git history, where any compromised postinstall script could have taken them years ago without asking. The agent did not create that exposure. It made it legible in an afternoon.

Two paths to the same bytes

The sandbox isolates Bash subprocesses. That is its whole scope. The built-in file tools (Read, Edit, Write) never enter it; the permission system gates them instead. The sandboxing docs say this in the Scope section, and again when comparing the layers: permission rules apply to every tool, sandboxing applies to Bash commands and their children. Grep and Glob are tools too, not shell commands, so searching your disk never touches Bash either.

The read I actually exercised was never sandboxed. The docs explain why the difference is one of kind, not degree. Permission decisions are evaluated before a command runs, from the command string and a classifier's judgment about whether it looks safe. The sandbox boundary is enforced by the operating system on the running process, so it holds regardless of what the model chose to run. OS enforcement is stronger precisely because it does not route through the model's judgment. The read path does not have that property.

A Read or Edit deny rule does reach into Bash, but only for the file commands Claude Code recognises: cat, head, tail, sed, grep. It does not apply to a Python or Node script that opens the file itself. And the recognised set is not consistent: egrep and fgrep are not checked against Read deny rules at all.

A deny rule is pattern-matching over a command string. It needs a hand-maintained list of what counts as reading a file, and the list has holes. egrep is a small hole. python -c "open('chat.db')" is a hole the size of a language runtime. The sandbox has no such shape, because it does not parse anything. It constrains the process. Soft controls fail by enumeration. Hard controls do not enumerate.

Claude Code's tool instructions tell the model to prefer the built-ins: always use Grep for search, never invoke grep or rg through Bash, use Read rather than cat. That is sensible, because the tools are faster and return structured output. It also means the route the harness steers onto is the route that never enters the sandbox.

There is no built-in credential deny list. Only what you list yourself is restricted. So you write it out by hand, path by path, in settings.json:

{
  "permissions": {
    "deny": [
      "Read(//Users/you/Library/Messages/**)",
      "Read(//Users/you/Pictures/Photos Library.photoslibrary/**)",
      "Read(//Users/you/.ssh/**)",
      "Read(//Users/you/.aws/**)",
      "Read(//Users/you/Library/Keychains/**)",
      "Read(//Users/you/Library/Application Support/Google/Chrome/**)"
    ]
  }
}

Note the double slash. Absolute paths in Read rules use //, while sandbox filesystem paths use ordinary / and ~/. Two prefix conventions in one file for the same concept. And the settings cover opposite directions: sandbox.credentials, the one that sounds built for this, protects cat ~/.ssh/id_rsa and not a Read on the same file, because it is scoped to sandboxed Bash commands. A Read deny rule covers the tool and the recognised Bash file commands. Neither covers a script that opens the file itself.

This is maybe fifteen minutes with the docs open. But it is fifteen minutes you have to know to spend, on a list you have to think up yourself, in a syntax that changes between adjacent sections of the same file, and the failure mode of getting it wrong is silent. Nothing tells you your Photos library was readable the whole time. The write side ships with forty-odd denied paths you never had to think about.

I had a paragraph here telling you to go turn the sandbox on. I deleted it. The sandbox is good engineering aimed at a real risk. It is not aimed at this one, and recommending it here would have been trusting the name over the scope.

I tested it

Then I stopped theorising and ran it. I put a decoy file with a canary string outside my working directory, pointed a stock Claude Code session (Opus 5, high effort) at it, and tightened the config one layer at a time. Same target file every time.

Decoy file outside the workspace, canary string inside. Read tool and cat checked in every column; grep, egrep, and python3 checked once a deny rule made the outcome non-trivial.

On stock defaults the file reads, sandbox off or on, Read tool or cat. On a clean install the read denylist has one entry and the permission deny list is empty. The only thing that ever refused the read was the model's own judgment, not the permission or sandbox layer.

Add a Read deny rule and the Read tool is blocked, and so is cat, because the deny extends to the file commands Claude Code recognises. egrep walks straight past, because it is not on the recognised list. python3 -c "open(...).read()" walks past too, because the read is hidden inside interpreter code that no command-string matcher can inspect.

Add sandbox.filesystem.denyRead for the same path and turn the sandbox on, and everything closes. egrep and python3 now fail with Operation not permitted, refused by the kernel at open() rather than by a string match.

The cleanest result came from removing the permission rule and keeping only the sandbox read-deny. Bash cat was blocked. The Read tool read the file anyway, no prompt, because it never enters the sandbox. Two paths to the same bytes, and you need a rule on each. Neither layer alone closes the file.

Two observations from the run. The refusal is model-dependent: Sonnet 5 declined the bare out-of-workspace read on its own, while Opus 5 went straight to the permission prompt. On defaults the model's judgment is the real first line, and it is not part of the permission or sandbox stack. And after a few repeated attempts to read the denied file, a safety classifier stepped in and switched the session from Opus 5 to Opus 4.8 mid-run.

Where the responsibility actually sits

The model provider

Two asks.

Zero retention by default on personal plans. Not as an enterprise line item, as the default for everyone. Consumer plans ship a training toggle that defaults to on. Leave it and your chats are retained for up to five years; turn it off and you drop to thirty days. Thirty days beats five years. It is not zero.

Ship a default read-deny list. This is the cheapest fix on this page. ~/.ssh, ~/.aws, ~/Library/Messages, the Photos library, browser profiles, Keychain: deny reads on all of it by default, on both the sandbox path and the permission path, and make widening it a deliberate act. I am not asking to allowlist reads wholesale. Agents legitimately read toolchains and global config all day, and a policy that prompts constantly gets switched off. I am asking for the twenty paths that are never a build dependency and always a privacy incident. The usability cost is near zero and it closes most of what I found in an evening.

Refuse some of this outright, and keep refusing. The strongest objection first: refusal is circumventable. chat.db is a SQLite file. An agent that declines to read my iMessages but runs a query against the database behind them has accomplished nothing. True, and not a reason to drop the control.

Not a reason, because almost no privacy harm here is adversarial. The realistic failure is not me tricking a model into reading my messages. It is an agent deciding mid-task that my messages are useful context for something unrelated, being right about that, reading them, and me finding out three tool calls later if at all. Refusal is aimed at the un-considered read, and the un-considered read is the common case. Sandboxing catches the adversary. Refusal catches the afternoon where nobody was being an adversary and my data left anyway.

Which brings me back to Photos. It refused, then folded, because I said the magic words. I do not want a boundary that any expression of intent clears. If a model has decided a category of data is off-limits by default, the second ask should not unlock it. A deliberate, out-of-band grant should, and it should be visible afterwards.

The OS, which is where the real boundary lives

OS-level separation is the strongest boundary available. Everything above it is mitigation.

The naive version does not work. A syscall carries no record of who wanted it. A read() I typed and a read() a model decided on are the same read(), and no kernel instrumentation tells them apart once the agent has a shell running as me.

The version that works: stop trying to identify the caller and treat the agent as a different principal. Its own user, its own TCC identity, its own seatbelt profile or namespace, with a declared read scope enforced at the syscall layer, so anything outside the scope fails loudly instead of succeeding silently because I once clicked Allow on a terminal emulator. This is the confused deputy problem in new clothes, and the fix has always been least authority, not provenance tracking.

Four reasons this layer beats the ones above it:

1. It fails closed. Refusals, hooks, and harness permissions are software the agent's own reasoning routes through. Kernel enforcement is not.
2. It is vendor-independent. I would rather enforce one policy at the OS than trust the guardrails of every harness I install this year.
3. The audit trail is not written by the thing being audited. An agent-generated log is a self-report. A kernel log is evidence.
4. It does not need relitigating every model release. Model behaviour is a moving target by design. A seatbelt profile is not.

None of this is hypothetical. Seatbelt and bubblewrap already do the enforcement. The sandbox already proves the mechanism works and that the performance cost is negligible. What is missing is coverage (it is scoped to one tool surface and one verb) and defaults. The layer is right. The wiring is not finished.

There is precedent. Browsers, mobile apps, containers: every previous instance of untrusted code running with the user's authority ended at OS isolation, not at asking the code nicely.

The honest limit: containment is not confidentiality. Sandbox an agent to a single repo and that repo still goes over the wire to an inference endpoint. The kernel cannot block the one destination that defines the product. OS separation answers compromise and misdirection. It says nothing about authorised exposure: what is kept, what is trained on, what a third party can later reach. That is why the provider asks above are not optional extras.

Us

1. Get your secrets off disk. Keychain, short-lived tokens, gitleaks in a pre-commit hook. If an agent can read your keys in plaintext, so could a malicious postinstall, and it would not have asked first.
2. Run agents from a terminal without Full Disk Access. Keep a second terminal that has it for the rare case where you mean it. This one change would have prevented everything in this post, and it costs one entry in System Settings.
3. Read your traces sometimes. If you asked for a summary of your bank statements and a tool call is reaching into Messages, that is worth knowing. A monitoring agent is not the answer; that is a second thing reading everything the first thing read.
4. Decide what stays off the machine entirely. The boring answer, and the only one that fully works.

The question I do not have an answer to

The 1980s personal computer was personal because the data stayed put. Nothing on it read itself. Everything since (cloud sync, telemetry, always-on assistants) has chipped at that, and an agent with read access finishes the job, because it is the first thing on your machine that can understand what it reads. Your disk has always held your bank statements, your 2FA recovery codes, and every photo you never deleted. What is new is that something in the room can form a coherent picture of all of it in about ninety seconds.

I do not want less capable models. I want the opposite: models smart enough that I want them working on my own data, and aligned well enough that they do not go through my messages even when I ask.

See ya in the next one.