2938 Members
Join Permit's SlackWhen Atlassian tells you, explicitly, that MCP clients can perform actions with existing permissions, that is not legal boilerplate. It is the security model speaking plainly. In the Rovo MCP context, a successful connection is not merely "read access to a chatbot." It is the ability for tools to execute real operations in Jira, Confluence, and Bitbucket as the authenticated identity permits. The warning matters because it shifts the question from "Did authentication succeed?" to "What exactly can now be done, where, and by whom?"
The second documented fact sharpens that tension: Atlassian's admin controls treat OAuth and API-token flows differently. In the Rovo administration controls, domain restrictions apply to OAuth-based connections but not to API-token-based connections, which are instead governed through other controls such as IP allowlisting and token scope and account permissions. Put differently, the connectivity fence is not the same fence for every auth method, and architects who assume one uniform perimeter will design blind spots into production.
Put those two facts together and the engineering gap becomes precise, not philosophical. OAuth gives you signed identity, consent, and scope framing. It does not, by itself, decide whether this specific call_tool request should transition this Jira issue in this project right now because an agent inferred it was a good idea. Authentication is a gate; runtime authorization is a referee. In MCP deployments, you need both, or your safest-looking diagram still grants broad, quiet power.
Atlassian's model is refreshingly explicit if you read it closely. Atlassian's authentication and authorization documentation positions OAuth 2.1 as the primary mechanism, especially for interactive, user-driven sessions. The OAuth flow gives you user presence, an auditable consent act, bearer-token validation, and a clear scope envelope across Atlassian products. The OAuth 2.1 configuration guide further clarifies site and cloud context and redirect-domain trust assumptions that are part of safe interactive operation.
API token flows serve a different operational reality. They exist for non-interactive workloads: CI pipelines, bots, backend automation, and service-style clients that cannot stop for browser consent. Atlassian's own admin controls document this as an "advanced" capability and describe that token-based connections bypass OAuth redirect patterns entirely. If you run headless systems, this is often necessary; if you run them casually, it becomes a standing credential with broad implied authority.
The important architectural line is this: both mechanisms authenticate a principal, but neither mechanism alone performs fine-grained, per-resource business authorization at tool invocation time. OAuth tells you "this user/app granted these scopes under this flow." API tokens tell you "this static secret maps to this account/key identity." Neither statement automatically answers "should this agent edit this Confluence page in this space for this workflow run?" That question lives above the handshake layer.
This is why security teams get tripped up by scope language. Scope is often treated as if it were a runtime intent policy. It is not. Scope is a coarse capability contract established at auth time; runtime authorization is a contextual decision at execution time. If your architecture conflates the two, your controls will pass audits at onboarding and fail quietly in operations.
Within the Rovo MCP server settings, Atlassian is direct about the split: domain allowlists govern OAuth-connected tools, while API-token paths do not use domain allowlist validation. That is not a bug; it is the natural consequence of redirect-based trust checks being absent in non-interactive token submission. Engineers should model this as distinct trust channels, not one mechanism with two user interfaces.
A common bad pattern in MCP programs is celebrating a successful OAuth integration as if it completed authorization design. It did not. OAuth was built to let a client obtain delegated access tokens under defined scopes and consent. It was never a system for continuously adjudicating each downstream action against business risk, resource sensitivity, workflow purpose, and human accountability.
The "existing permissions" warning from Atlassian captures this precisely: once connected, tool actions execute within the authority of the underlying identity. If that identity has broad Jira write power, broad write power is what the agent gets to wield. If it has Bitbucket push access across many repositories, that blast radius is available unless you impose a separate control plane. Authentication succeeded; risk containment did not.
The CI example is the one that should make platform architects wince. A service account token used by an agent in release automation has push rights to 50 repositories because "that's how we set up the build org three years ago." The current workflow only needs one repo, but the credential can reach all 50. Nothing about OAuth-style semantics, or token validity in general, will spontaneously narrow that runtime surface. Least privilege does not emerge; it must be engineered.
Read paths and write paths separate here in practical terms. Read operations such as issue lookup or search are often tolerable with auth-plus-scope alone when data classification is controlled and monitoring is strong. Write operations are different because they mutate state and trust: issue transitions can alter incident posture, Confluence edits can rewrite operational truth, and Bitbucket writes can alter supply-chain integrity. Once you cross into write territory, blast radius becomes a first-order design variable, not a nice-to-have.
Calling this a "gap" is not an indictment of Atlassian or OAuth. It is simply the boundary of what scope-based authentication systems were intended to do. If your threat model includes autonomous or semi-autonomous tool use, you need runtime authorization that can evaluate context per call, not just permissions at login. Otherwise you are effectively granting long-lived, broad delegation and hoping the prompts remain well-behaved — which is not a security control.
Before you can enforce smart policy, you need a risk language that maps to actual MCP tools. Many teams skip this and default to a binary: authenticated equals allowed. That shortcut works until the first high-impact write call occurs from an unexpected workflow context. A risk model does not need to be academically complex, but it does need to be explicit and shared by security, platform, and product owners.
Atlassian's MCP surface spans workflows with very different consequences. Some calls retrieve data and are mostly about confidentiality boundaries. Others mutate records, workflows, and code, where integrity and availability risks dominate. Treating these as equivalent is like locking the front door but leaving change-control approvals on a sticky note in the hallway.
A useful classification starts by tying each tool to business impact, then linking impact to required enforcement friction. Low-risk reads may pass with baseline controls and logging. Medium-risk writes might require stricter resource scoping and policy checks. High-risk software-delivery actions should often require explicit approval or tightly constrained automation contexts. The point is to avoid the fiction that "scope granted" is the same as "risk accepted."
| MCP tool / action (illustrative) | Access type | Risk level | Primary risk domain | Why auth alone falls short |
|---|---|---|---|---|
jira_read_issue |
Read | Low | Confidentiality | Usually acceptable with scoped auth and project visibility, but still needs tenant/resource checks |
jira_transition_issue |
Write | Medium | Workflow integrity | Can alter incident, SLA, and delivery state; should be bounded by project key and workflow intent |
| Confluence page edit/create | Write | Medium-High | Document integrity | Can overwrite operational docs, runbooks, and policy text; requires space/page-level constraints |
| Bitbucket push/merge actions | Write | High | Code and supply-chain integrity | Can ship vulnerable or malicious changes; requires repo- and branch-aware enforcement, often approvals |
Once this table exists, policy design becomes concrete. You can require stricter controls as risk rises: narrower resource scope, stronger provenance requirements, approval gates, and better evidence capture. Without classification, every control discussion stays abstract and every outage postmortem sounds surprised.
The decisive enforcement moment in MCP is call_tool. Not the OAuth redirect. Not token parsing. Not "connected successfully" in a setup wizard. Those steps establish who may attempt actions; call_tool is where the system decides whether this action should execute. If you do not enforce there, you are governing identity but not behavior.
This is where a dedicated policy layer becomes necessary in enterprise deployments. Permit MCP Gateway sits between MCP clients and the Atlassian Rovo MCP server and evaluates each tool invocation before execution. It is not a replacement for OAuth; it assumes authentication happened and then performs runtime authorization against policy. Think of it as the difference between checking someone's badge at the building entrance and checking whether they are allowed to open this specific data-center cage at 2:13 a.m.
At this layer, authorization can evaluate composite agentic identity and context: who delegated the work, which agent is acting, what workflow run is in progress, what intent class the request belongs to, what tool is being invoked, and which resource is targeted. For Atlassian operations, "resource" should be concrete: Jira project key (and issue, when relevant), Confluence space and page scope, Bitbucket workspace, repo, and branch context. Broad "Jira allowed" flags are too blunt for agentic execution.
Permit's model makes this operational by binding decisions to a richer identity tuple: delegating human identity, agent identity, workflow context, and intent classification. From that evaluation, policy can return allow, deny, or require just-in-time approval for sensitive calls. That approval outcome can itself be constrained by role, change window, and resource ownership rules rather than ad hoc out-of-band requests.
The security upside is zero standing permissions for agents: no perpetual blanket access waiting to be misused, only narrow grants when needed for a specific tool, resource, and workflow context. This sharply reduces blast radius in the same way ephemeral cloud credentials improved over static keys. We already learned this lesson with infrastructure IAM; MCP tool execution is simply where we must apply it for AI-era integrations.
In practical terms, every call_tool evaluation should include at least these dimensions after authentication succeeds:
That may feel heavyweight compared with "OAuth worked, proceed," but this is exactly the shift from integration convenience to enterprise control.
Most organizations discover too late that authentication logs are not authorization evidence. Token issuance records tell you that a principal obtained access. They do not tell you which high-risk tool calls were attempted, which were blocked, which required approval, or what happened to the target resources. For SOC 2 and ISO 27001 controls around change management and access governance, that distinction is material.
A defensible MCP audit trail needs to follow the action lifecycle, not just the login lifecycle. Each tool invocation should tie together identity, intent, policy, and outcome in one correlated record. If incident response has to reconstruct events across five systems with fuzzy timestamps, you do not have an audit trail; you have a scavenger hunt.
For Atlassian-centered deployments, the minimum useful log shape includes: delegating human identity, agent identity, tool invoked, targeted resource, declared or inferred workflow intent, policy decision (allow/deny/approval), approver identity when relevant, and final execution outcome from the MCP server and product API. This creates a chain of accountability from delegation to effect. It also lets teams prove controls are functioning rather than merely configured.
In mature programs, these records should be immutable, queryable, and linked to governance objects such as change tickets and incident IDs. That is how you answer "who approved this merge through agent tooling?" with precision instead of storytelling. OAuth events remain important, but they are one layer down: access-plane telemetry, not decision-plane evidence.
A good litmus test is simple. If an auditor or forensic investigator asks why a particular write action to Jira, Confluence, or Bitbucket was allowed at that time, can you produce a single record that includes the policy basis and outcome? If not, your architecture authenticated successfully but failed to authorize transparently. The two are not the same thing.
Authentication in MCP establishes who the client is and under what delegated identity or credential it is operating. Authorization decides whether a specific tool action on a specific resource is permitted in the current context. In other words, authentication is identity proof and session legitimacy, while authorization is per-action policy enforcement. In agentic systems, the authorization decision must happen repeatedly at runtime — once per call_tool — not just at connection time.
OAuth 2.1 can be foundational, but by itself it is not sufficient for tool-call security. It provides consent, token validity, and scope boundaries, which are important controls. It does not natively evaluate business intent, workflow context, or resource-specific risk at every call_tool. You still need a runtime authorization layer for high-integrity operations, particularly any write tool that mutates Jira workflow state, Confluence content, or Bitbucket repository history.
Use OAuth for interactive, user-present workflows where consent and user-level delegation are available and desirable. Use API tokens for non-interactive automation, CI/CD, and service-style processes that cannot perform browser redirects. The security posture differs meaningfully: API-token deployments generally require tighter compensating controls around scope, account privilege, network boundaries, and runtime policy checks, because they lack the domain-control guardrails that Atlassian applies to OAuth flows.
Admins should avoid granting broad Jira authority to the underlying identity and then hoping prompts stay narrow. Instead, they should enforce project-level and ideally issue-level authorization at runtime based on tool, workflow, and delegator context. This means policy decisions should explicitly include project key targeting and deny out-of-scope calls even when the credential could technically access them. That approach turns least privilege from a static aspiration into an executable rule at call_tool time.
Each request should be evaluated against delegating human identity, agent identity, tool risk class, targeted resource scope, workflow intent, and time-bound constraints. The policy engine should then produce an explicit allow, deny, or approval-required result with reason codes. This creates deterministic behavior and auditable decisions rather than implicit trust in token scope, and it enables safer automation by constraining what can happen when agent context drifts from original intent.
API tokens can be static, non-interactive credentials, and are often tied to service accounts with broad standing access. They do not carry the same user-consent interaction pattern as OAuth flows and, in Atlassian's model, do not use domain allowlist validation in the same way. That combination can increase blast radius if runtime authorization is weak. The risk is manageable, but only with deliberate scoping, rotation, monitoring, and per-call policy enforcement rather than treating token validity as sufficient authorization.
Zero standing permissions means agents do not retain broad always-on access by default. Access is granted narrowly and just in time for a specific tool invocation, resource, and workflow need, then expires or is withdrawn. This reduces persistent privilege exposure and limits lateral misuse if an agent or credential path is compromised. It is the agentic equivalent of ephemeral infrastructure credentials — a pattern the industry has already validated at scale for cloud IAM.
An OAuth proxy primarily handles token acquisition, validation, and forwarding in the authentication plane. Permit MCP Gateway focuses on runtime authorization decisions for each tool call in the execution plane. It consumes identity context from authenticated sessions but adds policy evaluation over tool risk, resource scope, delegator and agent linkage, and workflow intent. The two address different layers of the security stack and complement each other rather than compete.
Co-Founder / CEO at Permit.io
