MCP tool approvals at the gateway boundary: what changes

At a glance

What this is: This is an analysis of MCP tool approvals at the gateway boundary and the key finding is that approval is an implementation convention layered on top of MCP, not something the protocol itself standardises.

Why it matters: It matters because IAM, PAM, and NHI teams need to separate transient approval from standing authorisation, especially when shared gateways mediate tool use across agents, humans, and downstream services.

👉 Read TruFoundry's analysis of MCP tool approvals at the gateway boundary

Context

MCP tool approvals sit in the gap between tool invocation and authorisation, where a gateway can hold a call, notify an approver, and release execution only after a human decision. The primary identity problem is not whether tools can be gated, but whether organisations understand that approval is an implementation control at the boundary, not a protocol guarantee.

For IAM and NHI programmes, that distinction matters because approval metadata, requester scope, and validity windows determine whether a gated action is truly temporary or becomes an unintended standing privilege pattern. This is a governance problem for AI gateways, MCP servers, and the service identities that call them, not just a UI problem for approvers.

Key questions

Q: How should security teams implement MCP tool approvals in gateway-controlled environments?

A: Start by treating approvals as a gateway enforcement function, not a protocol feature. Hold the call at the boundary, return explicit pending metadata to the client, and require the caller to branch safely when approval is outstanding. Then scope the decision to a resolved requester identity, a specific server, and a specific tool, so the grant cannot drift across actors or sessions.

Q: When does time-based approval create more risk than it reduces?

A: Time-based approval becomes risky when later arguments can change the safety of the action, when the same grant can be reused by a different identity, or when the team cannot explain why a fresh human decision is unnecessary. In those cases, the time window is effectively standing authority, which belongs in policy design rather than informal convenience.

Q: What do teams get wrong about approval metadata and audit evidence?

A: They often assume a pending result or request ID is the same as a full compliance record. It is not. Correlation is useful, but the approval record still needs the approver identity, decision time, validity scope, and any conditions attached to the grant. Without those fields, the trail is incomplete for governance and incident review.

Q: Who is accountable when an MCP tool call is authorised through a gateway and fails downstream?

A: Accountability is shared across the gateway, the MCP server, and the system behind the tool. The gateway must validate the request it sees, the server must not accept mismatched headers or stale state, and the downstream system must enforce its own access boundaries. Policy delegation does not remove responsibility for the final action.

Technical breakdown

How MCP tool approvals layer onto the protocol boundary

MCP defines tool discovery, invocation, schemas, and results, but it does not standardise a universal approval workflow. A gateway can intercept a tools/call request, hold it, and return a pending result that a client must understand as “waiting for approval” rather than tool failure. That means approval lives in product convention and client behaviour, while MCP conformance only guarantees the underlying tool substrate. The 2026-07-28 revision adds richer interrupted-workflow handling, including input_required results and Tasks, but those are distinct protocol mechanisms with different semantics.

Practical implication: Treat gateway approval as a control plane convention and verify that calling systems branch correctly on pending-result metadata.

Why requester scoping and grant validity define the security model

The security semantics of tool approval depend on who the requester is and how long the grant lasts. A one-execution approval binds the human decision to a single pending call, while a time-based grant gives the requester + server + tool tuple temporary authority for later calls. That is useful for repeated safe actions, but it means later argument sets may execute without fresh human review. Denial is intentionally non-durable, so permanent prohibition must live in access control, tool exposure, or policy, not in a queue of approval decisions.

Practical implication: Scope approvals to the resolved requester identity and choose validity modes that match the risk of argument changes.

Why annotations help routing but cannot become trust anchors

Tool annotations such as destructiveHint can be useful signals for routing high-risk calls into approval, but MCP says clients must treat annotations as untrusted unless the server is trusted. That creates an important boundary: self-description is not enforcement, and metadata is not the same as policy. The gateway can use annotations to target controls, yet the organisation still needs independent classification of tools and explicit policy precedence. Otherwise a malicious or mistaken server can influence how risky a call appears without changing the underlying authorization model.

Practical implication: Classify tools independently and use annotations as inputs to policy, not as evidence of trust.

Threat narrative

Attacker objective: The objective is to turn a controlled tool invocation into repeated execution authority with weaker human scrutiny and incomplete audit context.

1. Entry occurs when a caller reaches the MCP gateway with a tool invocation that matches an approval policy and is held rather than executed immediately.
2. Escalation occurs when the approval state is treated as a reusable grant or when clients misread pending metadata, allowing later calls to proceed under weaker review than intended.
3. Impact occurs when consequential tool actions execute with scoped but overextended authority, creating audit gaps, unsafe mutations, or delayed detection of misuse.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Approval at the gateway is not a protocol feature, it is an enforcement choice. MCP gives vendors room to build approval semantics, but that flexibility also means there is no shared approval contract that clients can assume. The field should read this as a governance boundary problem, not a protocol deficiency. Practitioners should therefore validate both the gateway convention and the client behavior that interprets it.

Temporary approval is a form of delegated authority, not repeated judgment. A time-based grant changes the meaning of a human decision from one execution to a bounded execution window. That is acceptable only when the action is stable enough that later argument changes do not matter materially. The implication for IAM and PAM teams is that approval duration now belongs in the same policy conversation as scope and identity.

Requester identity becomes part of the control, not just the audit trail. If an approval can follow the wrong principal across a shared gateway or agent layer, then the boundary has already failed. This is why resolved requester identity, tool identity, and execution path must be correlated together. Identity governance for MCP must treat requester scoping as a first-class authorisation variable, not an annotation.

Approval fatigue is the clearest sign that the control is mis-sized. If humans are approving actions that policy could already decide, the gate becomes latency with theatre rather than a security decision. That is especially true in AI gateway environments where tool calls are frequent, repetitive, and context-sensitive. The right model is to push deterministic decisions into policy and reserve human approval for genuinely consequential exceptions.

Gateway approvals are shaping the market toward policy-aware tool mediation, not universal trust in AI workflows. The operational lesson is that enterprise AI control will increasingly sit at shared boundaries where identity, tool exposure, and audit correlation meet. Organisations that still treat approval as a checkbox will miss the larger shift: execution governance is becoming a layer in the AI gateway stack, and it must be designed accordingly.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That governance gap makes OWASP Top 10 for Agentic Applications 2026 a useful next lens for tool-use risk, because approval and authorisation failures often appear together.

What this signals

Approval governance will increasingly sit inside the AI gateway, not around it. That shifts the programme question from “can we approve tool use” to “can we prove which identity, tool, and grant conditions were actually enforced at runtime.” As gateway-mediated AI workflows spread, the control becomes only as strong as the client’s handling of pending states and the organisation’s ability to correlate decision records.

Pending-state observability is the new audit gap. If teams cannot distinguish waiting, denied, retried, and released tool calls, they will mistake workflow noise for governance. That is why approval telemetry should be treated as part of identity evidence, not just product instrumentation.

Tool mediation is becoming a lifecycle problem as much as an access problem. The question is not only who may call a tool today, but when temporary authority expires and whether that expiration is enforced consistently across humans, service identities, and AI-driven callers. Programmes that still separate IAM, PAM, and NHI controls will struggle to see the full execution path.

For practitioners

• Define approval as an enforcement layer, not a protocol guarantee Document exactly which MCP gateway components hold the call, create the approval request, and release execution. Require clients to recognise pending-result metadata explicitly and fail safe when they do not.
• Separate one-execution and time-based authority Use one-execution approval for irreversible or argument-sensitive actions, and reserve time-based grants for repeated calls where later inputs are still acceptable. Record the requester + server + tool tuple and review the expiry window as part of policy.
• Correlate requester identity with every gated call Make requester identity part of the authorization boundary at the gateway, not merely an audit label. Verify that approvals do not transfer across identities, sessions, or agent contexts unless policy explicitly allows it.
• Treat annotations as inputs, not trust signals Use tool annotations such as destructiveHint to route calls into scrutiny, but independently classify high-risk tools and keep standing prohibition in access control or tool exposure policy. Do not let a server describe its own risk class.
• Measure approval fatigue as a control-quality signal Track approval latency, re-request frequency after expiry, the share of calls using one-execution versus time-based grants, and the rate of admin fallback. If approvals are mostly predictable, move those decisions into static policy instead of human review.

Key takeaways

• MCP tool approvals work as gateway-enforced convention, not as a protocol-defined approval standard.
• Requester identity, approval duration, and pending-state handling determine whether the control is temporary authority or weakly bounded access.
• Teams need approval telemetry that proves real decisions, because audit correlation without scope and expiry evidence is not enough.

Key terms

• MCP Tool Approval: A gated control pattern where a tool call is held by a gateway until a human decision permits execution. The approval is not part of the MCP standard itself; it is an implementation-layer policy that depends on client behaviour, requester identity, and release semantics.
• Pending Result: A response that tells the caller a tool invocation has been accepted for processing but not yet executed. In gateway approval flows, this state is the signal that a human decision is pending, and callers must handle it explicitly rather than treating it as failure.
• Time-Based Grant: A temporary authority that allows repeated calls for a defined requester, server, and tool tuple until expiry. It reduces repeated review for stable actions, but it also widens the review gap if later arguments materially change the risk of execution.
• Requester Scoping: The practice of binding an approval decision to the resolved principal that asked for the action. It prevents a grant from silently transferring across identities or agents and is essential when multiple callers can reach the same gateway or tool.

What's in the full article

TruFoundry's full blog post covers the operational detail this post intentionally leaves for the source:

• Documented MCP approval flow for gateway-held tool calls and pending-result handling
• Product-specific guidance on request reuse, approval validity, and client branching logic
• Diagrammed relationships between tool approvals, pre-tool guardrails, and post-tool guardrails
• Implementation notes on audit correlation and approval metadata in the gateway

👉 The full TruFoundry post covers approval semantics, gateway placement, and audit correlation in more implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.