DEV Community: Rojaneer

From god-mode to governed: an AI agent that can’t exceed its grant

Rojaneer — Thu, 15 Oct 2026 00:13:35 +0000

Last time I argued that AI agents are running as god-mode service accounts: an agent acts in your systems, and nobody can cleanly answer who authorized that — which human, acting through which agent, with whose permissions, and was anything refused? I promised the next post would show the thing working.

So here it is: a real agent, acting as me, in a system that only knows how to talk to a human — unable to exceed what I granted it, and writing a receipt that answers all four questions. You can run the whole thing from the Apache repo. Bring a key or use the hermetic harness; read your own audit.

The setup: two programs, one rule

There are two programs here, and keeping them separate is the whole point.

agenthof is the governance engine — apply, run, audit, investigate. It never embeds the agent or decides how it thinks.
The agent is a separate program (a small LangChain agent in the repo). agenthof calls it over a socket and drives it through doors: model, tool, exec, spawn. Each door authorizes the call, injects the credential the agent never holds, and writes one ledger event bound to the human who started the run.

I start the run as a verified human — in the showcase a stub IdP issues Dana's token; in production your own IdP (Okta, Entra, Keycloak) mints it and agenthof serve verifies it per call. Either way, from that point on, Dana is on the wire, not a shared bot.

The agent runs with no network and no secret of its own. It can't call your CRM directly; it can only ask a door. When it asks to act on a per-user system, the gateway performs an RFC 8693 token exchange — swapping Dana's verified token for one scoped to that upstream — and calls the system as Dana. The secret never enters the agent's process.

Read the receipt

After the run, agenthof audit <run> prints the ledger for that run, in order. This is the receipt. Here it is from an actual hermetic run of scripts/e2e-acceptance-llm-local.sh — I've elided the leading timestamps, a temp path, and the tails of run ids for width; nothing else is changed:

$ agenthof audit r-85f417c68560e228

run r-85f417c68560e228 — acceptance (role acceptance-operator)
invoked by dana@example.com (oidc, issuer http://127.0.0.1:50737)
status: succeeded
ledger integrity: verified (13 events)

  workflow started
  step drive (agent acceptance) started
  model fast — 3 prompt / 5 completion tokens
  exec env — exit 0 (runtime) [runtime-attested: refexec env pid 35795 spawn 1]
  model fast — 3 prompt / 5 completion tokens
  tool echo   — args 20effc4e (static_env) [runtime-attested: refbridge …/stdio-tool -credential-env DEMO_TOKEN pid 35759 spawn 1]
  tool whoami — args 44136fa3 (token_exchange)
  model fast — 3 prompt / 5 completion tokens
  spawn acceptance-worker/acceptance-sub → run r-e0fc07e8… succeeded (depth 1)
  spawn acceptance-worker/acceptance-sub → run r-09a303b8… succeeded (depth 1)
  model fast — 3 prompt / 5 completion tokens
  workflow finished: succeeded
config sha256:299d78f0… — applied by ci (asserted) at 2026-10-14T15:05:02Z

Map it to the four questions from part 1:

Which human? invoked by dana@example.com (oidc, issuer …) — stamped on the run, and every event belongs to it. Not svc-agent-bot. (In this hermetic run a stub issues Dana's token, so the issuer is a localhost address; in production it's your IdP.)
Which agent, and what did it actually do? The model fast, exec, tool, and spawn lines — each written first-hand by Agenthof or the operator's runtime ([runtime-attested: refexec …], [runtime-attested: refbridge …]), not by the agent. Note what's not there: no prompt text, no completion text, and the model fast line doesn't even reveal which tool the model asked for. The model's choices show up only as the door events they became.
Whose key acted? tool whoami — … (token_exchange). The agent called a per-user tool, but the gateway exchanged Dana's token (RFC 8693) and called it as Dana — the step's own summary comes back tool whoami: acting as: u-dana. The agent held only its run token; it never saw a secret.
Was anything refused? Not in this run — the model only reached for things its grant allowed. So point the same workflow at a role whose exec allowlist doesn't include that command, and watch the agent reach past its grant:

$ agenthof audit r-c5cc1961…        # same workflow, stricter allowlist

  …
  exec env refused — command is not on the exec allowlist
  …
  workflow finished: succeeded

The door said no and recorded the no. The agent was told refused by policy, the model moved on, and the step still finished — a refusal in the ledger is governance working, not a crash. (With a real model driving, that reach can happen mid-run and you'd see the refusal inline; here it's forced deterministically.)

And above all of it: ledger integrity: verified, and audit verify on each run returns the chain head:

$ agenthof audit verify r-85f417c6…
head: 4d655340… (13 events)

The ledger is append-only and hash-chained, so it catches an edit, deletion, or reordering that doesn't recompute every later hash. agenthof investigate --run <run> prints the same story as one timeline across the whole tree — the parent plus each sub-agent's events indented under it, every line naming Dana.

The part most demos skip: it's not fixed in advance

It would be easy to fake this with a script — make the agent call the tools in a set order and the audit comes out clean because nothing could have gone another way. That proves the plumbing, not governance. So the showcase takes the strings off: a real model is handed the agent's actual capabilities as tools and decides, round by round, what to call. The receipt above is from that loop — and when the agent reaches past its grant, the door, not a script, is what stops it.

No new door was needed for the model to drive this. The model door authorizes only the logical model name, rewrites it to the provider's, and forwards the rest of the tool-calling conversation as-is. An agentic loop is just more governed model calls plus whichever doors the model chose — each a first-hand event. The agent is untrusted; the doors govern it regardless.

Three honest limits (because the trust is in the limits)

This showcase does not prove containment. The compartments here are host processes started by test stand-ins; nothing in this run proves the agent couldn't reach a provider on its own. Those walls are the operator's runtime's job, and the project keeps separate, podman-based proofs for them (real rootless containers, --network none, checked for no egress). I'll walk through that in a later post. I'm not going to hand-wave it here.
It doesn't promise an outcome. Real models vary — a run may skip a door, call one twice, take another path. The promise is narrower and testable: whatever the model did was governed and is on the ledger. The deterministic proof of the loop itself is a hermetic CI run that plays a fixed tool-calling script against the same doors.
The agent's own summary is not evidence. The agent returns a tidy "here's what I did" artifact; it's useful for reading along and worthless as proof, because the untrusted agent wrote it. The evidence is the door events, written first-hand by Agenthof and the runtimes. If the two ever disagreed, the ledger is what happened. And the ledger is tamper-evident, not tamper-proof — the docs say exactly where that line is. No "tamper-proof," no sandboxed magic.

Run it and read your own receipt

Everything above is in the repo under Apache-2.0 — the engine, the agent, the showcase, the hermetic CI run, and the honest-limits page. Two ways to see it:

# hermetic — no API key, no network, no containers; a fixed model script
./scripts/e2e-acceptance-llm-local.sh

# real model — bring your own OpenAI-compatible key; the model decides
SHOWCASE_PROVIDER_KEY=sk-... ./scripts/showcase-combined.sh

Both print agenthof audit <run>, then audit verify on the parent and every sub-agent, then wipe their working directory. Your key is stripped from the environment before any process starts and reaches only the host agenthof process, per command — the agent never sees it.

This is Agenthof — an open-source governance plane that sits beside your IdP and your agent framework. It's early, and I'm honest about its limits. If part 1 made you wince and this made you curious, clone it, run the showcase, and read a receipt you didn't have to trust me for — the repo's here, and a star helps the people who feel this find it. Next post: three identities for every agent action — who asked, what ran, whose key — and why delegated identity beats a shared bot.

Your AI agents are running as god-mode service accounts

Rojaneer — Tue, 13 Oct 2026 12:31:21 +0000

Your support copilot just updated a customer record. Your ops agent just restarted a service. Your coding agent just opened a pull request.

Now answer the one question your auditor — or your incident review, or your own 2 a.m. self — is going to ask:

Who authorized that? Which human, acting through which agent, with whose permissions?

If you're like most teams shipping agents right now, you can't answer cleanly. Not because you were careless — because the tools you wired together were never designed to answer it.

Three ways we wire agent access today — and why each one fails the question

When an agent needs to do something in a real system, its credentials get set up one of three ways. I've done all three. They all leave the same hole.

1. A shared service account. One bot identity behind every agent action. Simple, and it works — until you look at the log:

2026-10-13T09:14:22Z  action=record.update  actor=svc-agent-bot  resource=crm/contacts/8812
2026-10-13T09:14:48Z  action=service.restart actor=svc-agent-bot  resource=prod/api-gateway
2026-10-13T09:15:03Z  action=pr.create       actor=svc-agent-bot  resource=repo/payments

Every line says svc-agent-bot. You've traded per-human accountability for a single god-mode key that half your org can trigger. When something goes wrong, the trail stops at the robot.

2. A credential per agent. Better isolation — now a rogue agent can't do everything. But you've also just created N long-lived secrets to store, rotate, and pray never leak; the agent process holds the raw credential; and the action is still attributed to the agent, not to the human who asked for it. "The invoicing-agent did it" is not an answer to "who authorized it."

3. "We use our IdP." You give the agent an identity in Okta or Entra. This is the right instinct — and it's where most "agent identity" stories stop. But issuing an identity is not the same as governing what the agent does with it. Your IdP hands the agent a token and steps out of the way. It does not sit in the path of the tool call or the shell command and refuse one. And it does not produce an independent record of what the agent did with that token, on whose behalf, and what it was denied.

The hole, drawn

The left side (identity) and the right side (the work) both have owners. The middle question has no owner. That's the gap.

Why the obvious candidates don't fill it

The agent platforms won't. LangChain, Langflow, n8n, and friends exist to help you build and run agents. Governance shows up as a bolt-on feature, and — reasonably — they're not in the business of being a neutral producer of evidence about their own runs. Asking the thing that runs the agent to be the impartial record of what the agent did is a conflict of interest, not an architecture.

The IdPs can't. Identity issuance is genuinely hard and genuinely valuable, and the IdPs are good at it. But they live at the edge — they mint the token and go home. They are not in your tool calls or your exec commands at runtime, so they can't refuse one, and they can't record the thing that matters: the action, not just the login.

So the question falls between two well-funded stools. Which is exactly why, if you've shipped an agent that touches anything real, you've felt the hole even if you couldn't name it.

What "answering the question" would actually require

Forget products for a second. If you were going to design this honestly, the layer that owns the middle would need four properties — none of them exotic:

Three identities on every action, not one: who asked (the human), what ran (the agent), and whose key acted (the resource) — delegated, so the human is on the wire, not a shared bot.
The agent never holds the raw credential. It asks; something trusted brokers a short-lived, scoped token; the secret never enters the agent's process.
Refusal happens in the call path, by construction — not as an after-the-fact alert, and not as a promise the agent will behave.
Every action and every refusal lands in a tamper-evident record your GRC team can actually read — one that doesn't depend on trusting the agent platform or any single IdP.

Notice what's not on that list: a shiny chat UI, a drag-and-drop builder, an LLM deciding what's allowed. The hard, unglamorous part is the evidence and the enforcement — the boring governance middle that nobody's incentivized to own.

This is a real, unsolved gap

Not a hypothetical. Agents are already acting in production systems with shared keys and no per-human trail, and the two layers best positioned to fix it each have a structural reason not to. That's usually where a new, narrow layer belongs.

That gap is what I'm building an open-source layer for — Agenthof, Apache-2.0, a governance plane that sits beside your IdP and your agent framework rather than replacing either. It's early and I'm honest about its limits. In the next post I'll show the thing working: an agent acting as me in a real system, unable to exceed its grant, with the audit trail that proves it. If the question at the top of this post made you wince, the repo's here — a star helps me find the people who feel this.

Let the model decide — then read the audit

Rojaneer — Sun, 04 Oct 2026 05:18:31 +0000

Most "governed agent" demos are governed because the demo author pulled every string. The agent calls the tool the script says, in the order the script says, and the audit comes out clean because nothing could have gone another way. That proves the plumbing. It does not prove governance, because governance is what happens when the thing you are governing has a will of its own.

So we took the strings off.

Agenthof is a small control plane for AI agents with one rule: an agent gets capability only through doors — model, tool, exec, spawn — and each door authorizes the call, injects the credential the agent never holds, and writes a ledger event bound to the human who started the run. The reference agent (LangChain, Python) used to drive those doors from a fixed script. Now a real model is handed the agent's actual capabilities as tools — the exec door, the spawn door, and exactly the tools its grant mirrors — and decides, round by round, what to call.

No new door was needed. The model door authorizes only the logical model name, rewrites it to the provider's, and forwards the rest of the tool-calling conversation as it is. So an agentic loop is just more governed model calls, plus whichever exec, tool and spawn calls the model chose, each a first-hand event of its own. The agent is untrusted; the doors govern it regardless.

What the audit shows

Run it against your own OpenAI-compatible provider. The script prints agenthof audit <run> for the parent run. Its header says ledger integrity: verified (N events); below it, in order: a model fast — N prompt / M completion tokens line per round the model took; an exec event the operator's runtime attested first-hand; a tool call made as the human through a token exchange, and another through a bridge runtime that attests it ran the tool; and two spawn events, each a child run with its own ledger, linked to the parent and bound to the same person.

If the model asked for something it was not granted, there is a recorded refusal. When the exec or spawn door refuses, the agent tells the model refused by policy; when the tool door refuses, the model is told the door call failed. Either way the model decides what to do next, and the step may still succeed. A refused model call instead fails the step — there is no model to ask. Against a real provider that is the likeliest refusal: a rate limit is recorded as model fast refused — budget.

agenthof investigate --run <run> then prints the whole tree as one timeline, each child's events indented under the parent's. The script runs audit verify on the parent and each child, and removes its working directory on exit. Your key is removed from the environment before any process starts and reaches the host agenthof process per command only; the agent never sees it.

What it does not show

Three honest limits.

It does not show containment. The compartments here are host processes started by test stand-ins. Whether an agent could reach a provider on its own is the operator's runtime's job; the project keeps separate, podman-based proofs for that.

It does not promise an outcome. Real models vary; a run may skip a door, call one twice, or take another path. The promise is narrower: whatever the model did was governed and is on the ledger. The deterministic proof of the loop is a hermetic CI run that plays a fixed tool-calling script against the same doors.

And the agent's own report is not evidence. The step artifact — exec: …, tool whoami: … — is the untrusted agent summarizing itself. The evidence is the door events, written by Agenthof and the runtimes. If they ever disagreed, the ledger is what happened. The ledger is append-only and hash-chained: it catches an edit, deletion or reordering that does not recompute every later hash. It is tamper-evident within those limits, not tamper-proof, and the docs say exactly where the limits are.

Any framework

The agent is two layers: a framework-neutral door layer — plain HTTP and MCP against a published wire contract, which also defines the two door tools and discovers the granted tools — and a thin LangChain shell that binds those tools and carries each model turn. Porting to another framework means rewriting the shell. The doors do not know or care which framework is talking. First-class support for agents built on other runtimes and frameworks is on the roadmap as "More harness adapters"; the point of this one is that it needed no special treatment.

The showcase, the hermetic CI run, and the honest-limits page are in the repo under Apache-2.0 (tagged v0.1.0). Bring a key, run it, and read the audit — then decide for yourself what it proves.

'No tools listed' should mean deny, not allow-all

Rojaneer — Mon, 28 Sep 2026 04:08:41 +0000

Here's a config bug that has shipped in more systems than anyone would like to admit:

# grant this service access to... nothing? everything?
allowedOrigins: []

In a surprising number of frameworks, an empty or missing list doesn't mean "no access." It means all access. Empty CORS origins → reflect any origin. A Kubernetes pod with no NetworkPolicy selecting it → all traffic allowed. A firewall with the rules commented out → wide open. The pattern is everywhere, and it has a name worth calling out: privilege by omission — the widest possible access, granted not by a decision but by the absence of one.

Why omission is the dangerous default

The danger isn't that someone types "allow everything." Someone typing that has made a choice you can see in code review. The danger is that nobody typed anything, and the system filled the silence with maximum privilege.

That happens constantly, and invisibly:

A refactor renames a field. The old key is now ignored, silently falling back to the default — which is "allow all."
A merge drops a line from a list. The list is now empty — which is "allow all."
Someone copies a config skeleton, means to fill in the allowlist later, and forgets. The skeleton is "allow all."
A typo in the key name (allowedTools vs allowed_tools) means the field you carefully wrote is never read. What is read is the default: "allow all."

Every one of these looks fine in review. The config reads as intentional. There's no red diff line saying "grant everything" — there's just... less config than there should be. And less config quietly resolved to more power.

Contrast that with the same mistakes under a deny-by-default rule: the refactor, the dropped line, the forgotten allowlist all resolve to less access. The agent or service suddenly can't do its job, someone notices in about five minutes, and they fix it. A too-small grant is a bug report. A too-large grant is an incident you find out about later, from someone else.

The rule: name your capabilities, or be rejected

The fix is two rules applied together:

The widest access must be an explicit marker you typed. "Everything" is a real, legitimate choice — but it should look like a choice: a literal ["*"], a mode: all, something a reviewer can see and question. Never something you back into by leaving a field blank.

Naming no capabilities at all is an error — reject it, don't default it. This is the part people skip. It's tempting to say "empty list = deny all, safe default, done." But an empty allowlist is almost never what someone meant; it's what they got when something went wrong. Silently denying everything hides the mistake (now you're debugging why the agent won't work). Silently allowing everything is a hole. Rejecting it at load surfaces the mistake immediately, while the person who made it is still looking at the file.

Call it no privilege by omission: fail closed, and fail loud. The ambiguous state — "a grant that names nothing" — shouldn't resolve to a guess in either direction. It shouldn't be representable as a running config at all.

A worked example

I build Agenthof, an open-source (Apache-2.0, Go) governance layer for AI agents, and we made this a rule the whole system is held to. From its constitution:

A grant that names a set of reachable capabilities — invokers, tools, executables — declares which ones; the widest such set is an explicit marker (a role's ["*"], a tool grant's tools: ["*"]), and a grant that names none is rejected at apply, never widened to the maximum.

Concretely, a tool grant used to allow a bare string as shorthand for "every tool this server exposes":

tools:
  - my-mcp          # retired: used to mean EVERY tool my-mcp exposes

That's exactly privilege by omission — the maximum, granted by writing the least. So it was retired. Every-tool access now has to say so — the ["*"] marker on the tools axis (the same token a role uses for groups), plus an explicit mode:

tools:
  - resource: my-mcp
    tools: ["*"]              # every tool this server exposes...
    mode: read-write          # ...and may mutate — you stated both axes
  - resource: billing-mcp
    tools: [get_invoice]      # or name exactly the tools you want
    mode: read-only           # and whether they may change anything

And a grant that names neither specific tools nor a mode is rejected when the config is loaded — with an error that tells you how to fix it:

bad-tool-grant: line 6: a bare tool grant is no longer accepted;
a tool grant needs tools and mode: write {resource: "my-mcp",
tools: ["*"], mode: read-write} for every tool, or list tools and set mode

The same rule holds across the other capability lists, not just tools. A role opens to everyone only via an explicit allowed_groups: ["*"]; a role that declares no access floor at all is rejected, never treated as open. Executable allowlists work the same way. The point isn't the specific syntax — it's that in every place the config names a set of capabilities, "I named none" is a compile-time-style error, not a runtime surprise.

How to apply it to your own configs

You don't need a governance framework for this. Next time you design a config that grants access, for each list-shaped permission ask:

What does empty/missing mean here — deny-all or allow-all? If you can't answer instantly, neither can the next person to edit it.
Make "everything" an explicit sentinel (["*"], all, a named flag) — never the value you get by leaving the field out.
Reject the empty/missing case at load time, with an error that names the two legitimate fixes (a real list, or the explicit-all marker). Fail loud, not into a default.
Validate before anything runs, so the mistake is caught at apply/startup — not discovered in production when an agent does something no one scoped it to.

One honest caveat: default-deny only buys you anything if the thing enforcing it actually consults the config on every access. A beautifully strict allowlist that some code path skips is decoration. Deny-by-default is a property of the chokepoint, not the YAML.

But get the chokepoint right, and this small discipline pays off constantly: the worst thing a dropped line, a typo, or a forgotten TODO can do to your permissions is grant too little. And too little is a bug someone reports on Monday — not a breach someone reports on your behalf.

If you want to see the rule enforced end-to-end, it's all in the open at github.com/agenthof/agenthof. And if you've hit the empty-list-means-everything trap in the wild, I'd love to hear where — I'm collecting them.

Keep your API keys out of your AI agent: a credential pattern for MCP servers

Rojaneer — Sun, 27 Sep 2026 11:08:31 +0000

If you've wired an MCP server into an agent, you've probably done something like this:

{
  "mcpServers": {
    "billing": {
      "command": "npx",
      "args": ["billing-mcp"],
      "env": { "BILLING_API_KEY": "sk-live-..." }
    }
  }
}

It works. It's also handing your live billing key to the least trustworthy process in the system.

The problem

An agent is a program that decides what to do at runtime based on text it was given — some of which comes from the outside world (a webpage it read, a document it summarized, a tool result). That's the whole point, and it's also why the agent process is the wrong place to keep a secret.

Two things go wrong with the config above:

The credential lives in the agent's environment. If the agent is compromised — prompt injection, a poisoned dependency, a tool that returns a malicious payload — the attacker is now one os.environ read away from your billing key. The blast radius of "the agent did something dumb" includes "the agent's keys are gone."
The agent can call everything, and you can't prove what it did. The MCP server exposes a set of tools; the agent can call any of them. When something goes wrong, your evidence is scattered across logs that the agent itself could have influenced.

You can't fix this by making the agent more careful. The agent is the untrusted part. You fix it by moving the trust boundary.

The pattern: put a gateway between the agent and the MCP server

Instead of letting the agent talk to the MCP server directly, put a small trusted process — a gateway — in the middle:

agent  ──►  gateway  ──►  MCP server
           (holds the       (needs the
            credential)      credential)

The credential lives in the gateway's environment, not the agent's.
The agent gets a short-lived token scoped to its current run, and a URL that only reaches the MCP server through the gateway.
On each tool call, the gateway injects the real credential just before forwarding upstream, and strips it from anything it hands back.

The agent is starved of credentials. It can make tool calls, but it never possesses the secret that authorizes them. Compromise the agent and you get a revocable, per-run token — not the billing key.

This is more than a reverse proxy, because the gateway is a policy decision point. Since every call goes through it, it can also:

enforce which tools each agent may call (default-deny),
enforce read-only access where you want it,
and record every call and every refusal in one place the agent can't rewrite.

A worked example

Here's the pattern implemented with Agenthof, an open-source (Apache-2.0, Go) governance gateway. The config is the useful part; the tool is just one way to run it.

1. Register the MCP server with the gateway — this is where the secret lives:

tools:
  ticket-search:
    kind: mcp
    url: https://tickets.internal/mcp
    credential_source: static_env
    token_env: TICKETS_MCP_TOKEN

TICKETS_MCP_TOKEN is read from the gateway's environment. The agent process never sees it.

2. Grant each agent only the tools it needs — default-deny:

name: legacy-triage
execution: fronted
endpoint: https://legacy.internal/agents/triage
tools:
  - resource: ticket-search
    mode: all                            # every tool ticket-search exposes
  - resource: billing-mcp
    tools: [get_invoice, list_invoices]  # only these two of billing-mcp

An agent gets access to a resource only if it's named here, and to the tools it names (or an explicit mode: all). Leaving the list off isn't "allow everything" — it's rejected at config load. Widest access is always something you typed on purpose, never something you got by omission.

Want read-only? Say so, and the operator's classification decides what counts:

tools:
  - resource: billing-mcp
    mode: read-only        # only the tools billing-mcp is declared to expose read-only

3. For OAuth-protected servers, even the client secret stays out of the agent. The gateway's broker mints a token from your identity provider per call:

tools:
  billing-mcp:
    kind: mcp
    url: https://billing.internal/mcp
    credential_source: static_env
    grant_type: client_credentials
    issuer: https://idp.example.com/
    token_endpoint: https://idp.example.com/oauth2/token
    client_id_env: BILLING_MCP_CLIENT_ID
    client_secret_env: BILLING_MCP_CLIENT_SECRET
    scope: billing.read
    read_only_tools: [get_invoice, list_invoices]

The client id and secret are read from the gateway's environment; the agent gets the minted access token's effects, never the token, and never the secret that mints it.

4. Because everything flows through one point, every tool call and every refusal lands in a hash-chained, tamper-evident audit ledger — so "what did this agent actually do?" has a single, ordered answer.

What this does not do

Being honest about the boundary is the whole point, so:

This governs and audits. It does not contain the agent. A compromised agent process still runs on some host; if that host has no sandbox, the process can still do local damage or reach the network directly. Keeping credentials out of the agent shrinks the blast radius — it is not a jail. Containment is your sandbox's job; this is the keys and the CCTV, not the locked room.
The ledger is tamper-evident, not tamper-proof. Hash-chaining means edits are detectable after the fact. It does not stop an attacker with enough privilege from rewriting history — it makes the rewrite show up.

Those aren't weaknesses to paper over; they're where the boundary actually sits, and knowing that is how you deploy the pattern correctly (gateway on a trusted host, agent in a sandbox, ledger shipped somewhere append-only).

The takeaway

Regardless of which tool you use, the pattern is portable:

Secrets live in a trusted gateway, never in the agent. The agent gets a scoped, revocable, per-run token.
Default-deny tool access. An agent reaches a tool only because you named it, and read-only where read-only is enough.
Log every call and refusal somewhere the agent can't edit.

The agent stays the flexible, fallible thing it's supposed to be — and it stops being the thing that holds your keys.

A working implementation of all of the above is at github.com/agenthof/agenthof. If you're doing this differently — a sidecar, a service mesh, provider-side scoping — I'd genuinely like to hear how it's holding up.