MCP authentication vs authorization: are your controls keeping up?

TL;DR: Atlassian’s Rovo MCP guidance makes clear that successful authentication only proves who connected, not what tool actions can safely execute, while OAuth and API-token paths are governed by different controls and blind spots, according to Permit.io. That distinction matters because runtime authorization, not login success, is what constrains agentic tool calls and blast radius.

NHIMG editorial — based on content published by PermitIO: Authentication vs. Authorization in MCP, with Atlassian Rovo as the example

Questions worth separating out

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.

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.

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.

Practitioner guidance

• 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.
• 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.

What's in the full article

Permit.io's full article covers the operational detail this post intentionally leaves for the source:

• The article breaks down Atlassian Rovo authentication and authorization behaviour across OAuth 2.1 and API-token flows.
• It also explains which admin controls apply to OAuth connections versus token-based connections, including domain restrictions and IP allowlisting.
• The source includes a practical tool-risk table for Jira, Confluence, and Bitbucket actions that teams can use to shape policy.
• It walks through how a gateway can evaluate each call_tool request and produce allow, deny, or approval outcomes.

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

MCP authentication vs authorization: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →