Guenov Labs
More free tools

Free tool

Is your Jira project leaking?

A guided self-audit of the settings that most commonly expose a Jira Cloud project to the wrong people. Answer each question about your own project, get a plain- language verdict and what to change. This doesn’t connect to Jira — it just asks you the questions and nothing you enter is stored or sent anywhere.

Permission checklist questions
1. Is "Browse Projects" granted to "Any logged-in user" (or a similarly broad group) in this project’s permission scheme?
This is the single most common way a Jira project ends up visible to people who shouldn't see it.
2. Is anonymous or public access enabled for this project?
On Jira Cloud, this means literally anyone on the internet — logged in or not — not just people at your company.
3. If this project holds sensitive issues, are they protected with issue-level security (on top of project access)?
Issue-level security restricts individual issues beyond whatever Browse Projects already allows. It's a Premium/Enterprise feature, for company-managed projects only.
4. Are internal comments and sensitive fields kept out of customer or external view?
Relevant if this is a Jira Service Management project with a customer portal, or any project where some viewers shouldn't see everything.
5. Are Administer Projects and Delete Issues limited to a short, named list of admins?
These two permissions let someone reconfigure the project's own access rules or destroy history — worth a deliberate, named list rather than a broad group.
Summary
0 of 5 questions answered

Answer the questions above to see your results.

Where these come from

Each question is checked against Atlassian’s current Jira Cloud documentation, not general Jira knowledge that can go stale as Atlassian changes the product.

Last verified: . Atlassian changes permission behaviour and UI labels over time — check the sources above if something here looks out of date.

Questions

How do I check who can see a Jira project?
Open Project settings → People and Project settings → Permissions, and look at who holds the Browse Projects permission. That single permission is what decides visibility: anyone granted it, directly or through a group or project role, can see the project's issues. Groups are where surprises hide — a group like jira-software-users can include every licensed person on your site, so granting Browse Projects to it makes the project visible site-wide.
Does this tool connect to my Jira site?
No. It never touches Jira and asks for no credentials. It's a structured set of questions you answer by looking at your own project settings, and your answers stay in your browser — nothing is stored on a server or sent anywhere.
What is the most common Jira permission mistake?
Granting Browse Projects to a broad group rather than to a project role. It's the fastest way to set a project up and the easiest to forget about, and it quietly means every licensed user on the site can read the project — including work for one client being visible to people staffed on another.
Can external clients see my Jira issues?
Only if they have a licensed account with Browse Projects, or the project has anonymous access enabled. Jira Cloud has no free guest or viewer role, so there's no state where an unlicensed client is quietly reading your project — but anonymous access genuinely is public to anyone with the URL, which is the one setting worth checking first.
How often should I audit Jira project permissions?
Any time the shape of the team changes — a client offboards, a contractor's engagement ends, a project is cloned from a template — and on a fixed cadence otherwise, quarterly being a reasonable default. Permission drift comes from accumulated small grants, not one big mistake, so the periodic re-read matters more than the thoroughness of any single audit.

Further reading

External and anonymous access ties directly into a couple of the questions above: Jira guest access in 2026: what’s actually possible.

A free tool by Guenov Labs.