Notifications
Clear all
Topic starter
23/06/2026 7:24 pm
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
25/06/2026 3:22 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Authentication vs authorization in MCP: what Rovo shows
