Authentication vs authorization in MCP: what Rovo shows

At a glance

What this is: This analysis shows that MCP authentication does not equal runtime authorization, and that Atlassian’s OAuth and API-token paths create different control expectations for tool calls.

Why it matters: IAM, NHI, and agentic AI teams need to treat MCP as an execution-control problem, because delegated access can mutate Jira, Confluence, and Bitbucket state long after authentication has succeeded.

👉 Read Permit.io's analysis of authentication and authorization in MCP

Context

MCP tool access is a runtime governance problem, not just a login problem. In this model, a client can authenticate successfully and still be far too broad for the actions it can perform across Jira, Confluence, or Bitbucket.

The key identity question is what the connected principal can do after authentication, not whether the handshake succeeded. That matters for NHI governance, because OAuth scopes, API tokens, and service-style credentials all behave differently once tools begin making real changes.

Key questions

Q: How should security teams control MCP tool calls after authentication succeeds?

A: They should enforce a separate runtime authorization decision for each call_tool request, rather than trusting the login event or token scope alone. The control should evaluate the tool, the target resource, the workflow context, and the delegating identity before any write action executes. That is the point where blast radius can still be reduced.

Q: Why do API tokens create more governance risk in MCP deployments?

A: API tokens often behave like standing credentials for non-interactive systems, so they can outlive the business need that justified them. In MCP, that becomes risky when the token can reach broad Jira, Confluence, or Bitbucket rights without a per-call policy gate. The result is persistent authority, not just authenticated automation.

Q: What breaks when teams treat OAuth scope as the final authorization control?

A: They lose the ability to decide whether a specific action is appropriate in the current context. Scope can say a principal may access a class of resources, but it cannot judge intent, change sensitivity, or workflow legitimacy at execution time. That gap is where unauthorized but technically permitted tool actions slip through.

Q: Who should be accountable for risky MCP actions in enterprise environments?

A: Accountability should follow the full delegation chain, not just the token holder. That means the delegating human, the agent or client, the policy owner, and the approver must all be visible in the audit record when a high-impact action occurs. Without that chain, compliance and incident response lose the evidence needed to explain why the action happened.

Technical breakdown

OAuth 2.1 in MCP gives delegated identity, not action control

OAuth 2.1 establishes a delegated session with consent, token validity, and scope framing. In MCP, that is only the first layer. It tells you which principal connected and which broad permissions were granted, but it does not decide whether a specific tool call should edit an issue, rewrite a runbook, or push code. That distinction matters because scope is a coarse capability contract, while runtime authorization must inspect context at the moment of execution. If teams treat token scope as a substitute for business authorization, they end up with a clean authentication story and a weak control story.

Practical implication: Map every MCP tool to a separate runtime decision point instead of trusting OAuth scope as final authorization.

API tokens create standing access unless policy narrows them

API tokens are designed for non-interactive workloads such as CI, backend automation, and service-style clients. That makes them operationally useful, but also structurally different from interactive OAuth flows. A token authenticates a principal, yet it often persists long enough to become standing access unless the surrounding controls are tight. In MCP deployments, that is especially risky because the token may authorize broad write actions across multiple projects, spaces, or repositories. The architecture problem is not the token itself. The problem is assuming token validity equals acceptable operational scope.

Practical implication: Review every API-token path for standing privilege, broad account rights, and missing resource-level constraints.

Runtime authorization belongs at call_tool, not at connection time

The decisive control point in MCP is call_tool, because that is when the system decides whether a specific action should execute. Connection-time checks only establish identity and session legitimacy. They do not evaluate the tool, the target resource, the workflow context, or the business purpose of the request. A policy layer between the client and the MCP server can evaluate those factors on every invocation and return allow, deny, or approval required. That is what turns delegated identity into controlled execution rather than silent authority transfer.

Practical implication: Enforce per-call policy decisions with explicit reason codes before any write-capable tool executes.

NHI Mgmt Group analysis

MCP exposes a runtime authorization gap, not an authentication failure. The article’s central point is that successful authentication in MCP still leaves open the question of what the connected identity can actually do. That shifts the control problem from access to execution, which is where many IAM programmes still lack enforcement depth. The practitioner conclusion is that MCP must be governed as a continuous decision surface, not a one-time trust event.

OAuth scope is a capability envelope, not a business rule. Scope can describe a delegated permission set, but it does not adjudicate intent, resource sensitivity, or workflow legitimacy at the moment of action. That is why broad write access in Jira, Confluence, or Bitbucket becomes dangerous even when the connection looks properly authorised. The practitioner conclusion is to stop treating scopes as final authorisation and to add a runtime policy layer for high-impact actions.

Zero standing privilege is the right design goal for agentic tool use. Long-lived tokens and broad service-account rights are the structural reason MCP becomes risky once tools can mutate production systems. This is the same governance lesson identity teams learned with cloud workloads, now applied to tool execution. The practitioner conclusion is to design for per-call, per-resource, time-bounded authority instead of enduring access.

Runtime decisioning must be tied to the delegation chain. The relevant identity is not just the credential holder but the delegating human, the agent or client, the workflow context, and the target resource. Without that chain, auditors can see token issuance but not why a specific change was allowed. The practitioner conclusion is to make delegated identity traceable from request to effect.

Authentication succeeded is not a control outcome. It is only a checkpoint. In MCP, governance succeeds only when each write-capable action is bounded by explicit policy, auditable context, and resource-specific enforcement. The practitioner conclusion is that teams should measure control quality at tool invocation, not at login.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 38% have no or low visibility into those third-party OAuth connections, which means the control plane is often blind before tool execution even begins.
• That same visibility gap makes runtime governance more important, so teams should compare MCP control design with the Ultimate Guide to NHIs and the delegated-access patterns it addresses.

What this signals

Runtime authorisation will become the differentiator in agentic integrations. As MCP-style tooling spreads, organisations will stop getting value from authentication alone and start being judged on whether they can control actions at call time. The practical shift is toward per-resource policies, tighter evidence capture, and a smaller tolerance for broad standing access in any tool that can change business state.

Delegation chains are now part of the identity perimeter. A connected principal is no longer just a user or service account, but a chain that can include a delegating human, an agent, a workflow, and a target system. Teams that cannot expose that chain in their governance records will struggle to prove why a specific action was allowed, even when the token itself was valid.

Policy enforcement for tool calls is becoming an NHI control problem. The same discipline used to reduce blast radius in service-account governance now has to be applied to AI-era tool execution, where tokens, scopes, and approval paths can diverge. That means identity teams should prepare for more granular resource scoping, stronger audit correlation, and fewer always-on credentials.

For practitioners

• Classify every MCP tool by risk and mutability Separate read-only calls from write paths that can change Jira workflows, Confluence content, or Bitbucket history. Assign stricter control requirements as the business impact rises, and do not let a generic authenticated state stand in for acceptance of operational risk.
• Enforce per-call policy at call_tool Place a policy decision layer between the client and the MCP server so every invocation is evaluated for tool name, target resource, delegating identity, workflow context, and approval need before execution.
• Reduce standing privilege on API-token paths Review service-style credentials for broad account rights, long-lived validity, and unnecessary cross-project reach. Narrow token scope, rotate it aggressively, and remove permissions that are only justified by legacy build patterns.
• Build evidence around action-level decisions Log the delegated human identity, agent or client identity, target resource, policy result, approver when needed, and final execution outcome so compliance teams can reconstruct why a tool call was allowed or blocked.

Key takeaways

• MCP authentication proves identity, but it does not decide whether a tool should execute a risky action.
• API tokens and OAuth scopes can both leave broad authority in place unless runtime policy narrows each call.
• The practical control point is call_tool, where resource scope, intent, and delegation context must be evaluated together.

Key terms

• Runtime authorization: Runtime authorization is the decision made at the moment an action is requested, not when access is first granted. In MCP and agentic systems, it determines whether a specific tool call may execute against a specific resource under the current context, intent, and delegation chain.
• Call tool: Call tool is the execution point where an MCP client asks a server or gateway to perform an action. It is the control moment that matters most for security because identity has already been established and the system must now decide whether this particular action should proceed.
• Standing privilege: Standing privilege is persistent access that remains available without needing a fresh, contextual approval each time it is used. For MCP clients, service accounts, and API-token paths, it creates a broad operational blast radius unless access is narrowed, time-bounded, and monitored tightly.
• Delegation chain: A delegation chain is the sequence of actors involved when one identity authorises another to act, such as a human, an agent, a workflow, and a target system. In governance terms, it is the evidence path that explains who enabled the action and why it was allowed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by PermitIO: Authentication vs. Authorization in MCP, with Atlassian Rovo as the example. Read the original.