Connection-time authorization decides whether a user or agent may connect to a server, usually at token issuance or renewal. Per-action authorization decides whether a specific tool call should execute right now, based on policy, delegation, capability, and risk signals. The first governs access to the channel. The second governs each runtime action.
Connection-time authorization vs per-action authorization
Connection-time authorization is a gate on the session itself, while per-action authorization is a gate on each tool invocation after the session exists. In MCP-based workflows, the distinction matters because a valid connection does not automatically mean every tool call, resource read, or side effect should be allowed. The stronger design is usually to keep the channel open only as a transport, then evaluate each sensitive action against policy in real time.
Connection-time checks are best for coarse questions such as whether the requester is authenticated, whether the server should accept the token, and whether the session should exist at all. Per-action checks answer the harder question: given this user, agent, scope, context, and risk state, should this specific operation execute now? That difference becomes important when the same MCP client can make low-risk and high-risk calls in the same session, because a one-time approval cannot safely cover all future tool use.
In practice, connection-time authorization is closer to access admission, while per-action authorization is closer to delegated decision-making. The first can rely on token validity, audience, issuer, and coarse scope. The second should consider the tool name, target resource, requested parameters, current delegation, and whether the action crosses a privilege boundary. For MCP, that often means externalized authorization logic rather than trusting the original connection as proof that later tool use remains appropriate.
Why the distinction matters in MCP workflows
MCP workflows commonly involve an AI agent, a client, one or more servers, and tools with very different blast radii. A connection token may be sufficient to reach the server, but it is not sufficient evidence that the next tool call is harmless. A read-only lookup, a file write, a ticket update, and a secrets-related action should not be treated as equivalent just because they share the same session.
The security value of per-action authorization is that it can shrink standing privilege inside an otherwise connected session. It lets you express task-scoped access, just-in-time approval, and risk-based denial at the moment the action is requested. That is especially useful when the agent can chain tools, because the risk often emerges from sequence, context, and cumulative effect rather than from the initial connection alone.
Connection-time authorization still has a role. It can stop unknown or expired clients early, reduce noise, and prevent unauthorized sessions from ever forming. But it should be treated as the first boundary, not the only one. If the server accepts a session and then blindly executes all subsequent tool requests, the effective control becomes “whoever connected may act,” which is too coarse for high-trust workflows.
How to choose the right control boundary
The practical rule is simple: use connection-time authorization for session admission, and use per-action authorization wherever the action can change data, spend money, expose secrets, trigger side effects, or cross a trust boundary. If a tool call would still be dangerous even from an already authenticated session, it needs a second decision at runtime. That is the point where authorization becomes materially different from transport-level access.
For MCP server design, this usually means separating identity of the caller from permission to perform each tool operation. The server should not assume that a connected agent can safely reuse the same privilege for every request, especially when tool inputs come from dynamic context, retrieved content, or user prompts. The more the workflow resembles delegated execution, the more you want the authorization decision to be specific to the action, not just the session.
Operationally, per-action authorization is easier to justify when you can log the request, the decision, and the reason code for each high-value tool call. That gives you auditability and supports step-up review for sensitive actions. Connection-time authorization alone usually cannot provide that level of control, because it produces one allow-or-deny event for an entire session rather than a decision trail for each impactful action.
Risk and Threat Considerations
The main risk is privilege amplification: a session that was safe to establish can become unsafe to reuse if later tool calls are not re-evaluated. In agentic workflows, attackers also benefit from the gap between initial admission and runtime action, because they can steer the agent toward a higher-impact operation after the connection has already been trusted.
Failure mechanism: A server that treats connection approval as sufficient for all later tool invocations creates a broad trust boundary, so a compromised, over-tasked, or misled client can keep acting until the session ends.
Impact: That can lead to unauthorized data access, unintended writes, privilege abuse, and harder-to-detect abuse chains, especially when tool calls are chained through an agent that appears legitimate at connection time.
Practitioner Guidance
What to prioritise: Put the strongest controls on tools that change state, reach sensitive data, or can be chained into a larger workflow. Those are the cases where a connection-level allow decision is least trustworthy.
What to measure: Track how often runtime authorization changes the decision after a session has already been admitted. If nearly every sensitive action is implicitly trusted, the model is too coarse.
Common mistake: Assuming OAuth-style session acceptance is enough because the client is “already authenticated.” Authentication proves who connected; it does not prove each later action is still appropriate.
Practitioner takeaway: The attack surface is not the connection alone, it is the sequence of actions that follow it. Per-action authorization is what stops a valid session from becoming a standing privilege channel.
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 | MCP workflows must limit agent privilege per action, not just at connection time. |
| Recommendation — Enforce per-action authorization to prevent agents from reusing broad session privilege. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | The question is about enforcing access decisions at connection and action boundaries. |
| IA-5 — Authenticator Management | Connection-time authorization depends on valid tokens and credential handling. | |
| AU-2 — Event Logging | Per-action authorization needs auditable decisions for individual tool calls. | |
| Recommendation — Enforce tool-level access decisions instead of relying only on session admission. Validate and manage tokens so session admission is tightly controlled. Log each sensitive tool decision with context and outcome for review. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Per-action authorization is the control boundary that prevents overbroad function use. |
| Recommendation — Apply function-level checks before executing each sensitive tool call. | ||
Practitioner Guidance
What to verify: Check whether the MCP server enforces authorization at the tool boundary, not just at login or token acceptance. If the same session can invoke multiple tools with different impact levels, the runtime decision must be explicit and policy-backed.
Decision rule: If the request can modify state, access sensitive data, or trigger an irreversible side effect, treat connection-time authorization as insufficient on its own and require per-action evaluation. If the action is genuinely low-risk and idempotent, a coarser control may be acceptable, but document that boundary clearly.
What good looks like: The session is admitted once, but every meaningful tool call is checked against current policy, delegated authority, and the requested resource. The result is narrower privilege, better auditability, and less chance that a stale connection decision becomes a blanket permission grant.
Practitioner takeaway: In MCP, the safe default is to authorize the connection once and the action many times. That keeps transport open without turning session admission into permanent permission.
Related resources from NHI Mgmt Group
- What is the difference between scopes and role-based authorization in MCP?
- What is the difference between scope-based authorization and object-level authorization in MCP?
- What is the difference between user-based permissions and least privilege in MCP workflows?
- What is the difference between per-server consent and enterprise-managed authorization for MCP?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
