TrueFoundry Put the Approval Decision Where an Agent Builder Cannot Skip It

Two announcements from the same company, in the same week, use the word approval to mean two different things. Missing the difference is the easy way to overstate this story. Getting it right is most of what there is to say.

What TrueForge is, precisely

On 19 August 2026, TrueFoundry, an enterprise AI infrastructure company, published TrueForge: an open source agent runtime, released under the MIT License, distributed on GitHub as truefoundry/trueforge and on npm as @truefoundry/trueforge. We read the repository and its license file directly. The README describes TrueForge as running the agent execution loop, model calls, MCP tools, skills, sandboxing, approvals, context management and session state, and exposing it as a chat UI, an HTTP API with a TypeScript SDK, and an embeddable UI SDK. It runs in a local, single process mode for a single machine, or a hosted mode backed by Postgres and Redis for a shared or production deployment. TrueFoundry's own material describes TrueForge as the harness it runs in production, and states that other teams, including Automatiq and NetApp, run agentic workloads on it. That production claim, including TrueFoundry's own use, is TrueFoundry's account of its own customers and its own system. We have not independently confirmed it with those companies.

The checkpoint TrueForge ships is a per agent setting

Read the README carefully and the approval feature sits exactly where you would expect from a self hosted runtime library. TrueForge's setup flow has a team configure its models, MCP servers, skills and sandbox once, per agent, from a catalog. Human checkpoints, described as tool approval, ask user questions and generative UI in chat, are listed among those per agent capabilities. Nothing in the public README states that this checkpoint is mandatory, defaulted on, or enforced outside the agent that configured it. That is not a criticism of the project. It is simply what a runtime library is: whoever assembles the agent decides what the agent does, including whether it pauses for a human before calling a tool.

The README does not draw an explicit line between TrueForge and TrueFoundry's separate commercial MCP Gateway product. We are drawing that line ourselves, because the two are documented as structurally different things, and the difference is where the evidence actually lives.

The Human Gate is a different control point

On 13 August 2026, TrueFoundry published an architecture writeup titled The Human Gate: Designing MCP Tool Approvals at the Gateway Boundary. It describes a mechanism inside TrueFoundry's commercial MCP Gateway, a network intermediary that sits between an MCP client, of any kind, and the downstream MCP tool server. The documented flow: a tools/call reaches the Gateway and matches a configured approval policy. The Gateway holds the call rather than invoking the downstream tool, creates or reuses a pending approval request, and notifies the configured approver. The caller receives a successful result whose _meta.approval_status field communicates that execution is pending, rather than an error the client has to interpret on its own. A human then approves or denies. On approval, the Gateway releases execution according to the policy's configured validity: a one-execution grant ties the approval to that specific pending call, while a time-based grant creates a window in which later calls proceed without a fresh human decision. TrueFoundry's post states denial is intentionally ephemeral rather than a standing block, and that the resolved requester identity is treated as part of the security boundary, not merely an audit label, so an approval granted to one identity does not authorize another. TrueFoundry's separate MCP Gateway documentation describes the same policy as scoped per server and per tool, so a specific tool judged destructive can be flagged for approval once, at the Gateway, and that flag applies to every agent whose calls pass through it, rather than being something each agent's own configuration has to remember to set.

Why the location of the boundary is the actual claim

A tool approval that lives inside an agent's own configuration is only as reliable as every team that builds an agent. Miss one deployment, one internal tool, one contractor's fork, and the destructive call goes through unapproved, because nothing outside that agent was ever asked to check. A tool approval that lives at a Gateway the agent's traffic has to pass through does not have that failure mode in the same way. The Gateway does not need the agent's cooperation to hold the call, because the agent was never the thing deciding whether to hold it. TrueFoundry's own framing in the Human Gate post is explicit that this is a Gateway convention layered on top of MCP, not a state the MCP protocol itself defines, and that a client has to understand the _meta.approval_status convention to behave correctly around it. Held at the Gateway is the correct location if you want a policy that survives an agent builder who never thought about approval at all. It is not, by itself, proof that every client behaves correctly when it receives a pending result instead of a tool response.

What remains unconfirmed

Several things this record does not settle. Whether the hold actually happens before the downstream tool is invoked in a running deployment, rather than in the documentation describing the design, is not something we reproduced. How many organizations run TrueFoundry's MCP Gateway with approval policies active, beyond TrueFoundry's own account of its business, is not public. Whether TrueForge agents typically route their MCP traffic through the commercial Gateway, or operate independently of it with only their own per agent checkpoint, is not stated in the material we read. And the production claims for TrueForge itself, including TrueFoundry's statement that it runs the harness in its own production and that named customers use it, are the vendor's account of its own product and its own customers, not an independent confirmation.

What is solid: TrueForge is a real, MIT licensed, publicly inspectable open source artifact with a documented per agent approval checkpoint. The MCP Gateway's Human Gate is a documented design for holding a matched tool call at a shared network boundary, with stated validity, denial and identity scoping semantics, independent of which harness issued the call. Those are two different claims, at two different levels of confidence, and neither one is evidence for the other.

Where this sits in the pattern

Moona Intelligence has used Human Authority to mean the set of decisions reserved for a person, and the conditions under which that reservation can legitimately be delegated to software. A per agent checkpoint leaves that reservation as a convention each builder has to remember. A Gateway boundary that holds the call regardless of which agent sent it turns the reservation into something closer to a structural property of the system, at least for whatever traffic actually passes through it. That is consistent with the broader move we have tracked toward deciding authority outside the model, at the point of execution, and with the market's own drift toward deciding before a tool call executes rather than after. What TrueFoundry's documentation adds is a specific, named mechanism for one part of that idea: an approval flag set once, at a shared boundary, that an individual agent build does not get to silently skip. Whether it holds up as reliably as the design describes is a claim only a running deployment can answer.