Sentry credentials: Tell Tokens from DSNs and Respond to Leaks

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:

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:

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

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:

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_ and sntrys_ 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

1. Classify the value. Prefix sntryu_ or sntrys_ identifies itself; a DSN is a URL; a bare 64-hex string needs context (variable name, file, integration config). For sntrys_, decode the payload locally to read the organisation slug, without sending the token anywhere.
2. 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.
3. 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.
4. 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.
5. 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 isActive field) and set a rateLimit on keys that ship to clients. Deleting a client key needs project:admin.
6. Relay keys: regenerate the Relay credentials and re-register the Relay with its upstream.
7. 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.
8. 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.
9. Remove the source and record it using the Secrets Rotation Runbook Template fields.

Hardening baseline

1. Inventory: list organisation tokens, internal integrations and their tokens, and installed integrations; ask owners to list personal tokens used by automation.
2. Move CI to organisation tokens: one per pipeline or use case, named for it, so a revoke breaks one thing.
3. Restrict scopes: for internal integrations grant only the read, write or admin level needed; avoid org:admin and member:admin on automation.
4. 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.
5. 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.
6. 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.
7. 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

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_, reserved sntrya_/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.install and member.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