Your Users Can See 100 Jira Projects. Should Claude See All 100?

[#1]

AI assistants like Claude are changing how teams interact with Jira.

Instead of manually searching through projects and issues, users can ask AI assistants to find information, summarize issues, create tickets, and perform other actions on their behalf.

But as organizations connect AI assistants to Jira, a new security question emerges:

Should Claude have access to everything the user can access?

The answer may not always be yes.

Imagine an employee in a large enterprise who belongs to the Engineering group. As part of their role, they have access to 100 Jira projects.

However, not all of these projects contain the same level of information.

Of those 100 projects:

• 80 are regular engineering projects.
• 10 contains confidential product development information.
• 5 are related to security incidents and vulnerabilities.
• 5 contains highly confidential information about upcoming acquisitions and executive initiatives.

The employee may need access to all 100 projects to perform their job.

But the organization may not want Claude to access all of them.

The employee can continue accessing all 100 projects directly in Jira, while Claude should only be able to access the 80 projects approved by the organization.

The organization can also control what Claude is allowed to do within the projects it can access.

                                             

For example, Claude may be allowed to fetch and search information in approved engineering projects but restricted from creating, updating, deleting, or commenting on issues based on the organization's policies.

This creates an important distinction between what a user can access in Jira and what an AI assistant should be allowed to access and do on that user's behalf.

The Problem: Jira Permissions Shouldn't Always Equal AI Permissions

Traditional Jira permissions are designed to control access for human users.

But when an AI assistant is connected to Jira, organizations may want an additional layer of governance.

A user may have legitimate access to sensitive projects because of their role. However, that doesn't necessarily mean an AI assistant should be able to retrieve, summarize, or interact with the same information.

Organizations may therefore want to apply separate AI-specific access policies based on:

• The Atlassian group the user belongs to
• The Jira project Claude is attempting to access
• The operations Claude is attempting to perform (such as creating Jira issues, adding comments, fetching project or space details, deleting issues, or changing ticket status).

This allows organizations to restrict AI access without changing the user's existing Jira permissions.

Consider a few common scenarios.

Engineering Teams

An engineer may have access to 100 projects across the organization.

However, the security team may want Claude to access only approved engineering projects and prevent it from accessing:

• Security vulnerability projects
• Confidential product initiatives
• Acquisition-related projects

The engineer can continue accessing these projects directly in Jira as required for their role, while Claude's access can be restricted based on the user's group and the specific project being accessed.

HR Teams

An HR employee may have access to multiple Jira projects covering recruitment, employee operations, and workforce planning.

However, Claude may only be allowed to access recruitment-related projects while being restricted from sensitive employee relations or confidential HR projects.

The organization can also control which operations Claude can perform within the projects it is allowed to access.

Finance Teams

A finance employee may have access to budgeting, procurement, financial planning, and M&A-related projects.

The organization may allow Claude to access budgeting and procurement projects but prevent AI access to confidential M&A or strategic financial projects.

External Contractors

A contractor may have access to several Jira projects required for their work.

However, the organization may want Claude to access only a specific set of projects while blocking AI access to internal or confidential projects.

In each scenario, the user's Jira permissions remain unchanged.

The organization simply applies a separate layer of controls to govern what AI assistants can access and what operations they can perform on the user's behalf.

The Solution: Claude Governance for Jira

This is where miniOrange Claude Governance for Jira comes in.

The app enables organizations to create a separate access layer for AI assistants like Claude using Atlassian group-based policies.

Instead of relying solely on a user's existing Jira permissions, administrators can define what Claude is allowed to access and what operations Claude can perform based on the user's Atlassian group and the Jira project Claude is attempting to access.

For example:

Engineering Group

• User's Jira access: 100 projects
• Claude's permitted access: 80 projects
• Claude's restricted access: 20 confidential projects

The user can continue working with all 100 projects directly in Jira.

Claude, however, can be restricted from accessing the 20 confidential projects, even if the user has access to them directly in Jira.

The organization can also apply operation-level restrictions within the projects Claude is permitted to access.

For example, Claude may be allowed to fetch and search Jira data in approved engineering projects but restricted from creating, updating, deleting, or commenting on issues.

This allows organizations to keep existing Jira permissions intact while applying a separate AI-specific access layer that controls:

• Which projects Claude can access
• Which operations Claude can perform
• Which operations are allowed for a user based on their Atlassian group
• Which operations are permitted within a specific Jira project

Govern What Claude Can Do in Jira

Project-level access is only one part of AI governance.

Organizations may also want to control what Claude can do with the Jira data it is allowed to access.

Administrators can define policies based on both the user's Atlassian group and the Jira project being accessed.

This means that Claude can be restricted from performing certain operations depending on the group the user belongs to and the specific Jira project Claude is trying to access.

For example, the Engineering group may be allowed to:

• Fetch Jira data
• Search issues
• Create issues
• Add comments

But the organization may choose to block Claude from:

• Updating issues
• Deleting issues
• Performing other restricted operations

The organization can also apply different restrictions depending on the project.

For example, Claude may be allowed to fetch and search data in an approved engineering project but be restricted from creating or updating issues in that project.

For a highly confidential project, Claude may be blocked from accessing the project altogether.

With group and project-based policies, administrators can control operations such as:

• Fetch
• Create
• Update
• Delete
• Comment

This creates a more granular AI governance layer where access and actions can be controlled based on who the user is, which group they belong to, and which Jira project Claude is attempting to access.

Policies are enforced before AI agents can access your organization's Jira data, providing an additional layer of control over AI-driven interactions.

Monitor AI-Driven Jira Activity

As AI assistants become part of everyday workflows, security and Jira teams also need visibility into how AI interacts with organizational data.

miniOrange AI Access Governance for Jira provides detailed audit logs to help administrators track AI-driven activity.

Administrators can gain visibility into:

• AI calls
• Operations performed
• Arguments sent
• Response size
• Request latency

A centralized governance dashboard provides additional visibility into Claude's Jira activity, helping teams monitor AI access and identify potential policy violations or unusual activity.

This gives administrators greater visibility into how AI assistants interact with Jira and helps organizations maintain oversight as AI adoption grows.

Built for Enterprise AI Governance

The goal isn't to take away users' Jira permissions.

It's to create a separate governance layer for AI.

A user may need access to 100 Jira projects to do their job.

Claude may only need access to 80.

And even within those 80 projects, Claude may only need permission to perform specific operations.

By defining AI access policies based on Atlassian groups, restricting project access, and controlling AI operations, organizations can adopt AI assistants while maintaining greater control over sensitive Jira data.

The app is built 100% on Atlassian Forge, with no external server or database, helping keep your data within Atlassian.

Give AI Only the Access It Needs

AI assistants can help teams work faster and get more value from Jira.

But enabling AI shouldn't mean giving AI unrestricted access to everything a user can see.

With miniOrange AI Access Governance for Jira, organizations can take a more controlled approach:

• Keep your users' Jira permissions as they are.
• Define separate AI access policies.
• Restrict Claude from accessing specific Jira projects.
• Control what operations Claude can perform.
• Apply restrictions based on the user's Atlassian group and the project being accessed.

Because when it comes to AI and sensitive enterprise data, access should be intentional, not automatic.

Schedule a demo to learn more about securing Claude's access to Jira.