Step-by-step walkthrough for Secret Sentinel — install, test detection across AWS, GitHub, Slack, JWTs, Stripe, Anthropic, OpenAI, and more, configure Jira incident escalation, fine-tune with per-type overrides and exclude lists, and set up the Advanced edition's compliance dashboard and custom regex patterns.

Overview

Secret Sentinel automatically detects and redacts leaked credentials inside Atlassian products.

Secret Sentinel is delivered as two separate Forge apps:

Secret Sentinel for Confluence
Secret Sentinel for Jira

Each app works independently within its product. Jira incident creation from Confluence detections is optional and configurable.

Secret Sentinel ships in two editions, Standard and Advanced — detection, redaction, and Jira escalation are identical on both; Advanced additionally unlocks the compliance dashboard and custom regex patterns covered later in this page. See the product page for the full edition comparison.

Important note:
To create Jira incidents from Confluence detections, Secret Sentinel must be installed in both Confluence and Jira on the same Atlassian site (two separate app installations).

Video walkthroughs

If you prefer a guided walkthrough, watch the short demos for each Secret Sentinel app.

▶ Watch the Confluence walkthrough on YouTube:

https://youtu.be/zUqZ_-ziSVg

▶ Watch the Jira walkthrough on YouTube:

https://youtu.be/xYLS7-teg8E

Install the app

Install the relevant Secret Sentinel app(s) from the Atlassian Marketplace and approve the required permissions during installation:

Install Secret Sentinel for Confluence to protect Confluence content.
Install Secret Sentinel for Jira to protect Jira content.
Install both if you want Confluence detections to automatically create Jira incidents.

Confluence: Detecting and redacting secrets

Step 1: Create content

Create a Confluence page, comment, or inline comment and paste the following content.

# Deployment notes

Database connection:
password=SuperSecret123

AWS access:
AKIA1234567890ABCDEF

GitHub token:
ghp_a1B2c3D4e5F6g7H8i9J0k1L2m3N4o5P6q7R8

Slack bot token:
xoxb-1234567890-abcdef123456

JWT example:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMzQ1fQ.ZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5

This one should be ignored:
password=changeme

End of document.

Save the page or comment.

If this is an inline comment, make sure to update and save the page itself.

Step 2: Refresh the page

Wait a short moment and refresh the page.

Expected result

Detected secrets are automatically redacted in place.

Database connection:
[REDACTED by Secret Sentinel: generic_password_assignment, Supe****t123]

AWS access:
[REDACTED by Secret Sentinel: aws_access_key_id, AKIA****CDEF]

GitHub token:
[REDACTED by Secret Sentinel: github_token, ghp_****q7R8]

Slack bot token:
[REDACTED by Secret Sentinel: slack_token, xoxb****3456]

JWT example:
[REDACTED by Secret Sentinel: jwt, eyJh****Q0o5]

This one should be ignored:
password=changeme

End of document.

Note the bare AWS access key ID above: on its own (no paired secret key nearby) it’s flagged at medium severity, not high — it’s a public identifier, not exploitable by itself, so it doesn’t trip “Escalate only HIGH severity.” See Severity: what escalates as high-risk for the full model, and paste the full coverage check below to see a paired AWS key (aws_secret_access_key) land at high severity instead.

Full coverage check (optional) — every credential type, one paste

The example above exercises 5 of the 50+ credential types Secret Sentinel detects — enough to prove the mechanism works. If you want to verify every single type yourself in one go, paste this instead (or append it to the same page):

# Full coverage check — every credential type Secret Sentinel detects

Database connection:
password=SuperSecret123

PEM private key:
-----BEGIN PRIVATE KEY-----
MIOU3SLTAJj/XTWdNvZt9aIPg6dpeMhC07ymN7VDmCBcpH2L41vTP1fT6Mkpg4oEBn3QYmTiRbOBndy6Fp6CUpKGj4B44yO4tNwLJpDG+6ya4AC3tLMyECFCDHep8agYxG
-----END PRIVATE KEY-----

AWS access key pair:
aws_access_key_id=AKIAABCDEFGHIJKLMNOP
aws_secret_access_key=abcdEFGHijkl1234abcdEFGHijkl1234abcdEFGH

AWS account reference:
aws_account_id=123456789012

GitHub token:
ghp_a1B2c3D4e5F6g7H8i9J0k1L2m3N4o5P6q7R8

GitLab personal access token:
glpat-AAAAAAAAAAAAAAAAAAAA

Slack bot token:
xoxb-1234567890-abcdef123456

Slack incoming webhook:
https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

JWT example:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMzQ1fQ.ZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5

Basic auth in URL:
https://realuser:[email protected]

npm access token:
npm_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

npm .npmrc auth token:
_authToken=abcdefghijklmnopqrstuvwxyz0123456789AB

Anthropic API key:
sk-ant-api03-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

OpenAI API key:
sk-aaaaaaaaaaaaaaaaaaaaT3BlbkFJbbbbbbbbbbbbbbbbbbbb

Groq API key:
gsk_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Hugging Face access token:
hf_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Grafana Cloud API token:
glc_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Grafana service account token:
glsa_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA_abcdef01

Stripe live secret key:
sk_live_AAAAAAAAAAAAAAAAAAAAAAAA

Stripe test secret key:
sk_test_AAAAAAAAAAAAAAAAAAAAAAAA

Stripe live restricted key:
rk_live_AAAAAAAAAAAAAAAAAAAAAAAA

Stripe test restricted key:
rk_test_AAAAAAAAAAAAAAAAAAAAAAAA

SendGrid API key:
SG.aaaaaaaaaaaaaaaaaaaaaa.bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

Shopify API key:
shpat_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Linear API token:
lin_api_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Notion integration token:
ntn_11111111111AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

1Password service account token:
ops_eyJlbWFpbCI6ImFAYi5leGFtcGxlIiwiayI6IkFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUEifQ==

MongoDB connection string:
mongodb://user:[email protected]:27017/mydb

MySQL connection string:
mysql://user:pass1234@host:3306/mydb

PostgreSQL connection string:
postgresql://user:pass1234@host:5432/mydb

HashiCorp Vault service token:
hvs.AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

HashiCorp Vault batch token:
hvb.AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

HashiCorp Vault recovery token:
hvr.AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Vercel personal access token:
vcp_AAAAAAAAAAAAAAAAAAAA

Vercel integration token:
vci_AAAAAAAAAAAAAAAAAAAA

Vercel app access token:
vca_AAAAAAAAAAAAAAAAAAAA

Vercel app refresh token:
vcr_AAAAAAAAAAAAAAAAAAAA

Vercel AI Gateway API key:
vck_AAAAAAAAAAAAAAAAAAAA

Databricks personal access token:
dapiaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Docker personal access token:
dckr_pat_AAAAAAAAAAAAAAAAAAAAAAAAAAA

Figma personal access token:
figd_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Cloudflare global API key:
cfk_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabcdef01

Cloudflare user API token:
cfut_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabcdef01

Cloudflare account API token:
cfat_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabcdef01

Tailscale API key:
tskey-api-AAAAAAAA-AAAAAAAAAAAAAAAA

Tailscale auth key:
tskey-auth-AAAAAAAA-AAAAAAAAAAAAAAAA

Tailscale client key:
tskey-client-AAAAAAAA-AAAAAAAAAAAAAAAA

Tailscale SCIM key:
tskey-scim-AAAAAAAA-AAAAAAAAAAAAAAAA

Tailscale webhook key:
tskey-webhook-AAAAAAAA-AAAAAAAAAAAAAAAA

This one should be ignored:
password=changeme

End of document.

Expected result — every line redacted:

Database connection:
[REDACTED by Secret Sentinel: generic_password_assignment, Supe****t123]

PEM private key:
[REDACTED by Secret Sentinel: private_key, ----****----]

AWS access key pair:
aws_access_key_id=[REDACTED by Secret Sentinel: aws_access_key_id, AKIA****MNOP]
aws_secret_access_key=[REDACTED by Secret Sentinel: aws_secret_access_key, abcd****EFGH]

AWS account reference:
[REDACTED by Secret Sentinel: aws_account_id, aws_****9012]

GitHub token:
[REDACTED by Secret Sentinel: github_token, ghp_****q7R8]

GitLab personal access token:
[REDACTED by Secret Sentinel: gitlab_token, glpa****AAAA]

Slack bot token:
[REDACTED by Secret Sentinel: slack_token, xoxb****3456]

Slack incoming webhook:
[REDACTED by Secret Sentinel: slack_webhook, http****XXXX]

JWT example:
[REDACTED by Secret Sentinel: jwt, eyJh****Q0o5]

Basic auth in URL:
[REDACTED by Secret Sentinel: basic_auth, http****.com]

npm access token:
[REDACTED by Secret Sentinel: npm_access_token, npm_****AAAA]

npm .npmrc auth token:
_authToken=[REDACTED by Secret Sentinel: npm_auth_token, abcd****89AB]

Anthropic API key:
[REDACTED by Secret Sentinel: anthropic_api_key, sk-a****AAAA]

OpenAI API key:
[REDACTED by Secret Sentinel: openai_api_key, sk-a****bbbb]

Groq API key:
[REDACTED by Secret Sentinel: groq_api_key, gsk_****AAAA]

Hugging Face access token:
[REDACTED by Secret Sentinel: huggingface_token, hf_a****aaaa]

Grafana Cloud API token:
[REDACTED by Secret Sentinel: grafana_cloud_api_token, glc_****AAAA]

Grafana service account token:
[REDACTED by Secret Sentinel: grafana_service_account_token, glsa****ef01]

Stripe live secret key:
[REDACTED by Secret Sentinel: stripe_secret_key_live, sk_l****AAAA]

Stripe test secret key:
[REDACTED by Secret Sentinel: stripe_secret_key_test, sk_t****AAAA]

Stripe live restricted key:
[REDACTED by Secret Sentinel: stripe_restricted_key_live, rk_l****AAAA]

Stripe test restricted key:
[REDACTED by Secret Sentinel: stripe_restricted_key_test, rk_t****AAAA]

SendGrid API key:
[REDACTED by Secret Sentinel: sendgrid_api_key, SG.a****bbbb]

Shopify API key:
[REDACTED by Secret Sentinel: shopify_api_key, shpa****AAAA]

Linear API token:
[REDACTED by Secret Sentinel: linear_api_token, lin_****AAAA]

Notion integration token:
[REDACTED by Secret Sentinel: notion_token, ntn_****AAAA]

1Password service account token:
[REDACTED by Secret Sentinel: onepassword_token, ops_****fQ==]

MongoDB connection string:
[REDACTED by Secret Sentinel: mongodb_connection_string, mong****mydb]

MySQL connection string:
[REDACTED by Secret Sentinel: mysql_connection_string, mysq****mydb]

PostgreSQL connection string:
[REDACTED by Secret Sentinel: postgresql_connection_string, post****mydb]

HashiCorp Vault service token:
[REDACTED by Secret Sentinel: vault_service_token, hvs.****AAAA]

HashiCorp Vault batch token:
[REDACTED by Secret Sentinel: vault_batch_token, hvb.****AAAA]

HashiCorp Vault recovery token:
[REDACTED by Secret Sentinel: vault_recovery_token, hvr.****AAAA]

Vercel personal access token:
[REDACTED by Secret Sentinel: vercel_personal_access_token, vcp_****AAAA]

Vercel integration token:
[REDACTED by Secret Sentinel: vercel_integration_token, vci_****AAAA]

Vercel app access token:
[REDACTED by Secret Sentinel: vercel_app_access_token, vca_****AAAA]

Vercel app refresh token:
[REDACTED by Secret Sentinel: vercel_app_refresh_token, vcr_****AAAA]

Vercel AI Gateway API key:
[REDACTED by Secret Sentinel: vercel_ai_gateway_api_key, vck_****AAAA]

Databricks personal access token:
[REDACTED by Secret Sentinel: databricks_token, dapi****aaaa]

Docker personal access token:
[REDACTED by Secret Sentinel: docker_token, dckr****AAAA]

Figma personal access token:
[REDACTED by Secret Sentinel: figma_token, figd****AAAA]

Cloudflare global API key:
[REDACTED by Secret Sentinel: cloudflare_global_api_key, cfk_****ef01]

Cloudflare user API token:
[REDACTED by Secret Sentinel: cloudflare_user_api_token, cfut****ef01]

Cloudflare account API token:
[REDACTED by Secret Sentinel: cloudflare_account_api_token, cfat****ef01]

Tailscale API key:
[REDACTED by Secret Sentinel: tailscale_api_key, tske****AAAA]

Tailscale auth key:
[REDACTED by Secret Sentinel: tailscale_auth_key, tske****AAAA]

Tailscale client key:
[REDACTED by Secret Sentinel: tailscale_client_key, tske****AAAA]

Tailscale SCIM key:
[REDACTED by Secret Sentinel: tailscale_scim_key, tske****AAAA]

Tailscale webhook key:
[REDACTED by Secret Sentinel: tailscale_webhook_key, tske****AAAA]

This one should be ignored:
password=changeme

End of document.

That’s 50 distinct credential types verified end to end in a single paste — every type this documentation and the product page claim, run directly against the real detection engine, not a curated sample. (One type is deliberately left out of this combined document: GCP service account JSON key files, covered separately below — the rule that catches it requires the entire pasted content to itself be a valid JSON object, which can’t coexist with the rest of this plain-text example. Also not shown: raw AWS private-key .p12 files, which secretlint’s own rule can only verify by reading a real file from disk and can’t be checked from pasted text at all in any Confluence/Jira integration.)

GCP service account key file (separate paste — must be pasted alone)

This one only fires when the entire page or comment content is a valid JSON object shaped like a GCP service-account key file, so paste it by itself, not appended to the example above:

{
  "private_key_id": "abc123",
  "private_key": "-----BEGIN PRIVATE KEY-----\nMIIfakeKeyBody\n-----END PRIVATE KEY-----\n"
}

Expected result: the entire JSON object is replaced with a single redaction marker (gcp_private_key_json) — the match spans the whole key file, not just the private_key field, since a service-account JSON key is only meaningful as a complete unit.

SSH private keys — every common format, one type

“PEM private key” in the full coverage check above uses the generic -----BEGIN PRIVATE KEY----- header, but the same private_key detection covers every common SSH/PEM key format your team is actually likely to paste — legacy RSA/DSA/EC PEM keys and the modern OpenSSH format (ssh-keygen’s default output since OpenSSH 7.8, ~2018) alike. If you specifically want to verify the OpenSSH format:

id_ed25519:
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZWQyNTUxOQAAACBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
-----END OPENSSH PRIVATE KEY-----

Expected result:

id_ed25519:
[REDACTED by Secret Sentinel: private_key, ----****----]

A short placeholder block (e.g. a few xs between the markers) is correctly left alone in every one of these formats — detection checks that the base64 content is actually shaped like a real key, not just that the BEGIN/END markers are present.

Most of this coverage comes from secretlint, the open-source engine Secret Sentinel is built on — but not all of it. A couple of real, common leak shapes aren’t covered by secretlint’s own rules, so Secret Sentinel adds them itself: the JWT detector above is entirely our own (secretlint has no generic JWT rule), and the bare-AWS-identifier detection (the access key ID and account ID shown above, each redacted even without a paired secret) is secretlint’s own AWS rule with an option we deliberately turn on that’s off by default upstream. Both are documented, tested additions on top of the library, not just “we installed a package.”

Confluence: Automatically creating Jira incidents

This step is optional and only required if you want Secret Sentinel to create Jira incidents.

Step 1: Install the Jira app

Ensure Secret Sentinel for Jira is also installed on the same Atlassian site.

Step 2: Configure Jira escalation in Confluence

Open the Secret Sentinel global settings in Confluence and configure:

Jira project where incidents should be created
Issue type
Priority
Default assignee (optional)
Severity rules

Save the configuration.

Note:
These settings apply only to Confluence detections.

Step 3: Trigger a new detection

Repeat the steps from the Confluence section by creating or updating a page or comment with leaked credentials.

Result:

Content is redacted in Confluence
A Jira security incident is created automatically in the selected project

Jira: Detecting and redacting secrets

Secret Sentinel for Jira also protects Jira content directly.

Step 1: Create a Jira work item or comment

Create a Jira work item or add a comment and paste the same test content.

# Deployment notes

Database connection:
password=SuperSecret123

AWS access:
AKIA1234567890ABCDEF

GitHub token:
ghp_a1B2c3D4e5F6g7H8i9J0k1L2m3N4o5P6q7R8

Slack bot token:
xoxb-1234567890-abcdef123456

JWT example:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMzQ1fQ.ZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5

This one should be ignored:
password=changeme

End of document.

Save or update the work item.

Expected result

Secrets are automatically redacted in:

Work item title
Work item description
Comments

Database connection:
[REDACTED by Secret Sentinel: generic_password_assignment, Supe****t123]

AWS access:
[REDACTED by Secret Sentinel: aws_access_key_id, AKIA****CDEF]

GitHub token:
[REDACTED by Secret Sentinel: github_token, ghp_****q7R8]

Slack bot token:
[REDACTED by Secret Sentinel: slack_token, xoxb****3456]

JWT example:
[REDACTED by Secret Sentinel: jwt, eyJh****Q0o5]

This one should be ignored:
password=changeme

End of document.

Want to verify every credential type here too? The full coverage check from the Confluence walkthrough works the same way in a Jira work item or comment — same detection engine either way.

Jira: Automatically creating Jira incidents

Jira detections use a separate configuration.

Step 1: Open Secret Sentinel settings in Jira

Navigate to the Secret Sentinel global settings in Jira.

Step 2: Configure Jira escalation for Jira content

Configure the following fields:

Target Jira project for incidents
Issue type
Priority
Default assignee (optional)

Save the settings.

Important note:
Jira and Confluence configurations are independent.
Enabling Jira escalation in Confluence does not enable it for Jira, and vice versa.

Step 3: Trigger a Jira detection

Create or update a Jira work item or comment containing leaked credentials.

Result:

Content is redacted
A Jira security incident is created automatically

Severity: what escalates as high-risk

Secret Sentinel classifies every finding by real exploitability, not just by which pattern matched — this is what “Escalate only HIGH severity” in the settings screen filters on:

High severity — an actually-usable, complete credential: AWS secret access keys, GCP service account keys, PEM/SSH private keys, GitHub and GitLab tokens, Slack tokens, Stripe/Shopify/SendGrid keys, OpenAI/Anthropic/Groq/Hugging Face API keys, database connection strings (MongoDB/MySQL/PostgreSQL), HashiCorp Vault tokens, and most other service-specific tokens.
Medium severity — an identifier that’s only meaningful paired with something else, such as a bare AWS access key ID on its own, or a generic password=/token= assignment matched by keyword rather than a service-specific format.
Low severity — an identifier with no credential value by itself, such as a bare AWS account ID.

Every finding is redacted regardless of severity. Severity only controls what triggers automatic Jira incident creation when “Escalate only HIGH severity” is turned on — this keeps incident volume proportionate to real risk instead of one incident per low-value match.

Fine-tuning detection: per-credential-type overrides

The settings screen’s “Detection & Rules” tab lets an admin override the default severity and escalation behavior for any individual credential type — for example, treating generic_password_assignment as high severity in a security-sensitive space, or turning off Jira incident creation entirely for a type your team already tracks another way.

Two important invariants:

Redaction is never affected. A detected secret is always redacted, no matter what’s configured here — these overrides only change what triggers a Jira incident.
Per-type escalation overrides win over the global “Escalate only HIGH severity” toggle. If you explicitly mark a type as “always escalate” or “never escalate,” that decision applies regardless of the type’s severity.

This is what makes Secret Sentinel workable at real enterprise scale — teams that get flooded with low-value alerts for one specific credential type can silence just that type, without turning off escalation for everything else.

Reducing noise: escalation exclude list and ignored values

Two complementary tools exist specifically to cut false-positive fatigue without ever weakening redaction:

Escalation exclude list — skip Jira incident creation entirely for specific Confluence spaces, Jira projects, or Confluence comments (matched case-insensitively). Common use case: a documentation space whose whole purpose is to show admins what a leaked secret looks like — content there is still redacted normally, it just never pages anyone. Configured per product, in the same “Exclusions” tab as ignored values below.

Ignored values — mark one specific, exact string as permanently not-a-secret, e.g. a placeholder value reused across your own onboarding docs. Unlike every other override, this is the one exception where redaction itself is skipped, not just escalation — only use it for a value you’re certain isn’t a real credential. The value is hashed immediately on save; Secret Sentinel never stores or displays the plaintext value you’re ignoring.

Both controls apply on top of the full 50+ credential type detection engine and any custom regex patterns (Advanced edition, below) — they narrow what escalates or what counts as a secret at all, never what’s scanned for in the first place.

Compliance dashboard (Advanced edition)

The Advanced edition adds an always-visible compliance dashboard at the top of the settings screen: lifetime detection counts broken down by credential type, severity, and month, rendered as charts. This is built for security and compliance teams that need to demonstrate ongoing monitoring — no digging through Jira incident history or Confluence page history required.

Every value shown is an aggregate total. Redacted secrets themselves are never stored, logged, or displayed anywhere, on the dashboard or otherwise — only counts.

On the Standard edition, the dashboard section shows an example preview with sample data instead of your organization’s real counts, so you can see exactly what upgrading unlocks before you do.

Custom regex patterns (Advanced edition)

Beyond the 50+ built-in credential types, the Advanced edition lets an admin define their own detection rules — useful for an internal API key prefix, a proprietary token format, or any other credential shape specific to your organization that a generic scanner wouldn’t recognize.

Custom patterns are evaluated with RE2, a linear-time regular expression engine, rather than JavaScript’s native backtracking regex engine. This is a deliberate security choice: a native regex with catastrophic backtracking can be written (accidentally or maliciously) to hang indefinitely on certain inputs — a denial-of-service risk known as ReDoS. RE2 guarantees linear-time matching regardless of the pattern, so an admin-authored custom pattern can never stall a scan, however it’s written. One practical consequence: RE2’s syntax doesn’t support backreferences, since those are exactly what makes catastrophic backtracking possible in the first place.

Each custom pattern gets its own label and severity, and participates in the same redaction, per-type override, and Jira escalation pipeline as every built-in credential type.

Architecture highlights

Fully built on Atlassian Forge
Detection engine: secretlint — a maintained open-source secret-scanning project, not a proprietary black box
Backend dependencies:
- @forge/api
- @forge/events
- @forge/kvs
- @forge/resolver
Frontend dependencies:
- @forge/react
- @forge/bridge
- React
No external services
No data leaves Atlassian infrastructure
Covered by a rigorously tested codebase — 370+ automated scenario tests across detection, redaction, and escalation behavior

Documentation – Secret Sentinel

Overview

Video walkthroughs

Install the app

Confluence: Detecting and redacting secrets

Step 1: Create content

Step 2: Refresh the page

Expected result

Full coverage check (optional) — every credential type, one paste

GCP service account key file (separate paste — must be pasted alone)

SSH private keys — every common format, one type

Confluence: Automatically creating Jira incidents

Step 1: Install the Jira app

Step 2: Configure Jira escalation in Confluence

Step 3: Trigger a new detection

Jira: Detecting and redacting secrets

Step 1: Create a Jira work item or comment

Expected result

Jira: Automatically creating Jira incidents

Step 1: Open Secret Sentinel settings in Jira

Step 2: Configure Jira escalation for Jira content

Step 3: Trigger a Jira detection

Severity: what escalates as high-risk

Fine-tuning detection: per-credential-type overrides

Reducing noise: escalation exclude list and ignored values

Compliance dashboard (Advanced edition)

Custom regex patterns (Advanced edition)

Architecture highlights