Why do MCP controls need call-time authorisation instead of connection approval?

Why connection approval is not enough for MCP

Connection approval is a coarse trust decision. It tells you a client may talk to a server, but it does not yet answer the security question that matters in practice: whether this specific call should be allowed, with this argument set, against this target resource, at this moment. That distinction matters because delegated access becomes safe only when the decision is made at the point of use.

Call-time authorisation is the control that turns a broad connection into a bounded action. It can evaluate context, scope, target object, requested tool, and current policy before execution. For MCP, that is the difference between exposing a capability surface and governing actual use of that capability.

Connection approval also tends to age badly. A server that was acceptable at onboarding may later gain new tools, inherit new data access, or be placed in a different trust context. Call-time decisions let the system re-check intent and privilege continuously instead of assuming the original approval still fits the current request.

What call-time authorisation actually controls

In an MCP flow, the useful security boundary is not the transport connection itself, but the individual tool invocation. A single session may contain harmless reads, high-risk writes, and calls that touch different resources. Call-time authorisation lets the policy engine distinguish those cases, so the same connected client can be allowed to query metadata, denied on destructive actions, and constrained on sensitive objects without forcing an all-or-nothing decision.

This is why fine-grained authorisation belongs close to the tool execution path. It can account for the requested function, the target resource, the delegated scope, and any policy conditions that should narrow access further. The practical result is smaller blast radius, clearer auditability, and fewer assumptions hidden behind a shared connection trust decision.

For MCP practitioners, the right mental model is externalised authorisation rather than trusted socket equals trusted action. The MCP authorization specification is explicit that servers act as OAuth 2.1 resource servers and that tokens should be audience-bound rather than blindly passed through.

Why this matters for delegated access, auditing, and revocation

Call-time authorisation is what lets delegated access stay proportionate over time. If approval only happens at connection establishment, the server may keep exercising broad privilege long after the original rationale has changed. If approval is checked per call, policy can be tightened, revoked, or stepped up based on the sensitivity of the specific operation instead of the existence of an open session.

It also produces better evidence. A connection log can show that a server was reachable, but it cannot show which tools were actually used, which resources were targeted, or whether a denied action was attempted. Call-time checks create the right audit boundary for tool-level accountability, which is essential when an MCP server is acting on behalf of a user, a workflow, or an automated agent.

This is especially important in agentic workflows where tool access is delegated dynamically. If the authorisation decision is not made at call time, the system tends to drift toward standing privilege, and that is exactly the condition that makes abuse harder to contain. AI Agent Authorisation Guide and MCP Security Guide both reinforce task-scoped, per-action decisions rather than broad session trust.

For a broader authorisation design lens, Authorisation Models Guide helps place MCP decisions into RBAC, ABAC, and policy-based control patterns, while IAM and IGA Basics covers the governance logic behind access review, entitlement control, and least privilege.

Risk and Threat Considerations

Without call-time authorisation, MCP can become a confused-deputy problem: a connected server may exercise authority that is broader than the request truly warrants. That creates overreach risk for routine actions and a direct abuse path if a tool, argument set, or target resource is unexpectedly dangerous.

Failure mechanism: A connection-level approval is reused as if it were a standing permit, so the server can invoke high-impact tools, reach sensitive resources, or continue acting after the original context has changed.

Impact: Attackers or misconfigured workflows can expand access, trigger unintended side effects, or hide abuse inside an otherwise trusted session. The resulting exposure is usually larger than a single call, because the control failed at the point where privilege should have been bounded.

That risk is amplified when the MCP server itself aggregates many downstream capabilities. A weak approval model can allow one connected client to reach tool chains, secrets, or administrative actions that were never meant to share the same trust level. Top 10 NHI Issues and Ultimate Guide to NHIs, key challenges and risks both reflect the same operational pattern: once privilege is too broad or too durable, the failure becomes difficult to contain.

Practitioner Guidance

What to prioritise: Treat connection approval as the transport trust check and call-time authorisation as the actual security control. If your design cannot answer “should this exact tool call be allowed now?”, the model is not sufficiently constrained.

What to verify: Make sure the decision input includes the tool name, arguments, target resource, current subject, and policy context. If the server can execute meaningful actions without re-evaluating those fields, the approval boundary is too weak.

Decision rule: If a request can change data, reach a sensitive system, or consume a delegated capability, require per-call policy evaluation rather than relying on the original connection approval.

Practitioner takeaway: In MCP, the safe unit of trust is the individual action, not the session, because only call-time authorisation can keep delegation bounded to the exact capability being used.

Related resources from NHI Mgmt Group

• Why do MCP agents need runtime authorisation instead of one-time consent alone?
• How can organizations secure their MCP server credentials?
• Why is OAuth considered a better alternative for MCP servers?
• Why is it crucial to adopt new authentication methods in MCP usage?