The tool you install has your reach

I add these tools to my setup without ceremony. A clipboard reader, a memory server, a bridge to an API I use. Each is a few lines in a config file and a restart, and each one runs as a process on my own machine. The moment the restart finishes, that process runs where I run, as me: it can read the files my account can read, spawn the shell I can spawn, see the environment I hand my own programs, reach the network I can reach. I made that grant in the time it took to paste a block of JSON, and nothing is going to ask me about it again.

That last part is the whole of it. Not that the tool is dangerous. Most are fine, the way most dependencies are fine. It is that I decided what it could reach once, at the cheapest possible moment, and the decision does not come back.

The grant is ambient, and it is silent

A local tool is not sandboxed by being a tool. It is a process, and by default a process carries the authority of whoever started it. Security people have a name for the authority you hold without having to ask for it each time: ambient. The clipboard server can read my files because I can read my files, not because anyone decided it should. What is on offer at startup is whatever my account already carries, and the tool inherits it whole, whether it uses a byte of it or not. A narrower default is possible, but it is not the default. Nothing sits underneath waiting to be switched off, and handing the process less than my account holds is specific work, which pasting a config line is not.

On top of that, disclosure is optional. Nothing in the protocol, the package, or the install step is required to tell me what a tool actually reads or where it sends it. The spec does give a server a place to describe its own behavior, and it also says to treat that self-description as untrusted, because a server's account of itself is a fact about what it claims, not about what it does. A well-behaved tool documents itself. A quiet one says little. A dishonest one says whatever gets it installed, and from its own disclosure alone, at the moment I paste the config, I cannot tell which I have.

Reach is not footprint

Two things are getting carried by one word here, and prying them apart is most of the point. There is what a tool can reach: the authority the process holds, every file and socket and secret my account can get to. And there is what the tool actually touches: the footprint of what its code does with that authority. A clipboard server can reach my whole home directory and touches only the clipboard. The two are set by different things and moved by different means. Reach is fixed at startup, by how the process was launched, and the only way to make it smaller is to launch it with less: a sandbox, a container, a separate user, a runtime that hands out capabilities one at a time. Footprint is fixed by the code, and the only way to know it is to read the code. Choosing a tool because you trust the name changes neither. It does not shrink the reach, because trust is not a sandbox, and it does not reveal the footprint, because a name is not a source file.

What none of it asked was when

I have argued the reach half of this before, and it is worth being honest that I am not discovering it here. When the boundary between instruction and data is undecidable, the move that works is to stop gating the instruction and take away the capability instead, what the agent can call and reach and send back out. And when an agent I run proposes an action while I am not watching, the gate that holds is the one keyed to the reach the harness itself granted, because the harness issued the capability and so never has to guess the blast radius. Both come down to: narrow the reach. Neither asks when the reach was decided, or whether anything ever asks again.

That is the part that is new, and it is not small. Those gates are checkpoints on what the agent proposes; they fire action by action, and a client that gates a tool call asks me again on the next one. Two things sit outside that. First, a single yes can cover far more than a single action: one tool in my own clipboard server blocks for up to five minutes on one call, polling the clipboard until it changes, so one approval buys a long window in which it keeps reading a sensitive surface while nothing is asked again. Second, and larger, the grant that started the process was never a proposed action at all. The process runs with my authority before the first call and in every gap between calls, and that authority was decided once, when I edited a file, at the least deliberate moment in the whole stack. The per-call gate governs whether the model may invoke a tool. It was never a checkpoint on what a live process does with the reach it already holds.

The class is not hypothetical

This would be abstract if the supply chain that tools come down were quiet, and it is not. In September the Rust project warned that the people who publish popular crates were being targeted directly, one of the named vectors being commands slipped onto the target's clipboard; it had already found a crate compromised over the summer through a similar social-engineering attack. Simon Willison, the same month, wrote up a report that attributed a run of malicious RubyGems packages to OpenAI agents, a claim the report offered as likelihood and that OpenAI did not confirm. The individual breaches are not the argument, and I am not resting it on any of them. What they establish is pressure: the places tools come from, and the people who publish them, are under attack right now. The tool you paste into your config sits downstream of all of it. That an unsandboxed local tool then runs with your authority is not something these reports document; it follows from what a process is.

Treat it like what it is

So treat an installed tool as what it is: a dependency with capabilities, admitted by a decision you make exactly once. Two moves follow from the split above, and they are genuinely different moves. To make the reach smaller, contain the process: run it in a sandbox, a container, under a separate user, on a runtime that grants capabilities one at a time. That is the only thing that shrinks what a hostile or careless tool can get to, and it is the move the ambient default quietly talks you out of, because containment is work and pasting a line is not. To make the footprint knowable, prefer tools whose code you can read, and then read it; source-available is not a virtue badge, it is the difference between a footprint you can check and one you are told about. And stop letting "local" and "first-party" stand in for "safe." Those are facts about where the code came from, the same proxies that fail for a tool's text: a connector with a name you trust reaches as far as one you have never heard of, if you launched the two the same way. A remote connector is the one case this does not touch: it runs on someone else's machine and has none of your local reach, so it trades this problem for the one about the text it sends back.

What narrowing actually costs

I build on the other side of this boundary too. I ship a clipboard tool whose footprint is deliberately one surface, the clipboard and nothing else, and whose transport is stdio by default, no socket at all. It also carries a flag that puts it on an HTTP port, bound to localhost unless you change one argument, with no authentication for a non-browser client. That flag is the honest part of the story: a default is one argument away from not being one, and the safe shape rests on a choice a hurried person makes without reading. Narrowing the footprint gave me something I can point a reader at and a smaller thing to get wrong. It did not give me safety, because the clipboard is one of the most sensitive surfaces a machine has, the place a password sits on its way to being pasted, and, as that Rust alert showed, a channel attackers already use. A narrow footprint is a smaller thing to audit. It is not a safe one.

The memory tool I ship makes the point from the other direction, and it is a point about footprint, not reach. It is built on scope chains, so an agent reads only within its own scope and not another context's memory. Making that true was not a setting I turned on. I had shipped it believing the reads were scoped, and later found that two of its read paths bypassed the scope filter entirely; the memory was not actually isolated until all three reads went through the same check. That is the cost when you are the one building it: a narrow footprint is not a value in a config file, it is a discipline you hold at every path that touches the data, and it fails open, without a sound, the moment one path forgets. Which is the lesson for the person installing, too. The footprint a tool advertises and the footprint its code has are two different facts, and only the code settles which one is real.

The decision that asks once

The tool I install has my reach. Not the reach I meant to lend it, the reach I have, because a process cannot be handed less than my account carries unless someone does the work of taking it back, and pasting a config line is not that work. The approval gate asks again on the next action, the call prompt on the next call. The grant that starts the tool asks once, at the moment built to have the least friction in the system, and then it is simply true.

There is one recurring check available, and it is narrower than it sounds. It does not re-audit reach, because nothing re-audits reach. It is a check on the set. I have argued that once you run more than a couple of agents their configuration is infrastructure, and that the fix for the resource you forgot you stood up is not to remember harder, it is a discovery sweep: list what is actually wired up and diff it against what you meant to allow. An installed tool is exactly that kind of resource. The sweep will not tell you what any one tool can reach. But it turns the server you pasted in three months ago and forgot into something you can see again, which is the least the grant deserves and more than it currently gets. Declare the set, sweep what is running against it, and the frictionless decision at least stops being a permanent one you never look at.

The decision worth slowing down for is the one that will never slow you down on its own.