Skip to content

Warden

Warden User Guide

Confluence Cloud gives you no way to see, across every space, which pages are restricted and to whom, and Jira gives you no single view of who can see each project. Warden inventories both in read-only reports, flags the risky access nobody else catches, and lets you export a compliance snapshot. It never changes a restriction or a permission.

Access Audit report

Every view/edit-restricted page across the site, direct versus inherited, plus red flags — and what changed since the previous scan.

Confluence Settings → Apps → Warden — Access Audit

Red flags

Restrictions that quietly break governance: deactivated user, empty group, orphaned principal — plus stranded pages whose entire audience is now dead.

Top of the report

Restriction changes

What moved between one scan and the next: pages that became restricted or unrestricted, and users or groups added to or removed from a restriction.

Below the report

Jira project access

Who can see each Jira project, and through what — plus the findings an access review looks for. Only where Jira is connected; version 5.0.0 and later.

Jira Settings → Marketplace apps → Warden — Jira Project Access

CSV export

A compliance snapshot for SOC 2 and ISO access reviews.

Bottom of each report

Run a scan

Go to Confluence Settings → Apps → Warden — Access Audit and click Run scan. The scan runs in the background, off the request clock, so large sites don't time out; the report refreshes automatically when it finishes. Warden also re-scans daily to keep the snapshot fresh.

The scan walks every space, finds every view/edit-restricted page, and resolves the users and groups those restrictions name. It also reads folders, so a view restriction set on a page above a folder reaches the pages inside it — and a restriction set on a folder itself is named as the source.

Read the report

Red flags come first — the restrictions that silently break access governance:

  • Deactivated user — a page restricted to a user who has been deactivated.
  • Empty group — a restriction pointing at a group with no members.
  • Orphaned principal — the user or group named in the restriction no longer exists.
  • No live viewer / No live editor — the page-level consequence: every user and group granted view (or edit) is deactivated, empty or deleted, so the page's intended audience is locked out and only site admins can still reach it. This is the one to fix first — a stranded view restriction also strands every page that inherits it.

Since last scan — every scan is compared with the one before it. A banner above the table says how many red flags are new and how many were resolved, and each new finding carries a New marker. From the second scan onwards you read a diff, not the whole inventory again.

Restricted pages lists every restricted page, who can view or edit it, and whether the restriction is set directly on the page or inherited from an ancestor, naming the ancestor it came from. Clicking a page opens it in a new tab so you can fix the restriction in Confluence.

Partial scan. Very large sites are scanned up to a page cap; if it is hit, the report is flagged as partial — a snapshot of the first pages scanned.

What the scan could not see. A page whose restrictions could not be read, a page whose ancestors pass through something Warden cannot follow (a whiteboard, a database, a folder it could not read), and a restriction naming more users and groups than were read are each counted in a banner, never shown as clean. The next scan compares only what both scans saw, so an unreadable page is never reported as fixed.

Restriction changes

Every scan is compared with the one before it, and what moved is kept in a change log below the report: pages that became restricted or unrestricted, and users or groups added to or removed from a restriction, with when Warden saw it. The last 50 scans that found a change are kept, and Export change log CSV gives the full log.

It reports what changed and when Warden saw it — never who made the change (that needs Confluence's own audit log), and a restriction added and removed again between two scans does not show. It fills in from the second scan onwards.

Export the compliance snapshot

Use Export inventory CSV for all restricted pages, Export red-flags CSV for just the findings, or Export change log CSV for the history. The red-flags export carries a New since last scan column, so a quarterly review can start from what changed. Every CSV is UTF-8 with a BOM, so it opens cleanly in Excel and Google Sheets.

Jira project access

Jira project access ships in Warden 5.0.0. If your site runs an earlier version, Confluence Settings → Atlassian marketplace → Manage apps offers the update; because it adds two read-only Jira scopes, an admin approves it once.

Warden is a Confluence app that can also be connected to Jira. The two reports are independent: each has its own admin page, its own scan and its own storage, and no data passes between Jira and Confluence. The Jira report never reads Confluence, the Confluence report never reads Jira, and a site that connects only Confluence sees nothing new.

Connect Warden to Jira

  • When you install Warden from the Marketplace, the install screen asks which Atlassian apps to connect it to — choose Jira as well as Confluence.
  • Already installed? A site or organization admin can add the connection later in Atlassian Administration → Connected apps.

Run the Jira scan

Go to Jira Settings → Marketplace apps → Warden — Jira Project Access: the gear icon at the top right, then Marketplace apps, and Warden is listed in the left sidebar under Apps. (Not Jira apps in the same menu, which lists Atlassian's own products.) Only Jira administrators can open it; anyone else sees Jira administrators only, and the server re-checks that on every request. Click Scan Jira projects; a scan takes a minute or two, and after the first one Warden re-scans daily. Warden reads permission schemes and project roles only — never issues.

For each project the report shows its permission scheme, how Browse projects is granted (for example Role: Member (2 users, 1 group) or Any logged-in Jira user), and how many people, guests and app accounts hold it. Team-managed projects are marked, because they are changed under Project settings → Access rather than in a shared scheme.

Findings

  • Public — no login — anyone on the internet can browse the project.
  • Open to every Jira user — every account with Jira access can browse it.
  • Guests can see it — guest accounts hold Browse projects.
  • Deactivated account in a role — a deactivated account still sits in a project role that grants Browse; reactivating it restores access without anyone deciding it.
  • Granted to a named user — Browse projects granted to one person directly in a scheme, outside groups and roles, so it is invisible from each project's People page.

A permission scheme is shared, so a scheme-level finding appears once per scheme, naming the projects it reaches, instead of once per project. Every scan is compared with the one before (new / resolved).

Limits are shown, not hidden: the first 300 projects are scanned; Jira's permission search counts the first 1,000 accounts of a site, so counts past that show a +; a project that cannot be read is named. Export project access CSV and Export findings CSV are paid, like the Confluence exports.

Try it on your own site

On a site that still uses Jira's defaults there is something to see straight away: Default software scheme grants Browse to any logged-in Jira user, so the first scan shows Open to every Jira user for that scheme, naming every project on it. To see the other findings:

  1. On Jira Standard or above (Jira Free does not allow changing permission schemes), go to Jira Settings → Work items → Permission schemes and grant Browse projects to one named user, then click Re-scan — Granted to a named user appears, marked NEW, and the banner counts 1 new.
  2. Remove that grant and click Re-scan — the finding is counted as 1 resolved.
  3. Deactivate a user who sits in a project role that grants Browse, then re-scan — Deactivated account in a role names the role and project.

On the Confluence side, page restrictions are a Standard-and-above Confluence feature: a site on the Free plan has none, so the report correctly shows Restricted 0 · Red flags 0. On a Standard site, restrict a page to a user and deactivate that user, or to a group and empty the group, then Run scan.

Free vs paid

Free forever

The full Access Audit report — inventory, red flags and change log — and the Jira project access report, view-only, at any team size.

Paid — free up to 10 users

The CSV exports: inventory, red flags, change log, Jira project access and Jira findings. Above 10 users export needs an active license; an admin can start a free trial under Confluence Settings → Atlassian marketplace → Manage apps.

What Warden does not do, by design

  • It is not an audit trail. Warden compares scans, so it can tell you what changed and when it saw it, never who changed a restriction or a permission; that needs Atlassian's own audit log.
  • It is not auto-remediation. It reports and flags; it never changes your restrictions or permissions and does not "guarantee compliance". You act on the evidence.

Troubleshooting

  • Report is empty — run a scan first, and remember the Confluence report lists only restricted pages; a site with no restrictions has nothing to flag. Page restrictions are a Standard-and-above Confluence feature.
  • No Warden page under Jira Settings → Marketplace apps — Warden is not connected to Jira on this site, or the installed version is older than 5.0.0. See Connect Warden to Jira above.
  • Export shows an upgrade prompt — you are above the free tier without an active license. Start a trial as above; viewing the reports stays free.
  • A "Partial" badge appears — a very large site hit the page cap; the snapshot covers the first pages scanned.
  • A deactivated user isn't flagged — the deactivated-user signal is best-effort under Runs-on-Atlassian. The empty-group and orphan flags are exact.
  • A page shows atomic flags but no "No live viewer" — that is correct: at least one live user or group can still see it, so it is not stranded. "No live viewer/editor" fires only when every grantee is dead.

Data & privacy

Warden Runs on Atlassian — no external servers, no egress. Every scope is read-only and in-tenant, including the two Jira scopes used only by the optional Jira report; there is no write scope in the manifest, so Warden cannot modify a restriction or a permission. The snapshots live in Forge storage inside your tenant, and Jira accounts are stored as identifiers only, never names. Full policy: Warden privacy policy.

Support: [email protected]