Skip to content

Warden

Warden Privacy Policy

Warden inventories the page restrictions across your Confluence site and flags the ones that have quietly stopped working, and, where Jira is connected, shows who can see each Jira project. It runs entirely inside your own Atlassian cloud environment, reads restriction and permission metadata rather than page or issue content, and holds no write scope at all.

Effective
3 October 2026
Vendor
Hullara
App
Warden — Access Audit for Confluence
Platform
Atlassian Forge · Runs on Atlassian

Summary

Warden (“the App”) is an Atlassian Forge app that participates in Atlassian's Runs on Atlassian program. It runs entirely inside your Atlassian cloud environment. It does not send your data to Hullara's servers or to any third party — there are no external servers, no analytics calls, and no data egress. The App is read-only: it audits and reports on your page restrictions and, where Jira is connected, on who can see each Jira project; it never changes them.

Data we access

The App reads only the data required to audit page restrictions, using the granted Atlassian scopes — all read-only, in-tenant, on your behalf:

ScopeWhy it is needed
read:space:confluenceEnumerate spaces.
read:page:confluenceWalk the page tree (page id, title, parent). The App does not read page bodies or content.
read:folder:confluenceA folder's id, title and parent, so a restriction set above a folder is traced to the pages inside it.
read:content-details:confluenceRead which pages are view/edit-restricted and to which users or groups, plus whether those users are still active. This is the READ scope for restrictions; read:content.restriction is Atlassian's write scope and the App does not request it.
read:group:confluenceGroup membership, to detect empty groups and orphaned group references.
read:user:confluenceResolve the accounts named in restrictions and detect deactivated or orphaned users.
read:jira-workOnly where your site connects Warden to Jira: each project's permission scheme and grants, and its project roles and who sits in them. The App does not read issues.
read:jira-userOnly where Jira is connected: who holds Browse projects on each project, and whether the accounts in project roles are active. Jira accounts are stored as account ids only, never names.
storage:appStore the scan snapshot.
report:personal-dataReport to Atlassian which accounts the snapshot still caches a display name for, so Atlassian can tell us when one is closed or changed and we can discard our copy. Required by the platform for any app that stores a name alongside an account id.

It reads folders too (id, title and parent only), so a restriction set above a folder is traced to the pages inside it.

Where your site connects Warden to Jira (optional), the Jira project access report also reads each project's key, name and type, its permission scheme and the grants in it, and its project roles and who sits in them; Jira's own count of the accounts that hold Browse projects; and whether the accounts in project roles are active, and people or app accounts. It does not read issues. Display names are read only to show them on the page; they are not stored.

Warden is an administrative audit tool: it reads restriction and permission metadata across the site to produce the reports, and does not read the content of your pages or issues.

Data we store

The App stores a scan snapshot and its configuration in Atlassian-hosted Forge storage, which lives inside your Atlassian cloud environment and inherits its data-residency region. The snapshot contains only what the report shows: the list of restricted pages (page id and title, not page content), the users and groups named in those restrictions (account and group identifiers and names), the direct-versus-inherited relationships, and the red-flag findings.

Only restricted pages are stored, not your whole page corpus.

Next to the snapshot the App keeps a restriction change log: for each scan that found a difference from the one before, which pages became restricted or unrestricted and which users or groups were added to or removed from a restriction — by account and group identifier only, without display names. The log keeps at most the 50 most recent such scans.

Where Jira is connected, the App also stores a Jira project access snapshot: per project its key, name, permission scheme and a count of who holds Browse projects; per finding its kind, the projects or scheme it concerns, the role name and up to 25 Atlassian account identifiers with the true count. It stores no names, email addresses or other profile data for Jira accounts.

We do not copy any of this data outside Atlassian.

Data we do not collect

We do not sell, rent, or share your data. We do not use it for advertising or to train machine-learning models. We do not receive a copy of it — it never leaves your Atlassian tenant. We do not read your page content, and we never modify your restrictions.

Sub-processors

None beyond Atlassian itself, the platform hosting the App. Because the App runs on Atlassian with no egress, no additional sub-processors are involved.

Security

The App inherits Atlassian's platform security controls, including SOC 2 Type II and ISO/IEC 27001, and Atlassian's data-residency options. The audit report is an administrative surface, available to your Confluence site administrators; the Jira project access report is available to Jira administrators only. Both re-check on the server who is asking before returning any data.

Read-only is a fact, not a promise. There is no write scope in Warden's Forge manifest, so the App cannot modify a page restriction even if it were asked to — and any administrator can verify that on the install screen before approving it. The manifest also declares no external permissions and no web triggers, so the restriction data it reads has nowhere to go outside your tenant.

Data retention and deletion

The scan snapshot and configuration are stored only while the App is installed. Uninstalling the App removes the App's stored data from your Atlassian environment.

The Jira project access snapshot holds account identifiers only and is replaced by every Jira scan (daily, once the first scan has run).

Because the Confluence snapshot caches display names for the accounts named in restrictions, the App reports those accounts to Atlassian every week using Atlassian's personal data reporting API. The report goes to Atlassian, in-tenant — nothing is sent to Hullara or to any third party. When Atlassian reports that an account has been closed (erased) or updated, the App immediately discards its cached copy of that person's display name; the row then shows the account identifier alone until the next scan resolves a current name. This is how a right-to-erasure request reaches the App's stored data without you having to ask us.

Children

The App is a business tool and is not directed to children under 16.

Changes

We may update this policy; material changes will be reflected here with a new effective date.

Contact

Questions or data requests: [email protected]