Integrations
MCP approval: human sign-off and single-use clearance for MCP tool calls
For platform and security teams who already run MCP servers or an MCP gateway, and now have to answer who approves the call that moves money, closes an account or changes production.
GembaOS is a zero-trust governance runtime for enterprise AI agents: policy-decided access, single-use clearance tokens bound to exact parameters, and accountable human approvals, running on-premises or in a private VPC. This page is about what sits between an MCP tool call and a production system once the connection itself is already governed.
What does an MCP gateway decide, and what does it leave open?
An MCP gateway decides the connection: which client may reach which server, under which identity, with which credential, and which tools are exposed to that caller. Those decisions are made before anyone knows what the agent will actually ask for. The tool list is served; the arguments come later.
| Question | Decided by the gateway | Decided per action |
|---|---|---|
| May this agent reach this tool at all? | Yes | — |
| Which credential is used? | Yes | — |
| May this refund of this amount on this order happen? | No | The policy |
| Who is accountable for it? | No | The signature chain |
| Does it still hold when the write happens? | No | The host’s reality check |
| Can it happen twice? | No | The single-use clearance |
This is not a gap in gateway design; it is a different layer. A gateway is about access. What follows is about authority for one action.
Where does GembaOS sit?
Sensitive tool calls are routed to the GembaOS capability gateway instead of directly to the business system. From there the call passes the four gates described in the architecture whitepaper: the policy decision, the signatures the route requires, a single-use clearance bound to the exact arguments, and the host’s re-read of the real state just before the write.
The agent keeps its own orchestration and its own MCP clients. What changes is where the sensitive call lands, and what exists afterwards: a work item with the verified facts, the arguments, the signatures and the execution, hash-chained and replayable.
Which layer owns which risk?
| Risk | Where it is handled |
|---|---|
| An agent reaches a tool it should not see | The gateway’s tool exposure and identity rules |
| A long-lived credential sits in the agent’s context | GembaOS: the credential stays in the capability gateway, released for one call under one clearance |
| An instruction inside a document or a tool description asks for more authority | GembaOS: content is data, never authority; a suspicious input flag routes the action to a person |
| Nobody can say who authorized a write | GembaOS: a named person’s passkey signature on the request, and on-behalf-of recorded when someone stands in |
| The record moved between the decision and the write | GembaOS: the reality check, the hold on the record and the limits re-read before the write — see the note on stale approvals |
| A retry writes twice | GembaOS: single-use clearance and a host-filled idempotency key |
Summary
MCP settled how agents reach tools. It did not settle who is accountable for what the tool then does, and a tool list cannot answer a question about an amount. Keep the gateway for access, and put the actions that move money, close accounts or change production behind a policy decision, a named signature and a clearance that is spent once.
Questions this note answers
Does GembaOS replace our MCP gateway?
No. A gateway governs the connection: which client may reach which server, with which credential, and which tools are exposed. GembaOS governs one proposed action: whether it may happen, who signs it, and that it executes once under a clearance bound to its arguments. Most deployments keep both.
How does a human approval work when the caller is an MCP client?
The tool call reaches the capability gateway instead of the business system. The policy decides the route; if the route reserves a step for a person, the call becomes an approval request that a named approver signs with their passkey, and the clearance is issued from the arguments they saw.
Do we have to change our MCP servers?
The servers keep their own interfaces. What changes is which endpoint the sensitive call goes to and what the adapter declares about that write, including how it guards against a concurrent change. The interface and adapter work is scoped in the architecture consultation.
What stops a tool description from granting an agent more authority?
Authority never comes from content. Tool descriptions, returned documents and messages are data; the decision to allow an action is taken by policy outside the model, against the Delegation of Authority, so text that asks for more cannot produce more.
Sources
As of September 2026 GembaOS holds no certification; the control mappings on this site are self-assessed, not audited. GembaOS is in its design partner stage. Read about the design partner program.
Last updated: · GembaOS v0.2