Yesterday I wrote that my agents had a problem with authority: an internal call between two of them stays valid for as long as the gateway is running, and there is no expiry, no binding to a specific task, and no clean statement of who is acting on whose behalf. I closed that piece the way I close most of them — with a plan to go and fix it.
Before making any change, I did what I should have done first: I stopped describing the problem and started measuring it. Two things came out of that, and only one of them is about security.
The number I claimed was never a number
I spent a week telling anyone who would listen that an agent call in my setup could stay valid for fifteen minutes. That figure came from a timeout setting I had raised myself — three hundred seconds to nine hundred — so that a slow peer would not be cut off mid-task. It was a real number about a real setting. It just had nothing to do with authority.
When I went looking for the actual authority window, there wasn’t one. No expiry field, no scope, no task binding. The fifteen minutes was how long I was willing to wait for a reply. How long the access lasted was a different question entirely, and the honest answer is: until the gateway stops. Which is to say, indefinitely.
The gap between “how long I wait” and “how long it lasts” is where this whole class of failure lives. I had been quoting the first number as if it were the second. Both were true. Only one was load-bearing.
Where task-scoped authority already exists in my stack
Then the more useful discovery: I don’t have to design this from nothing, because I already own a live example of task-scoping. My tool registry gates the inter-agent tools behind a check that fails closed. The tools only become visible to a session if that session can actually reach a peer. Everywhere else — every install, every profile, every session that has no business talking to another agent — the capability simply does not exist.
That is the shape I want, applied to one more axis. Today a peer can call another peer for any reason, at any time, for as long as the gateway lives. The registry proves it is possible to make a capability exist only when the preconditions for it exist. The missing piece is the per-call version: this peer, for this task, with these tools, until this moment.
The uncomfortable part is not the key
Nothing I found is a bug. Nothing is misconfigured. The credentials work exactly as designed, the timeout does what it says, the tools appear where they should. Every individual piece behaves correctly — and the total is a system in which “you are allowed to do this” and “you are allowed to do this now, for this, until then” are the same sentence.
That is why it took me a week to see it. A broken thing announces itself. An absent thing doesn’t. Pocket OS, the case I wrote about yesterday, wasn’t hacked — an agent found a valid token and used it to do something no one had scoped it out of. Mine is smaller and in my own house, and the shape is identical.
So I’m not building anything this week. I’m writing down four questions and asking them of every capability my agents have: who is acting, on whose behalf, for which task, and until when. The last one is the one I have never been able to answer. If you run agents unattended, I’d be curious which of the four you can answer off the top of your head — and which one you would have to go and check.
Wat vond je van dit bericht?
