Keyring

Data & Security

Last updated 5 July 2026

Runs on AtlassianZero egressRead-onlyPure Forge · nodejs22.x

This page describes how Keyring is built and what that means for your data, in plain terms — no marketing language, no rounding up.

Architecture: pure Forge, zero external egress

Keyring has no infrastructure of its own. Every function runs inside Atlassian Forge, on Atlassian's infrastructure, and every byte of data it reads or writes stays inside Atlassian's platform: Forge SQL and the Forge key-value store. There is no Worqflow server, no external database, no analytics beacon, no outbound network call of any kind. This is what makes Keyring eligible for Atlassian's "Runs on Atlassian" designation.

Read-only, by scope

Keyring holds no write scopes on either product. It cannot create, edit, or delete a permission scheme, project role, group, or space permission. Its Jira and Confluence API scopes are all read-scoped:

Product	Scope area	Why it's needed
Jira	Permission schemes, permissions, project roles, projects, issue-security levels, groups, users	Resolve who holds which permission on each project, including via role and group actors
Confluence	Spaces, space permissions, groups, users	Resolve who holds which permission on each space
Both	`storage:app`, `report:personal-data`	Store findings in Forge storage; support Atlassian's Personal Data Reporting API

In Jira's classic scope model this shows up to installers as the broader read:jira-work and read:jira-user scopes, because Jira's permission-scheme and project-role APIs are only exposed at that grant granularity — not because Keyring needs issue content. In practice, Keyring reads and stores only permission and directory configuration. It never reads issue summaries, descriptions, comments, attachments, worklogs, or Confluence page bodies, and none of what it reads is ever transmitted anywhere outside Atlassian.

What's stored, and where

Scan results (permission grants, resolved group membership) and campaign records (attestations, exceptions, completeness affirmations, countersign statements, evidence packs) are stored in Forge SQL, attached to your installation. Settings, scan cursors, and progress markers live in the Forge key-value store. Both are Atlassian-hosted and logically isolated per installation — Worqflow has no standing access to either.

Auth model

Per-product admin gate. The Jira admin console checks live site-admin permission on every request; the Confluence admin console checks admin status the same way. A Jira-only admin cannot read Confluence permission data through Keyring, and vice versa.
Reviewer isolation. A reviewer can only see and act on the campaign items assigned to them — enforced on every request, not just at the UI layer.
License gate. Paid features (campaigns, evidence export) check an active license on every resolver call; without one, campaign data is not returned.

Integrity model — precisely stated

Scan and campaign records are append-only: corrections are recorded as new entries superseding the old one, never as edits or deletes. Each record carries a per-record integrity hash chained to the ones before it, and a snapshot- or evidence-level checksum lets you verify the chain hasn't been altered after the fact.

We describe this deliberately as "append-only with per-record integrity hashes" rather than "tamper-proof" or "cryptographically guaranteed" — the hash chain detects alteration within Keyring's own storage, it is not a cryptographic guarantee against every possible actor, and we don't market it as one.

What Keyring does not claim to do

It does not claim a complete or full permission graph. Object-level grants (issue-security schemes) and context-dependent holders (dynamic roles, anonymous access) are flagged and shown separately, not silently resolved.
It does not enumerate site- or organization-wide administrator access, Confluence page-level restrictions, or dormant/inactive accounts — each is disclosed as not evaluated in every report's coverage statement.
It does not certify individual group-membership appropriateness — only the grant itself.
It does not automatically revoke access, enforce least privilege, or write back to your permission configuration in any way.
It is not SOC 2 compliant or ISO 27001 certified itself, and using it does not make your organization compliant — it is designed to help evidence specific controls (SOC 2 CC6.3, ISO 27001:2022 A.5.18) as one input to your broader program.

Personal Data Reporting & erasure

Keyring implements Atlassian's Personal Data Reporting API, reporting every account-id field it stores about a user across scans, campaigns, and evidence packs. Where Atlassian's erasure workflow is invoked, Keyring anonymizes that user's display name across all of its records — including previously frozen evidence packs — while preserving the underlying decision history.

Reporting a security issue

If you believe you've found a security issue in Keyring, please email briano@worqflow.org or open a ticket via our support portal. We'll acknowledge reports promptly.

See also our Privacy Policy and Terms of Service.

← Back to Keyring