Why can everyone in my company see my Jira project?

If you've just discovered that anyone in your company can open a Jira project you assumed was private, there's one setting that explains it about nine times out of ten.

The Browse Projects permission is granted to "Any logged-in user."

That grant does exactly what it says: every licensed user in your Jira site can see the project. Not your team. Not the department. Everyone with an account. It's a common default, nobody deliberately chose it, and it sits there quietly until the day someone mentions they read your sprint board.

Why this happens

Jira governs who can do what through permission schemes — reusable lists mapping each permission to whoever holds it. Browse Projects is the master visibility switch: hold it, and you can see the project. (If schemes themselves are the part that's confusing, gour permission schemes explainer walks through the whole model.)

Many default schemes grant Browse Projects broadly, on the reasonable assumption that internal transparency is a feature. For a lot of teams it is. For client work, HR, security, finance, or anything confidential, it isn't — and because nothing in the interface announces it, the project looks private until it demonstrably isn't.

How to check and fix it

1. Open the project, then Project settings → Permissions.
2. Find Browse Projects and look at who it's granted to. If you see "Any logged-in user" or "Application access," that's your answer.
3. Change the grant to a specific project role (like Team, or a role you create) or a group.
4. Make sure the right people are actually in that role — Project settings → People.
5. While you're there, scan the other sensitive permissions: Administer Projects, Delete Issues, Manage Sprints. They're often broader than intended too.

If you'd rather work through that audit systematically, the gJira project permission leak checklist covers the same ground in order, including the grants people skip.

The trap when you edit

Permission schemes are shared. The same scheme is frequently attached to many projects, so tightening it for one project silently tightens it for all of them — which may be what you want, or may break access for a team you weren't thinking about.

Before you edit, check which projects use the scheme. If several do and only one needs different rules, copy the scheme, change the copy, and attach it to just that project. It's an extra minute and it avoids a confusing outage.

Use roles, not named users

When you make the change, grant the permission to a project role rather than listing individuals. A role's membership is set per project, so one shared scheme can behave correctly across many projects — Project A's Team role contains Project A's people, Project B's contains Project B's. Granting permissions to named users means editing schemes every time someone joins or leaves, and that maintenance burden is how instances end up with forty near-identical schemes nobody understands.

Related: this isn't the same as anonymous access

Worth separating two things people conflate. "Any logged-in user" means every licensed person in your site. Anonymous access is a different setting entirely, available on paid plans, that makes a project visible to anyone with the URL — no account at all. If you're auditing exposure, check both. Anonymous access is the more serious of the two, and it's genuinely public.

Fix the Browse Projects grant first. It's one dropdown, it takes a minute, and it's the single most common reason a private project isn't.

---

I'm Andrey. I build small, focused apps for Jira at gGuenov Labs, and I write about the parts of Jira that are more confusing than they need to be.