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.
At a glance
What this is: This analysis explains why MCP authentication and authorization are not interchangeable, and shows that tool execution in Atlassian Rovo depends on existing permissions rather than on login success alone.
Why it matters: IAM, PAM, and NHI teams need this distinction because agentic tool calls can mutate Jira, Confluence, and Bitbucket state unless authorization is enforced at execution time, not just at connection time.
Context
MCP authentication can prove who connected, but it does not by itself decide what a tool may do once the session is live. In this article's Rovo example, the governance gap is between identity proof and action control, which is why MCP security has to be treated as an authorization problem as much as an authentication problem.
Atlassian's controls also separate OAuth-based connections from API-token-based connections, which means different trust checks, different blind spots, and different operational risk. For IAM and NHI programmes, the key question is whether permissions are being enforced at the point of tool execution, especially when agentic workflows can act inside Jira, Confluence, and Bitbucket.
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. Individual consent creates access sprawl that is hard to distinguish from sanctioned access, and revocation becomes partial or delayed because no central authority owns the full path from identity to tool access.
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: 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. Write actions can change incident status, documentation, or source code, so the control must sit at execution time and evaluate resource scope, tool risk, and intent together.
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.
Technical breakdown
Why OAuth scope is not runtime authorization
OAuth gives a client delegated identity, consent, and a scope envelope, but it does not evaluate every downstream tool action against current business context. In MCP, that matters because a valid token can still be used for a high-impact write action long after the original login step. Scope is therefore a coarse capability contract, not a per-call policy decision. If teams treat OAuth as the final authorization layer, they will overestimate how much blast radius has actually been reduced.
Practical implication: Treat OAuth as the starting trust signal and enforce separate per-call authorization for every action that can mutate state.
How API tokens change the trust model in MCP
API tokens support non-interactive workloads such as bots, CI pipelines, and backend automation, but they also create a different control shape from OAuth. They bypass redirect-based trust checks and often map to standing account permissions, so the token can inherit broad reach if the underlying identity is not tightly constrained. That makes token scope, account privilege, and network constraints critical. The technical issue is not token use itself, but the assumption that a static credential can safely represent changing runtime intent.
Practical implication: Classify API-token connections as standing delegation paths and constrain them with account scoping, network limits, and explicit runtime policy checks.
Why call_tool is the real enforcement point
In MCP, call_tool is where identity becomes action. Authentication answers who established the session, but call_tool must decide whether this specific request may execute against this specific resource, at this moment, under this workflow. That decision can incorporate delegating human identity, agent identity, tool risk, resource scope, and intent. Without that layer, enterprises are governing access at login time while leaving behavior effectively unbounded at execution time.
Practical implication: Place policy enforcement at call_tool and bind each decision to tool, resource, delegator, and workflow context.
Threat narrative
Attacker objective: The objective is to use legitimate authenticated access to perform higher-impact tool actions than the original workflow should have permitted.
- Entry begins with a successful MCP connection, often through OAuth or an API token that authenticates the principal but does not yet restrict the next action.
- Escalation occurs when the connected identity inherits existing Jira, Confluence, or Bitbucket permissions and uses them to perform write operations beyond the immediate workflow need.
- Impact follows when those actions mutate tickets, documents, or code in ways that expand blast radius, alter operational truth, or affect supply-chain integrity.
Breaches seen in the wild
- Cisco DevHub breach 2024: A misconfigured script left non-public files on Cisco's DevHub; IntelBroker took them and claimed reuse of hard-coded SSH credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Runtime authorization is the decisive control plane for MCP governance: Scope, consent, and token validity are useful, but they were never designed to judge whether a specific write action should proceed in the current workflow context. This is especially true for tools that mutate state, because write power changes workflow integrity, document integrity, and code integrity at once. The practitioner conclusion is simple: if the control is not evaluated at execution time, it is not constraining behavior.
Distinct trust channels require distinct policy models: OAuth and API-token flows are not just two ways to reach the same endpoint. They are different trust paths with different guardrails, which means one uniform perimeter model will always leave blind spots. The implication for identity governance is that access governance must classify the connection method as part of the risk model, not as a transport detail.
Zero standing permissions for MCP agents is now an identity design principle, not a nice-to-have: The article makes clear that standing account rights can be inherited by tool calls unless they are narrowed at execution. That creates a runtime entitlement problem rather than a login problem, and the correct control response is to remove persistent broad access from the agent path. The practitioner takeaway is to design for least privilege at the call, not just at the credential.
MCP authorization is an NHI governance problem with human accountability attached: The article's strongest insight is that delegated AI tooling still sits inside human-owned access structures. Human approvals, agent identities, and workload context all need to be visible in the same decision record if teams want auditability and containment. The field should stop treating MCP as a protocol question and start treating it as an identity lifecycle and authorization problem.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
MCP trust debt: organisations that equate successful connection with safe execution accumulate hidden authority across tool calls. The practical shift is to move governance from session establishment to per-action decisioning, especially where an authenticated identity can edit Jira, Confluence, or Bitbucket content.
What matters next is whether teams can express resource scope and workflow intent at call time. If policy cannot distinguish a harmless read from a state-changing write, then the programme is still operating with a coarse delegation model rather than an executable authorization model.
For practitioners
- 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.
- Bind policy to call_tool context Require each decision to include delegating human identity, agent identity, target resource, and workflow intent before the action is allowed to execute.
- Log the decision plane, not just the login plane Record allow, deny, or approval-required outcomes with reason codes so auditors can reconstruct why a specific tool action was permitted.
Key takeaways
- MCP environments create risk when authentication is mistaken for permission to act, because connected identities can still carry broad operational reach.
- The core control issue is not login success but whether each tool invocation is checked against resource scope, intent, and write risk.
- Practitioners should move policy decisions to execution time and treat OAuth, API tokens, and agent context as separate parts of the trust model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article focuses on authentication proving identity without constraining tool action. |
| NHI-05 — Overprivileged NHI | Existing permissions can let connected MCP identities do more than the workflow needs. | |
| NHI-07 — Long-Lived Secrets | API-token paths behave like static credentials and can widen blast radius. | |
| Recommendation — Use NHI-04 to separate identity proof from runtime tool authorization. Apply NHI-05 to reduce standing access on agent and service identities. Apply NHI-07 to shorten token lifetime and remove persistent credential exposure. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic tool calls can inherit or misuse permissions during execution. |
| Recommendation — Map MCP tool governance to ASI03 and bind each action to explicit privilege checks. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API tokens and OAuth credentials both require lifecycle governance. |
| Recommendation — Apply IA-5 to govern credential issuance, scope, rotation, and revocation. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement Point — Policy Enforcement Point | Runtime authorization requires an enforcement point at the call boundary. |
| Recommendation — Place a policy enforcement point at call_tool so every action is checked before execution. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Static tokens and inherited permissions can support credential abuse and internal reach. |
| Recommendation — Track token abuse and downstream tool movement under TA0006 and TA0008. | ||
Key terms
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- 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 Delegation: Standing delegation is persistent authority that remains available after initial approval or setup. In MCP and NHI governance, it becomes risky when a token or account can keep acting across workflows without fresh contextual checks, because the authority outlives the immediate need.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org