Moving MCP secrets into a gateway leaves a hijacked agent holding only a per-run token

The case against the env block starts with how an agent works. It chooses its next action at runtime from text, and some of that text comes from outside: a webpage, a document it summarized, a tool result ^[3]. The post's author wrote, "You can't fix this by making the agent more careful. The agent is the untrusted part." ^[4] The direct setup has a second gap. The agent can call any tool the server exposes, and the record of what it called sits in logs it could have influenced ^[13].

The gateway moves the trust boundary one process over. The credential lives in the gateway's environment. The agent holds a short-lived token scoped to its current run, plus a URL that reaches the MCP server only through the gateway ^[5]. According to the post, compromising the agent then yields a revocable per-run token in place of the billing key ^[7]. That token still works until someone revokes it. An attacker who controls the agent can call whatever its grant list allows for the rest of the run. The grant list is where the design has to be strict. In the post's example, an agent named legacy-triage gets every tool on ticket-search but only `get_invoice` and `list_invoices` on billing-mcp ^[15]. Failing config load when the tool list is missing is the detail I would copy into any gateway ^[9].

Read-only mode is thinner. `mode: read-only` admits the tools a resource is declared to expose read-only, and the operator's classification decides what counts ^[10]. A write tool listed in `read_only_tools` passes as read-only. The OAuth example adds a second layer: the broker requests `scope: billing.read` from the identity provider when it mints each per-call token ^[11]. If the provider and the billing server enforce that scope, a mislabeled write call fails upstream even after the gateway lets it through. If they do not, the label is the only control.

The ledger claim needs one qualification. The post describes a hash-chained, tamper-evident log of every call and every refusal, kept in one place the agent cannot rewrite ^[12]. Tamper-evident means an edit can be detected. The agent cannot touch the log because it never writes to it. An operator with write access to the gateway host is a different case. In general, a hash chain holds up against that operator only if its latest hash is stored somewhere the operator cannot reach.

The costs are an extra network hop on every tool call and one process that now holds every upstream secret ^[5]. The post does not include latency figures for that hop. It is candid about the product: "The config is the useful part; the tool is just one way to run it." ^[14] Agenthof is open source under Apache-2.0 and written in Go ^[8], so the config semantics can be checked against the code. My context is agents that read outside text and can reach live, write-capable keys. There I think the hop is worth paying for. For an agent holding a sandbox key that can touch nothing billable, the env block is fine.