Documentation

Keyring — Access Review & Recertification

This page explains how Keyring works, how to install and configure it, how to run an effective-access report and a certification campaign, and gives step-by-step instructions to verify the app's functionality end to end on a test Jira + Confluence Cloud site.

Runs on AtlassianPure ForgeZero external egressRead-only

What Keyring is

Keyring answers a single governance question for every Jira project and Confluence space: who can access this, through which grant — and should they still? It resolves group and role membership into a plain-language effective-access report, then runs recurring certification campaigns in which reviewers attest keep / revoke / exception on each grant and an admin countersigns a signed, checksummed evidence pack.

It is an access-holder review tool intended to help evidence access reviews for frameworks such as SOC 2 CC6.3 and ISO 27001:2022 A.5.18. It is read-only, does not enforce least privilege, and does not auto-revoke access — remediation is produced as a worklist for a human admin to act on.

Architecture

How it works

Keyring is built entirely on Atlassian Forge and runs inside your Atlassian Cloud tenant. The data path has four stages:

Scan

Keyring reads permission and directory configuration — Jira permission schemes, project roles, groups and their members; Confluence space permissions — and stores a normalized snapshot in Atlassian-hosted Forge storage. Scans run daily on a schedule and can also be triggered on demand from the admin page. Large tenants are fanned out asynchronously over a Forge queue so a scan never blocks the UI.

Resolve into effective access

The snapshot is expanded into a per-project / per-space effective-access view: each holder, and the grant chain by which they got in. Object-level grants (issue-security schemes) and context-dependent holders (dynamic roles such as assignee/reporter, and anonymous/public access) are flagged and shown separately rather than silently folded in, so the report never overstates what it can resolve.

Certify

A campaign freezes the current access for a chosen scope and routes it to reviewers, who attest a decision on every grant, sign a completeness affirmation, and hand off to an admin who countersigns on close. Recurring templates carry the campaign forward on a monthly, quarterly, semiannual, or annual cadence.

Evidence & remediation

Closing a campaign materializes an append-only, per-record hashed evidence pack plus a remediation worklist. On a later scan that covers the same scope, Keyring records whether each revoked grant is confirmed absent, still present, or unverifiable.

Zero external egress. Keyring makes no network calls off the Atlassian platform. It reads configuration and writes its findings to Forge storage — nothing is transmitted to Worqflow or any third party. Keyring holds no write scopes; it cannot modify a permission scheme, group, or grant.

Getting started

Installation & setup

From the Atlassian Marketplace listing, choose Get it now / Try it free and select the Jira or Confluence site to install to. Keyring is a single app that provides modules for both products.
Approve the requested read-only permission scopes (listed under Permissions & data) when prompted.
Installation provisions Keyring's Forge storage automatically. No external account, API key, or configuration is required — there is nothing to connect.
Open Keyring Access Review from the admin area (see below) and run your first scan, or wait for the daily scheduled scan to populate reports.

No credentials to provide. Keyring integrates with no third-party software, so there is no external test instance or login to configure. Everything runs against the Atlassian site it is installed on.

Navigation

Where the app appears

Module	Product location	Who sees it
Keyring Access Review (admin)	Jira → Settings → Apps; Confluence → Global settings	Site / space administrators — scans, campaigns, countersign
Keyring Reviews (reviewer)	Jira global page; Confluence global page	All assigned reviewers, including non-admins — attest decisions

The admin console is gated so only administrators can launch scans, create campaigns, and countersign. The reviewer page renders each reviewer only the grants assigned to them, in their own isolated view.

Free feature

Using the effective-access report

Every install — free — gets an exportable effective-access report for each Jira project and Confluence space Keyring can see.

Open Keyring Access Review and run a scan (or use the most recent scheduled snapshot).
Select a project or space. Keyring lists every holder and the grant chain that gives them access, with flagged/separated rows for object-level and context-dependent grants.
Export the report to CSV to hand to a reviewer or attach to a ticket.

The free report is an access inventory, not a signed-off audit record: it carries no reviewer attestations, no completeness affirmation, and no coverage statement. Those come from a campaign.

Paid feature

Running a certification campaign

Create a campaign from the admin page and scope it to a set of projects and/or spaces. Optionally attach a recurring template (monthly / quarterly / semiannual / annual).
Keyring freezes the current effective access for that scope and routes each grant to its reviewer (typically the project lead or space admin).
In Keyring Reviews, each reviewer attests keep, revoke, or keep with a documented exception on every grant, with the grant's last decision shown for context, then signs a completeness affirmation.
An admin reviews the completed attestations and countersigns to close the campaign.
Keyring produces the evidence pack and a remediation worklist (below).

Certification campaigns and the evidence pack are the paid tier, licensed and billed through the Atlassian Marketplace. To exercise paid features during evaluation, enable the app's development/evaluation license via Manage apps. Keyring does not process any payment directly.

Output

The evidence pack

Closing a campaign materializes a two-part evidence pack:

Frozen core — scope, certified grants and their decisions, the exceptions register, self-review disclosures, and a mandatory coverage & limitations statement (what was and was not evaluated).
Post-close addendum — the remediation worklist and, once a later scan covers the same scope, whether each revoked grant is confirmed absent, still present, or unverifiable.

Every record in the pack is append-only and carries a per-record integrity hash, giving a verifiable audit trail. Keyring describes this as a strong hashed audit record — not a cryptographically-guaranteed or "tamper-proof" ledger.

For reviewers & evaluators

Verifying functionality — step by step

The following steps exercise Keyring end to end on a test Jira + Confluence Cloud site. A test site with a few projects/spaces, a couple of groups, and 2–3 users is enough.

Install

Install Keyring on the test site from the Marketplace listing and approve the read-only scopes. Confirm the install completes with no request for any external credential or configuration.

Run a scan

Open Keyring Access Review (Jira Settings → Apps, or Confluence Global settings) and trigger a scan. Confirm it completes and reports a snapshot timestamp.

Read an effective-access report

Open the report for a project or space. Verify it lists the expected holders and, for each, the grant chain (role/group → member). Confirm any dynamic-role or anonymous/public access is flagged separately rather than merged in.

Export CSV

Export the report and confirm the CSV contents match the on-screen report.

Create a campaign

With the evaluation license enabled, create a campaign scoped to one or two targets. Confirm each grant is routed to a reviewer.

Attest as a reviewer

Open Keyring Reviews, record keep / revoke / exception decisions, and sign the completeness affirmation. Confirm a reviewer sees only their assigned grants.

Countersign & close

As an admin, countersign and close the campaign. Confirm the campaign moves to a closed state.

Export the evidence pack

Export the pack and confirm it contains the frozen core (scope, decisions, exceptions, coverage & limitations statement) and per-record integrity hashes. Re-run a scan over the same scope and confirm the addendum records remediation-verification status for revoked grants.

Confirm zero egress & read-only

Review the app manifest / permissions: Keyring requests only read scopes plus storage:app and report:personal-data, declares no external fetch / egress permissions, and therefore cannot alter your permission configuration or transmit data off-platform.

Security

Permissions & data

Keyring requests read-only scopes only, plus app storage and personal-data reporting. It requests no write scopes and no external-egress permission.

Scope	Why
`read:permission-scheme:jira`, `read:permission:jira`, `read:project-role:jira`, `read:issue-security-level:jira`	Resolve Jira permission schemes, roles, and object-level grants into effective access
`read:group:jira`, `read:user:jira`, `read:project:jira`, `read:jira-work`, `read:jira-user`	Expand group/role membership and identify projects and holders
`read:space:confluence`, `read:space.permission:confluence`, `read:group:confluence`, `read:user:confluence`	Resolve Confluence space permissions into effective access
`storage:app`	Store scan snapshots, campaigns, and evidence packs in Atlassian-hosted Forge storage
`report:personal-data`	Support the Personal Data Reporting API for account-holder data included in reports

See the Data & Security and Privacy Policy pages for full detail on data handling and retention.

Help

Support

Questions, issues, or feature requests go through our support portal. We aim to acknowledge every request within the response target published on our Marketplace Support tab.

Open the Keyring support portal →