Adding Human Approval Before AI Agent Actions Through Kong

Where approval belongs in a Kong-fronted architecture

Kong typically fronts agent traffic for routing, authentication and rate limiting. Those functions answer who is calling and how often. They do not answer whether this particular tool call, with this payload, should proceed without a person looking at it. That is a per-action decision, and it needs to be made before the action executes.

Two placement mistakes are common. The first is review after the fact, where a log is inspected once the write or transaction has already happened. That is detection, not approval. The second is approval buried in application code inside each agent, which gives every team its own logic, its own timeouts and its own evidence format.

A more dependable pattern separates the roles. Kong handles traffic and API management. A policy decision point evaluates each interaction or tool call and returns allow or escalate. A policy enforcement point in the request path acts on that result, so an escalated call cannot reach the downstream system without a decision. Whether the enforcement point is a custom plugin, an external callout or a separate component in the path alongside Kong is an implementation choice. The requirements below apply to all three.

This approval step corresponds to the configuration in which the AI system defers to a human. NIST AI RMF describes the range as the system deciding autonomously, deferring to a human expert, or acting as an additional opinion for a human decision maker. Approval gating is the deferring case, applied only to the actions that warrant it.

Failure modes and governance considerations

Most failures sit at the edges of the flow. An approval service that is down should deny escalated calls, not pass them. A request that is approved after the agent has abandoned it should not execute stale. Approvers who see only a tool name, without the payload and the content that triggered the call, cannot make a meaningful decision. OWASP specifically flags actions triggered by externally retrieved content as a case for human confirmation, so the approver view should include that context.

Approver identity is a second weak point. Attribution to a named person requires binding the human identity to the agent identity and the specific action. NIST NCCoE is exploring exactly this question for human-in-the-loop authorization, so treat it as emerging guidance rather than a settled standard and keep your implementation easy to revise.

Regulatory context matters, but scope it carefully. As of November 2026, Regulation (EU) 2024/1689 requires that high-risk AI systems be designed so natural persons can effectively oversee them, with appropriate human-machine interface tools. The recitals add that overseers need competence, training and authority, and that oversight measures should include operational constraints the system cannot override. Whether a given agent is high-risk depends on its classification, so do not assume every agent deployment falls under that text. NIST also calls for documenting instances where human operators override AI decisions, so record approvals and overrides as separate events.

Where Trussed fits

Trussed is runtime control for consequential AI. It enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. The available outcomes are allow, redact, block, rate limit and escalate for human approval. Escalation is enforced at runtime, not reviewed after the fact, so it sits alongside Kong, which continues to manage traffic and APIs.

Enforcement also generates audit-ready evidence continuously, mapped to frameworks including the EU AI Act and NIST. For a regulated enterprise, this means the record of what the AI was allowed to do and what it did comes from the same mechanism that applied the policy. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. It has run in continuous production in a regulated enterprise for more than 18 months.

The design requirements above hold whichever route you take. Trussed addresses per-interaction and per-tool-call enforcement. It does not provide transaction-level governance or end-to-end tracing of agentic workflows.