Human in the Loop for MCP: TrueFoundry vs Kong

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
Human in the Loop for MCP: TrueFoundry vs Kong
Human in the loop (HITL) for MCP is a gateway policy that pauses selected tool calls until a named human approves or denies them. It lets enterprises give AI agents real autonomy without turning every irreversible action into an unchecked risk.
Authentication proves who the agent is. Authorization proves what it may call. HITL answers the final question neither can: should this specific action happen now? Without HITL, one authorized mistake can become a P1, trigger blanket removal of agent write access, and stall the wider agent program.
TL;DR
TrueFoundry vs. Kong comes down to where human approval lives. Kong operates as a stateless API gateway: it evaluates each MCP tool call and authorizes or denies it synchronously, without maintaining the workflow state needed to pause and resume a request. TrueFoundry can hold a tool call at the gateway, notify governed approvers, and issue a scoped, time-boxed grant. Enterprises using Kong must build and operate that human-approval workflow themselves.
Why human in the loop matters
When permission is not enough
Imagine a financial-services platform team. Its agents reach internal systems only through an MCP gateway. Identity, RBAC, and audit logging are already in place. A cleanup agent can access Kubernetes, cloud accounts, and Slack, including a destructive database tool.
Now give that agent a reasonable quarter-end prompt: “Clean up unused infrastructure.” The risk becomes visible when you follow the request from permission to consequence.

Fig. 01 · One identity and one gateway authorize both paths. The difference is not access; it is consequence.
The agent starts with harmless work: listing pods, scaling idle deployments, and inventorying databases. Then it finds db-fin-rpt-01, unused for 34 days. The heuristic says stale, so it calls delete_database.
The call is valid, authenticated, authorized, and logged. That is precisely the problem: every conventional control answers whether the call is permitted, while none asks whether this irreversible action makes sense now.
What happens when HITL is missing
Once the call executes, the technical failure is recoverable. The loss of trust in agent autonomy is not.

Fig. 02 · A valid deletion moves from invisible to urgent, and ends with a freeze on agent write access.
From the VP Engineering chair, the lesson is not that the agent lacked controls, it had all of them. The failure was the missing decision between allow and deny. A brief approval before delete_database could have prevented both the quarter-end P1 and the later retreat to read-only agents.
HITL creates that third path. Routine reads and reversible changes continue at machine speed; delete, pay, send, and deploy wait for a named human. The example now becomes a gateway-policy problem, not recovery logic every agent team must reinvent.
How TrueFoundry implements HITL
TrueFoundry turns that third path into a first-class MCP gateway policy. Platform teams define once which tools require approval, and the rule applies across agents, clients, and frameworks.
Hold, notify, decide
Apply it to db-fin-rpt-01: when the agent calls delete_database, the gateway holds the request before execution, notifies a governed approver, and returns an approval-pending response the agent can safely retry. An approval creates a time-boxed grant scoped to the requester, server, and tool.

03 · The call pauses at the gateway, then resumes only under a scoped approval, or stays blocked with a recorded reason.
Because the approval state lives at the gateway, application teams do not reimplement pause, resume, notifications, denial handling, and audit logic for every agent. Only tenant admins and designated MCP Server Approvers can decide.
For the platform team, setup remains policy configuration: select the server and tools, set the validity window, choose a notification channel, and save. When rules overlap, the most restrictive policy wins. That workflow boundary is where the comparison with Kong starts.
What is missing in Kong
Kong’s MCP controls authenticate agents, enforce tool ACLs, and allow or deny calls. They do not support a native approval workflow that can hold an otherwise permitted tool call while a human decides.
That is the missing layer. HITL is stateful: the gateway must persist a pending request, notify authorized approvers, record the decision, and issue a scoped, expiring grant. A binary per-request allow/deny decision cannot provide that workflow by itself.
Why this becomes a platform problem
- Duplicated engineering: every agent team must implement pause-and-resume state, approver routing, retries, timeouts, denial handling, and audit events.
- Policy drift: each implementation makes different choices about which tools are gated, who can approve, and how long approval lasts. Platform teams lose a single enforceable standard.
- Operational burden: centralizing this in a separate service still means owning a new internal product, availability, tenancy, RBAC, idempotency, notification failures, upgrades, and on-call.
- Fragmented evidence: approvals and denials are spread across agent services and chat channels, making incident review and compliance evidence collection slower and less reliable.
- Enterprise outcome: teams either delay write-enabled agents or fall back to blanket read-only access. Both reduce developer velocity and the return on agent investments.
TrueFoundry vs Kong: HITL comparison
These costs all follow from the same architectural boundary: Kong governs the request, while the enterprise must build the approval lifecycle around it. The comparison below makes that boundary explicit.
The 10-minute evaluation test
The feature table reduces to one live procurement test. Ask each vendor: “An authorized agent requests an irreversible action on an MCP. Show me the human approval, the policy that triggered it, and the resulting audit trail.”
If the demo depends on custom workflow code in each agent, approval is not a platform capability; it is application debt.
Book a demo and gate your own riskiest tool call in an afternoon, or explore the Agent Gateway and MCP Gateway docs.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.

















.webp)



.png)

.png)










