Secret payload
The sensitive text entered by the user, such as passwords, tokens, certificates, private keys, or other confidential handoff notes. This is stored in the Forge Secret Store.
// secret notesSecurity &
Security &
Privacy.
A factual overview of how Secret Notes for Jira & JSM handles sensitive note content, metadata, permissions, retention, and platform boundaries.
// summary
Runs on Atlassian, without an external backend.
Secret Notes is built as an Atlassian Forge app for Jira and Jira Service Management.
HostingHosted on Atlassian Forge infrastructure. No Forge Remote and no external Verdaro Labs app server for secret handling.
Secret storageSecret plaintext is stored in the Atlassian Forge Secret Store. Metadata is stored separately in Forge KVS.
No telemetryNo analytics, advertising trackers, third-party telemetry, or external error-reporting SDKs are used by the app.
Product surfacesAvailable in the Jira issue panel and the Jira Service Management portal request detail panel.
// data processed
What data the app handles
Note metadata
Note title, Jira issue or JSM request reference, Atlassian site/cloud identifier, creator metadata, selected reveal audience, expiry/status information, counters, and metadata-only audit events.
// storage boundaries
Where plaintext is not written
The app is designed to avoid the common problem of secrets being pasted into regular Jira/JSM data surfaces.
Not Jira commentsSecret plaintext is not intentionally written to Jira comments or JSM request replies.
Not Jira fieldsSecret plaintext is not intentionally written to Jira issue fields or custom fields.
Not issue propertiesSecret plaintext is not intentionally written to Jira issue/request properties.
Not normal KVS metadataForge KVS stores note metadata, not the secret plaintext payload.
Not logs or audit eventsAudit events are metadata-only and do not contain the revealed secret value.
Not Verdaro Labs serversThe app does not send secret plaintext to an external Verdaro Labs backend.
// access control
Permission and reveal model
Authorization is enforced server-side in Forge resolvers. The browser UI is not treated as a security boundary for reveal, revoke, visibility, cleanup, or audit decisions.
- Creators can see and revoke their own notes.
- Jira/site admins can reveal and revoke notes from the Jira issue panel.
- Notes can be available to the default issue/request audience, internal users only, or selected users/groups.
- For JSM request notes, reporter and participant checks support portal workflows without returning stakeholder account IDs to the browser.
- Anonymous users are blocked from default reveal access.
// lifecycle
Expiry, deletion, and audit
Read onceRead-once notes require confirmation and are designed to self-destruct after the first reveal.
Time limitsNotes can expire after 24 hours or 7 days. “No expiry” notes remain until revoked, with a 365-day Forge Secret Store TTL backstop.
Manual revokeCreators and Jira/site admins can revoke notes when access should end.
CleanupExpired and destroyed secrets are cleaned up best-effort during normal app operations.
UninstallThe app includes an uninstall handler designed to purge tenant app data when the app is uninstalled, subject to Atlassian platform behavior and backups outside direct app control.
User anonymizationThe app handles Atlassian user anonymization events by scrubbing stored user references in note metadata.
// important boundary
Clipboard and user handling
When a user reveals or copies a secret, that plaintext leaves the protected storage context and becomes visible to that user. If copied, it enters the operating-system clipboard.
Clipboard managers, browser extensions, operating-system sync features, or other tools outside the app may retain clipboard contents. Secret Notes warns users about this boundary, but cannot control software outside the Forge iframe.
// questions
Open supportSecurity or privacy question?
For app security, privacy, or Marketplace review questions, contact Verdaro Labs through the support channel.