Topic starter
23/06/2026 7:24 pm
TL;DR: In MCP, successful authentication only proves who connected, while real risk sits in what tools can execute in Jira, Confluence, and Bitbucket under existing permissions, according to PermitIO. OAuth and API-token paths also receive different admin controls, so runtime authorization, not login success, is what limits blast radius.
Editorial analysis by NHI Mgmt Group, based on content published by PermitIO: “Authentication vs. Authorization in MCP: What Atlassian Rovo Shows About OAuth, API Tokens, and Tool Calls”.
Key questions
Q: What breaks when MCP authorization is left to individual users?
A: You get fragmented trust, inconsistent policy, and no reliable enterprise audit trail.
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: Where do MCP controls fail in practice when tools can write to enterprise systems?
A: They fail when scope or token validity is treated as the final decision, even though the tool is about to mutate state.
Practitioner guidance
- Separate authentication from execution control Treat successful connection as a prerequisite only, then enforce a distinct authorization decision for every tool call that can mutate Jira, Confluence, or Bitbucket state.
- Classify tool risk by action type Map read, write, merge, and workflow-transition operations to different enforcement rules so that low-risk retrieval does not inherit the same controls as high-risk state changes.
- Constrain API-token paths as standing delegation Review every token-backed connection for account privilege, resource scope, and network boundary assumptions, then remove broad inherited rights that are not needed at runtime.
Bottom line: MCP environments create risk when authentication is mistaken for permission to act, because connected identities can still carry broad operational reach.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:22 am
Authentication and authorization collapse into the same risk conversation when agents can act with existing permissions: In MCP, the real question is no longer whether a principal can connect, but whether it can safely execute a tool call in the moment of action. That shift matters because agentic workflows can turn a successful login into broad operational reach across Jira, Confluence, and Bitbucket. Practitioners should treat connected identity as a prerequisite, not as evidence of control.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How do teams decide who is accountable for MCP server access and tool use?
A: Accountability should follow the control layer. Identity teams own user and group authorisation at the IdP, platform teams own gateway enforcement and observability, and application owners own the permissions exposed by the server. If those roles are not written down, no one can explain why a request was allowed.
👉 Read our full editorial: Authentication vs authorization in MCP: what Rovo shows