The toolkit framing is right. Most key pain isn't generating them — it's knowing which of the keys already on the machine a given host actually accepts, and which ones nothing has used in a year. Mapping key → host → last successful auth saves more time than generation ever does.

Retry choreography as a fixture is right — most bugs live in the third attempt, not the first. The case I'd add: succeed, then replay the same call. An agent that loses the 201 retries the same intent, and you want to know if that makes a second order or answers "already done".

The server's view is the one that survives arguments: it's the only record where what the agent meant and what it did are the same thing. The number I'd want from that count: how many calls were retries. Retries are where idempotency assumptions meet your side effects.

No keys copied is the right half. The half that bites later is time: an approved node stays approved between tasks, so the grant outlives the job it was made for. Worth pairing with grants that expire by default, and a fast way to see what an agent can still reach today.

Exactly, and that is the part that survives the click. The approval is a moment; the audit line is what you read back in March. Same three facts in both places: which host, what scope, where the token went. If the record can't reconstruct the decision, the consent screen was theatre.

Treating them as product features is the shift. The one we keep relearning: a narrow default has to be visible at the moment of approval. Whoever clicks approve should see the host, the command scope and where a token would actually go, or the default is just a setting nobody read.

Right, the protocol is the wire format, not the policy. Where the boundary sits stays a product decision: which host, which commands, read-only or not, and who can flip it. Expose "run any shell command" and MCP will faithfully carry your full authority across every system it touches.

That's the failure in one line: nothing checked the action, only the prompt. The gate that pays off most is making destructive verbs (rm, DROP, force-push) a separate grant, off by default, checked right before exec. Does Doberman decide on the command string or the resolved target?

That's the part that bites. The permissions you grant are only the declared surface. The real one is whatever the agent's process can reach: ~/.ssh, env vars, a stray .env, the cloud metadata endpoint. Least privilege has to cover the environment it runs in, not just the tools you hand it.

Exactly right, and that's the half people skip. Custody stops the key leaking, but does nothing about capability. If the tool you expose is "run any shell command," the agent has the key's full authority anyway. So scope the operation: allowlist commands, read-only by default. Two walls, need both.

Exactly — belt and suspenders. A least-privilege SELECT-only role sets the ceiling; the client-side read-only gate catches what the role still permits. Neither alone is enough, but together the worst case is a bad query, not a bad write.

nice. if you do, the free tier has no host limits so you can point it at the pi without thinking about it, and read-only + off-by-default is the bit worth poking at first. ping me if you hit any friction, happy to help