Agenthof Open-Source Governance Engine: Putting a Permission Leash on AI Agents

AI Agents are taking actions inside your systems, yet when something goes wrong, no one can say for sure—who authorized it? Whose permissions were used? Was anything denied? Agenthof offers a working answer.

Agenthof is an open-source governance plane licensed under Apache-2.0. Its core thesis is a single sentence: the Agent is forever "untrusted," but every request it makes must pass through a door—and the door authorizes, injects credentials, and writes the ledger.

Core Design: Two Programs, One Rule

Agenthof splits the system into two completely independent programs, and this is the foundation of the entire approach:

• agenthof is the governance engine, handling apply, run, audit, and investigate. It is never embedded in the Agent, nor does it decide how the Agent thinks.
• The Agent is a separate program (the repository ships a small LangChain Agent). agenthof invokes it over a socket and drives it through "doors": the model door, tool door, exec door, and spawn door. Each door authorizes the call, injects credentials the Agent never holds, and writes a ledger event bound to the originating human identity.

At runtime, the Agent has no network and no keys of its own. It cannot call backend systems directly—it can only ask the doors. When it needs to operate on a per-user isolated system, the gateway performs an RFC 8693 token exchange—swapping the originator's verified token for a token scoped to the upstream—and then calls the system as the originator. Keys never enter the Agent process.

RFC 8693 token exchange is an OAuth 2.0 extension defined by the IETF for exchanging tokens between trusted identity providers, allowing one subject to call downstream services as another subject (or as a downscoped role) without exposing the original credential. In Agenthof's scenario, the originator's verified token is the only trusted source of identity; the gateway uses it to obtain a token whose scope is narrowed to the upstream system, while the Agent process itself never holds or sees any key throughout. The key point is calling as the originator rather than as the Agent—audits trace directly back to a person, and permission boundaries are set by that person's authorization rather than by the Agent's runtime account. Compared with distributing long-lived credentials to Agents, token exchange concentrates key management into the gateway.

Reading the Receipt: Four Questions Answered at Once

After a run completes, agenthof audit <run> prints that run's ledger in order—that is the receipt. The following comes from a real sealed run, with only timestamps and path widths elided:

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
  model fast — 3 prompt / 5 completion tokens
  exec env — exit 0 (runtime) [runtime-attested: refexec env pid 35795 spawn 1]
  tool whoami — args 44136fa3 (token_exchange)
  spawn acceptance-worker/acceptance-sub → run r-e0fc07e8… succeeded (depth 1)
  workflow finished: succeeded

Map it to the four questions:

Who authorized it? invoked by dana@example.com—stamped onto this run, and every event belongs to it, not to svc-agent-bot. In production, it is signed by your own IdP and verified per call.

Which Agent, and what did it actually do? Each line—model fast, exec, tool, spawn—was written first-hand by Agenthof or the operator runtime ([runtime-attested: ...]), not by the Agent itself. Note what is absent: no prompt text, no completion text, and the model fast line does not even reveal which tool the model requested—the model's choices appear only in the form of door events they become.

Whose key was used? tool whoami — (token_exchange). The Agent called a per-user tool, but the gateway exchanged the originator's token and called as that identity—the step's own summary returns tool whoami: acting as: u-dana. The Agent holds only its own runtime token and never sees any key.

Was anything denied? Not in this run—the model only reached for what it was authorized to reach. Point the same workflow at a role whose exec allowlist excludes that command, and you can watch the Agent cross the authorization boundary:

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

The door said "no" and recorded that "no." The Agent was told refused by policy, the model continued, and the step still completed—a denial in the ledger is governance at work, not a crash.

A hash-chained ledger is a log structure that binds each record to the digest of the previous one: the hash of event N is computed from the content of event N plus the hash of event N−1, so if any historical event is altered, all subsequent hashes fail to match. It therefore provides "tamper-evident" rather than "tamper-proof"—tampering necessarily leaves a trace that can be verified, but the structure itself does not prevent writes. audit verify recomputes the entire chain and compares it against the archived value. This is why the text stresses "tamper-evident, not immutable": it cannot physically stop someone with write access from altering the ledger, but no alteration can be hidden. That is the realistic boundary of most audit systems.

The Point Most Demos Skip: It Isn't Hard-Coded

It is easy to fake with a script: have the Agent call tools in a fixed order, and the audit naturally looks clean, because no other path is possible. That only proves the pipes are connected—not that governance works.

Agenthof's showcase removes that safety net: a real model is given the Agent's actual capabilities as tools and decides round by round for itself what to call. The receipt above comes from exactly this loop—when the Agent oversteps, it is the door that stops it, not a script.

Model-driven operation requires no new door types. The model door only authorizes the logical model name, rewrites it to the provider's name, and forwards the rest of the tool-calling conversation unchanged. The agentic loop is just more governed model calls, plus whichever doors the model selects—each a first-hand event.

An agentic loop means the model decides its next action each round based on the current context—whether to call a tool, which one, whether to keep reasoning—rather than executing in a fixed scripted order. The key difference from traditional function-call orchestration is that control flow is produced by the model, so paths are unpredictable and cannot be enumerated in advance to guarantee safety. Agenthof's view: rather than trying to constrain the model's "thought process," constrain every call it can actually reach. Broken down, an agentic loop is nothing more than a series of model calls plus a series of tool calls the model chooses autonomously; as long as each one passes through its corresponding door and is recorded in the ledger, the loop remains inside the governance boundary no matter how free it is. This also explains why model-driven operation needs no new door types—doors govern calls, and the varieties of calls are finite.

Three Honest Limitations

Trust is built precisely on candid limitations:

One, this showcase does not prove isolation. The isolation chamber here is a host process launched by a test double; nothing in this run proves the Agent cannot reach the provider on its own. Those walls are the operator runtime's responsibility, and the project keeps a separate Podman-based proof (real rootless containers, --network none, checked for no egress).

Two, it makes no promises about outcomes. Real models vary—a run may skip a door, call twice, take another path. The promise is narrower and more testable: whatever the model does, it is governed and recorded in the ledger.

Three, the Agent's own summary is not evidence. The Agent returns a tidy "what I did" artifact—good to read but worthless as evidence, because it was written by an untrusted Agent. The evidence is the door events, written first-hand by Agenthof and the runtime. If the two conflict, the ledger wins. And the ledger is tamper-evident, not immutable—the documentation draws that line explicitly.

No-egress network isolation is a container security practice that cuts off a process's network entirely, typically in the form of a Podman rootless container combined with --network none, so the process has neither an outbound route nor a listening port. Under this configuration, even if the Agent is steered by the model toward connecting directly to a provider, it fails because there is no network path. The reason the text repeatedly distinguishes "a host process launched by a test double" from "a separate Podman proof" is precisely that only the latter provides strong guarantees at this level: the former merely happens not to access the network, while the latter strips away networking at the kernel capability level. The governance plane governs authorization and record-keeping; the isolation chamber governs physical reachability. The two have different responsibilities and cannot substitute for each other.

Run It Yourself

The engine, the Agent, the showcase, the sealed CI run, and the honest-limitations page are all in the Apache-2.0 repository:

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

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

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

One-line Summary

Agenthof uses an independent governance engine and authorization doors to make every call of an untrusted Agent authorizable, traceable, and deniable.

Paragraph Summary

Agenthof is an Apache-2.0 open-source governance plane whose core thesis is that the Agent is forever untrusted, and every request must pass through a door for authorization, credential injection, and ledger recording. The system splits the governance engine and the Agent into two independent programs; the Agent has no network and no keys and can only request operations through the model, tool, exec, and spawn doors; when per-user isolated calls are needed, the gateway performs an RFC 8693 token exchange to access the upstream as the originator. After a run, agenthof audit prints a hash-chained ledger that answers the four questions—who authorized it, which Agent did what, whose key was used, and whether anything was denied—all at once. The showcase uses a real model that decides round by round rather than a hard-coded script; when it oversteps, the door blocks it and records the denial, demonstrating governance rather than plumbing. The author candidly notes three limitations: the showcase does not prove container isolation, it makes no promises about outcomes, and the Agent's self-report is not evidence.