Permissions, data and limits
What the app can access, exactly what it stores, retention, and troubleshooting.
Limits and retention
| Item | Value |
|---|---|
| Detection patterns | 165, in 17 categories, plus your own |
| Attachment scanning | Text-based files up to 1 MB, 55 extensions and 24 MIME types |
| Bulk scan | 1,000 issues per scan, processed 50 per batch |
| Findings held in the queue | 500. The oldest are evicted past that, and the eviction is written to the audit log. |
| Dismissals and resolutions held | 1,000, evicted the same way |
| Audit log retention | 90 days, one row per event, no per-day cap |
| Analytics window | 90 days |
| Stored value of a secret | Masked preview (4 characters) plus a one-way SHA-256 hash. Never the value itself. |
Permissions the app requests
| Scope | Why it is needed |
|---|---|
read:jira-work | Read issue fields, comments, change history and attachments in order to scan them, and read the project and field lists the settings screens offer you. |
write:jira-work | Create remediation issues, and apply auto-redaction when you enable it. |
read:jira-user | Resolve the comment author and the person who dismissed a finding — at the moment the screen draws them, not by storing the name. |
storage:app | Store findings, dismissals, configuration and scan progress. The audit log itself is Forge SQL, one row per event. |
report:personal-data | Atlassian's Personal Data Reporting cycle. Once a day the app reports every account ID it holds — on findings, on dismissals and in the audit table — and erases what belongs to an account Atlassian reports as closed. |
The app declares no outbound network access at all. Nothing leaves your Atlassian tenant.
What the app stores
- Findings
- Issue key and summary, the field and its label, the category and pattern, the masked match, a one-way hash for deduplication, the detection time, the comment author where relevant, the linked remediation ticket and its status, and the redaction flag.
- Dismissals and resolutions
- Who actioned a finding, when, the outcome and the reason.
- Configuration
- Enabled categories and rules, your custom patterns, scanning scope, project exclusions, and the tracking project, issue type and priority for created issues.
- Audit log
- App events, one row per event in Forge SQL, for 90 days.
- Scan progress
- The issue list and position of a bulk scan, so it can carry on across invocations.
The privacy policy is the full, authoritative list.
What happens without an active licence
Licensing is enforced, and the line was drawn so that a lapse can never trap you. Two things stop: real-time scanning of new events, and the two actions that make the app do work — Create Issue from a finding, and Start Scan on the Bulk Scan tab. Both buttons are disabled with a tooltip saying why, and a warning banner sits above the tabs.
Everything else stays open, on purpose. You can read every finding you already have, work the queue, dismiss, resolve and restore, read the analytics, read and export the audit log CSV, and change every setting. The bulk-scan status poll and its Reset stay open too, specifically so a licence that lapses mid-scan cannot leave an administrator stranded in front of a job with no way to clear it. Nothing is deleted, and renewing picks up exactly where you were.
Uninstalling
Uninstalling erases what the app holds. A preUninstall handler empties the audit table first — that is the store holding account IDs — then sweeps the key-value store until a pass finds nothing left, working to a 45-second budget and attempting each store even if the other fails. Remediation tickets stay in Jira, because they are ordinary Jira issues.
Troubleshooting
- No findings at all
- Check in this order: the Secret & PII Scanner master switch is on at the top of Scanning Rules; at least one category is on; the project is not excluded; and there is an active licence, without which real-time scanning does not run at all. Remember real-time scanning only covers changes made after the app was installed — run a bulk scan for history.
- New findings stopped appearing, but the old ones are still there
- That is the shape of a lapsed licence: the queue you already have stays fully readable and workable while nothing new is scanned. The banner above the tabs says so.
- The queue seems to have stopped growing
- The findings list holds 500 and the dismissed list 1,000; past that the oldest are evicted. The eviction is recorded in the Audit Log, so check there before assuming the scanner went quiet. Work the queue down, or narrow the categories producing the volume.
- Far too many findings
- Switch off PII — Contact & Network and Generic Keyword Secrets first, then exclude sandbox and training projects.
- A secret in an attachment was missed
- Three conditions: Scan Attachments enabled, file is text-based, file is under 1 MB. Archives, PDFs and images are not read.
- A dismissed finding came back
- Dismissal covers one exact value in one exact place. The same value pasted elsewhere is a new finding, by design. A resolved finding is different: resolving does not suppress the value, so if the secret is still in the issue the next scan finds it again — deliberately, because the point of resolving is that you dealt with it.
- I dismissed the wrong thing
- Open the Dismissed tab and use Restore on that row. It goes back in the queue and the suppression is lifted.
- Auto-redaction removed something it should not have
- The field cannot be un-redacted, but the original text is still in the issue's change history. Disable auto-redaction, dismiss the pattern that caused it, and restore the value from the history.
When you open a ticket, send us the pattern name and the field. Never send the secret itself.