Sentry holds stack traces, request data and release artefacts for your applications, and a leaked Sentry auth token can read that data or change the organisation, while a "leaked" DSN usually cannot read anything at all. Telling the two apart quickly is the first job of any Sentry leak response, followed by working out whether the token belongs to a person, the organisation or an integration, because each one is revoked in a different place by a different role. This guide covers Sentry's credential types and formats, what each reaches, where misuse shows up, the revoke and rotate steps, and the hardening that limits the next exposure. It is for application security, platform and SRE teams that run Sentry SaaS or self-hosted Sentry with CI uploads, integrations and AI tooling connected. The Leaked Credential Response Playbook gives the general process; this page is the Sentry-specific detail.
Key takeaways
- Prefixes settle most cases.
sntryu_is a personal token,sntrys_an organisation token; an unprefixed 64-character hex string may be a legacy token, an internal integration token, an OAuth token or a webhook signing secret. - DSNs are not secrets, but they are not harmless. A DSN only lets someone submit events, yet those events can carry crafted content that people and AI agents later read and act on.
- Personal tokens are the widest blast radius. They reach every organisation and project their owner can reach, and their scopes cannot be edited after creation.
- Organisation tokens are narrow but easy to mint. Any member can create one, owners receive a security email, and only owners and managers can revoke it.
- Internal integration tokens never expire. Each integration can hold up to 20 tokens with custom scopes, so inventory and revoke them deliberately.
How identity and access work in Sentry
People sign in to sentry.io with a password, SSO or two-factor authentication and act through organisation and team roles. Machines use one of three kinds of auth token, or the project's client keys (DSNs) for sending events. Sentry's own token formats page lists what each credential looks like:
| Credential | Format | What it reaches | Lifetime and owner |
|---|---|---|---|
| Personal token | sntryu_ plus 64 hex characters | Any organisation and project its user can reach, limited to the scopes picked at creation | Bound to the user; stops working if the user is removed from the organisation |
| Organisation token | sntrys_ plus a base64 payload and a 43-character suffix, roughly 180 to 250 characters | All projects in one organisation, with a fixed CI-oriented permission set (source maps, releases) | Bound to the organisation; shown once |
| Internal integration token | Unprefixed 64 hex characters | All projects in one organisation, with custom, editable scopes | No automatic expiry; up to 20 per integration |
| Legacy auth token or API key | Unprefixed 64 hex, or 32 hex for legacy API keys | Depends on how it was issued | Treat as long-lived |
| OAuth tokens and client secrets | Unprefixed 64 hex | Scopes granted to a public integration | Access and refresh tokens issued per installation |
| Webhook signing secret | Unprefixed 64 hex | Lets the holder forge webhook payloads that pass signature checks | Per integration |
| Relay keys | 43-character base64 values, often in credentials.json | Authenticate a Relay instance to its upstream | Per Relay |
| DSN (client key) | A URL with a 32-hex public key, such as an ingest host and project ID | Submit events to one project; no read access | Until rotated or deactivated |
Sentry also reserves sntrya_ (user app) and sntryi_ (integration) for future tokens; nothing issues them today, but matching them now future-proofs your scanner. Organisation tokens embed their payload in base64, which includes the organisation slug, so the token itself tells you which organisation to contain.
Admin roles and privileged access
- Owner: full access to the organisation, its data and settings. Owners receive the security email when an organisation token is created and can revoke organisation tokens.
- Manager: full management of teams, projects and membership; can revoke organisation tokens.
- Admin: edits global integrations and manages projects. On Business and Enterprise plans this role can no longer be assigned and is replaced by Team Admin.
- Member and Billing: members can create organisation tokens and personal tokens; billing users manage payment details.
A personal token can never exceed its owner's permissions, so a leaked owner's token with org:admin is the worst case: it can delete the organisation's projects and change membership. Keep the number of owners small, require SSO and 2FA, and give automation organisation or integration tokens rather than an owner's personal token.
Integrations, API tokens and service accounts
Sentry API scopes follow a read, write, admin pattern per resource. The ones that change the response:
| Scope | What a holder can do | After a leak |
|---|---|---|
event:read, project:read | Read issues and events, including stack traces, request data and any personal data or secrets that SDKs captured | Treat as a data exposure; check what your events contain |
org:ci, project:releases | Upload source maps and debug files, create releases and manage code mappings | Check releases and artefacts for tampering |
project:write, project:admin | Change project settings, create or delete client keys and projects | Review client key and project changes |
member:write, member:admin | Invite and remove members | Persistence risk: review invites |
org:write, org:admin | Change organisation settings and integrations, or delete | Treat as organisation compromise |
Sentry recommends a separate token per use case, organisation tokens for CI, internal integrations only when you need wider API access on behalf of the organisation, and personal tokens only for acting as a user. Personal tokens are a poor fit for CI because they break when the person leaves, and the docs note they remain viewable in the UI after creation as legacy behaviour, which widens exposure if an account is compromised. For the general trade-offs see the API Keys vs OAuth Tokens Guide.
Logging and detection
Secret scanning coverage
| GitHub secret type | Scanned in public repos (partner) | Push protection | Validity check |
|---|---|---|---|
sentry_organization_token | Yes | Yes | No |
sentry_personal_token | Yes | Yes | Yes |
sentry_integration_token | No (private with GitHub Secret Protection only) | Yes | No |
sentry_user_app_auth_token | No (private with GitHub Secret Protection only) | Yes | No |
Gitleaks' default rules (checked 28 October 2026) include sentry-user-token, sentry-org-token and an older sentry-access-token rule keyed on the word "sentry". The hard case is the unprefixed 64-hex token: any SHA-256 digest matches that shape, so rely on context. Sentry's documentation lists the strings that appear near real tokens (SENTRY_AUTH_TOKEN, authToken, auth.token, Authorization: Bearer, client_secret), and warns that the Sentry-Hook-Signature header is a digest, not the secret. Exclude DSNs from secret rules to keep noise down. The Developer Secret Scanning Triage guide covers tuning.
Audit log events to watch
Sentry's organisation audit log records administrative actions. Event names from Sentry's source code that matter for credential incidents:
| Concern | Audit event |
|---|---|
| New or removed organisation token | org-auth-token.create, org-auth-token.remove |
| Integration token changes | internal-integration.add-token, internal-integration.remove-token, integration.rotate-client-secret |
| Integrations installed or added | sentry-app.add, sentry-app.install |
| Client key (DSN) changes | projectkey.create, projectkey.change, projectkey.remove |
| Legacy API keys | api-key.create, api-key.edit |
| Membership and SSO | member.invite, member.accept-invite, sso.disable |
| Destructive changes | project.remove, issue.delete, alertrule.remove |
Also watch for surprise releases or source map uploads, sudden event volume on one project (a DSN being abused), and events whose messages contain commands, URLs or "resolution" instructions. The last pattern is not theoretical: researchers showed that crafted error events posted with a public DSN were returned through the Sentry MCP server to AI coding agents, which ran the embedded commands. See the Sentry MCP agentjacking analysis.
Metrics that show it is working
- Mean time to revoke: from scanner alert to token revoked, with a target measured in minutes for
sntryu_andsntrys_findings. - Personal tokens in automation: count of pipelines or services still using a person's token; the goal is zero.
- Integration token age: share of internal integration tokens older than your rotation period.
- Owner and manager count: kept small, reviewed quarterly, with at least one reachable out of hours.
- Events with scrubbed fields: rate of events in which scrubbing removed a secret-like value, which shows whether SDK filtering is improving.
Leak response
- Classify the value. Prefix
sntryu_orsntrys_identifies itself; a DSN is a URL; a bare 64-hex string needs context (variable name, file, integration config). Forsntrys_, decode the payload locally to read the organisation slug, without sending the token anywhere. - Revoke an organisation token under Settings, Developer Settings, Organization Tokens. Only owners and managers can do this, so the on-call runbook must name who holds that role.
- Revoke a personal token from the owner's Personal Tokens page. If the owner is unavailable or compromised, remove the user from the organisation, which stops their personal tokens working there, and disable them at the identity provider.
- Revoke internal integration tokens under Developer Settings for that integration, create a replacement first if the integration must keep running, and redeploy. Rotate the client secret of a public integration if it leaked.
- Handle a DSN exposure in proportion: a DSN in a browser bundle is expected. If you see abuse, create a new client key, ship it, then deactivate the old key (the API's
isActivefield) and set arateLimiton keys that ship to clients. Deleting a client key needsproject:admin. - Relay keys: regenerate the Relay credentials and re-register the Relay with its upstream.
- Review the window: filter the audit log for the events above from the earliest possible exposure, and check releases, source maps, client keys and integrations created in that window.
- Assess data exposure: if the token had
event:read, review what your events contain. Secrets captured in stack frames or request bodies need rotating too, and personal data may trigger privacy obligations. - Remove the source and record it using the Secrets Rotation Runbook Template fields.
Hardening baseline
- Inventory: list organisation tokens, internal integrations and their tokens, and installed integrations; ask owners to list personal tokens used by automation.
- Move CI to organisation tokens: one per pipeline or use case, named for it, so a revoke breaks one thing.
- Restrict scopes: for internal integrations grant only the read, write or admin level needed; avoid
org:adminandmember:adminon automation. - Scrub what Sentry stores: enable server-side data scrubbing and SDK-side filtering so events do not carry passwords, tokens or personal data, which shrinks the impact of any read token leak.
- Protect client keys: one DSN per project and component, rate limits on keys shipped to browsers and mobile apps, and a way to change the DSN without a full app release.
- Treat event content as untrusted: if AI agents read Sentry through MCP, require human approval before commands suggested by tool output run, and keep long-lived secrets out of agent environments. See the MCP Security Guide.
- Test and roll back: create the replacement token, deploy it to one pipeline, confirm uploads succeed, then revoke the old token. Organisation tokens are shown only once, so store the new value in your secret manager immediately.
Small teams can rely on organisation tokens for CI, two owners with 2FA and push protection. Larger organisations should enforce SSO, route Sentry tokens through a secrets manager, forward audit events to the SIEM and review integrations quarterly.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | MITRE ATT&CK |
|---|---|---|---|---|
| Token inventory and ownership | IA-5, AC-2 | PR.AA-01 | A.5.17 Authentication information | T1078 Valid Accounts |
| No tokens in code and CI files | IA-5(7) | PR.DS-01 | A.8.4 Access to source code | T1552.001 Credentials In Files |
| Scopes and roles | AC-6 | PR.AA-05 | A.8.2 Privileged access rights | T1528 Steal Application Access Token |
| Audit events and anomaly review | AU-6, SI-4 | DE.CM-09 | A.8.16 Monitoring activities | T1098.001 Additional Cloud Credentials |
| Event data minimisation | SI-4, AC-6 | PR.DS-01 | A.8.11 Data masking | T1530 Data from Cloud Storage |
Common misconfigurations
- Owner's personal token in CI: organisation-wide admin power tied to one person and invisible to organisation token reviews.
- Panic over DSNs, silence over tokens: teams rotate public DSNs while an unprefixed integration token sits unflagged in a config file.
- Integration tokens forgotten: internal integrations accumulate tokens that never expire and outlive the project that needed them.
- Secrets inside events: SDKs capturing headers or local variables, so a read token becomes a credential harvest.
- Nobody on call can revoke: only owners and managers can revoke organisation tokens, and none are reachable out of hours.
- Agents trusting tool output: AI assistants allowed to run commands that came from event text.
Practitioner checklist
- Keep a Sentry credential table (format, owner, revoke location, role needed) in the on-call runbook.
- Scan for
sntryu_,sntrys_, reservedsntrya_/sntryi_and context-anchored 64-hex tokens; exclude DSNs. - Use organisation tokens for CI, one per use case; no personal tokens in pipelines.
- Review internal integrations and their token counts quarterly; revoke unused tokens.
- Limit owners and managers, enforce SSO and 2FA.
- Alert on
org-auth-token.create,internal-integration.add-token,sentry-app.installandmember.invite. - Enable data scrubbing so events do not contain secrets or unnecessary personal data.
- Rate-limit client keys shipped to clients and keep a DSN rotation path.
- Require approval before AI agents act on instructions found in Sentry events.
Standards and references
- Sentry Docs: Token and Credential Formats
- Sentry Docs: Auth Tokens
- Sentry Docs: Permissions and Scopes
- Sentry Docs: Internal Integrations
- Sentry Docs: Data Source Name (DSN)
- Sentry Docs: Organization and User Management
- GitHub Docs: Supported secret scanning patterns
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
Related NHI Mgmt Group resources: Leaked Credential Response Playbook · Git Secret Scanning Guide · New Relic credentials · Developer Secret Scanning Triage