They cannot hold an authorized tool call in a pending state, so the organisation loses the chance to review consequence before execution. That pushes approval logic into custom code or manual processes, which creates inconsistency, audit gaps, and higher operational overhead.
When a Gateway Can Only Say Yes or No, It Stops Being a Safety Checkpoint
An MCP gateway that only allows or denies a request has no place to pause an authorised tool call for human review or policy enrichment. That means every decision is forced into a binary path at the edge, even when the real governance question is whether the action should be executed now, delayed, delegated, or split into smaller steps. The design limitation is not just technical, it changes how control is exercised.
Once the gateway cannot represent a pending state, organisations usually compensate with custom orchestration logic, ticket-driven approvals, or manual sign-off. Those compensating controls can work, but they move decision quality away from a single enforceable control point and create uneven behaviour across tools, teams, and environments.
In practice, the missing state is what lets an organisation examine consequence before execution. Without it, the gateway becomes a simple gatekeeper rather than a policy enforcement layer that can support exception handling, conditional approval, or staged release of higher-impact actions.
Why That Limitation Changes MCP Operating Models
The biggest shift is that approval becomes an external workflow problem instead of a protocol-level capability. If the gateway cannot hold a request, the organisation must decide where the pause happens, who owns the review, how the original context is preserved, and how the approval result is enforced when the tool call resumes. That is harder to standardise than allow or deny.
This also weakens consistency. Two teams may solve the same problem in different ways, one with custom code in the agent path and another with a ticket or chat approval. The outcome may be functionally similar, but the control evidence, logging, and failure modes will differ. That makes auditability and operational support harder, especially when the same MCP pattern is reused across many agents or tools.
For practitioners designing MCP security, the protocol-level authorization model described in the Model Context Protocol: Authorization specification is important context because it shows the boundary between transport authorization and higher-order approval workflows. The practical lesson is that a gateway decision model should fit the control objective, not force every approval problem into a binary access check.
The architectural consequence is that consequence-aware control often migrates into adjacent systems, such as agent orchestration, workflow engines, or privileged access processes. That can be acceptable, but only if the organisation treats those systems as part of the control plane and not as informal glue code. Otherwise, approval becomes scattered and hard to prove.
Where the Control Gap Shows Up in Real Deployments
The gap is most visible when the tool action is technically authorised but still risky in context. A token may be valid, the tool may be allowed, and the request may be within policy, yet the operational impact could still be high enough to warrant review. A gateway that cannot express pending or conditional states cannot distinguish between routine automation and a case that should wait for confirmation.
That matters even more in environments that already depend on agentic workflows. NHIMG’s MCP Security Guide treats gateways, token passthrough, and authorisation as part of the practical control surface, because poor handling of approval boundaries can turn a security control into a routing layer. The underlying issue is not just access, it is whether the system can safely interrupt execution when consequence is uncertain.
Related identity and privilege patterns also become relevant. When a request is permitted automatically, the organisation still needs to know whether the calling agent, workload, or service has more authority than the action really deserves. If the gateway cannot pause for review, excessive privilege is more likely to translate directly into execution, which increases blast radius and reduces opportunities for human intervention.
That is why binary gateways often push teams toward compensating controls such as pre-approved action sets, step-up approval outside the gateway, or narrowly scoped tool segmentation. Those patterns can reduce exposure, but they also add design and operational overhead. The more exceptions you need, the more the gateway ceases to be the place where policy is actually decided.
Risk and Threat Considerations
A binary gateway creates exposure when the organisation assumes every authorised tool call is safe to execute immediately. If the system cannot hold a request pending, a high-consequence action may proceed before a reviewer can judge context, intent, or downstream impact. That increases the chance of accidental damage, abuse of overbroad authority, and weak auditability.
Failure mechanism: The gateway cannot represent intermediate states, so approval logic moves into custom code, workflow tools, or manual processes that are harder to govern consistently. Attackers and careless users benefit from that inconsistency because the highest-impact path often becomes the least standardised path.
Impact: Organisations lose a clean enforcement point for consequence-aware review, which can lead to untracked approvals, delayed detection of misuse, and a wider operational blast radius if an agent or operator issues the wrong tool call.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Binary allow/deny gateways affect whether agent actions can be paused before privileged execution. |
| ASI02 — Tool Misuse | MCP gateways mediate tool calls, so execution gating directly limits harmful tool misuse. | |
| Recommendation — Add a hold-and-review step before privileged agent actions can execute. Constrain tool paths so risky calls can be deferred or rejected before execution. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Gateway-only decisions can let high-impact functions execute without granular approval control. |
| Recommendation — Separate routine access from high-impact function execution with finer-grained authorization. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Approval gaps often widen effective privilege beyond what the task needs. |
| AU-2 — Event Logging | Custom approval workflows need auditable records when the gateway cannot hold requests pending. | |
| Recommendation — Limit each tool path to the minimum authority needed for the request. Log approval, deferral, and execution events with enough context to reconstruct the decision. | ||
Practitioner Guidance
What to verify: Confirm whether your MCP control point can preserve request context, decision reason, and approver identity when a tool call is deferred. If it cannot, treat that as a design limitation, not a minor feature gap.
Decision rule: If a tool action can create material business, security, or data impact, the control path should support a hold-and-resume pattern somewhere in the approval chain. If it cannot, restrict the tool scope until the surrounding workflow can enforce that pause reliably.
What good looks like: The organisation can show a consistent record of what was requested, who reviewed it, why it was approved, and what finally executed. The important test is not whether approval exists somewhere, but whether the approval is enforced at a predictable point in the execution path.
Practitioner takeaway: A binary gateway is adequate for simple access decisions, but it is not enough when the real control objective is to review consequence before execution. If the platform cannot pause an authorised action, the organisation must make that gap explicit and engineer a compensating control that is auditable, consistent, and hard to bypass.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org