API keys in incident chats and tickets: what to investigate

Updated October 4, 2026. The previous version described a constructed fintech incident with precise timestamps, company details, and credential-looking strings as though it had been observed. It also made unsupported claims about monitoring vendors, audit scope, and incident prevalence. This guide removes that story and explains how to investigate a credential found outside a code repository.

What counts as a non-code finding?

A credential can appear in an incident conversation, support ticket, runbook, shared document, or public web page. These are different from a source-code commit, but the same basic questions apply: which value was found, who can access that location, does the value still work, and what can it reach? OWASP lists chat, logs, configuration, and other data stores among the places where machine credentials can leak.

A finding in a private chat is not automatically a public leak. A message in a workspace is not automatically readable by every employee. Check the actual channel, ticket, document, guest access, sharing settings, and retention policy. Do not copy the raw value into another investigation note; record a masked identifier and restrict access to the original.

Separate discovery from exposure and use

First, preserve the source details: object link or identifier, observation time, relevant sharing permissions, and a masked credential reference. Then identify the issuer and owner. If the type supports a safe validity check, confirm the current status; otherwise mark it unverified. Confirm the credential’s permissions with the issuer. The source location alone does not tell you whether an attacker saw or used it.

If the issuer provides request or audit logs, review the period in which the source was accessible. Match activity to expected workloads and note missing log coverage. A source author, ticket reporter, or person who pasted a value may know how it got there, but may not own the live service that uses it.

Contain the key and the source copy

For a sensitive key that may still be valid, coordinate replacement or revocation at the issuer promptly. Update dependent workloads and confirm that the old value is rejected. Then remove or redact avoidable source copies according to the platform’s controls and your organization’s retention rules. Source cleanup does not revoke the key, and revocation does not erase every historical copy.

Prevent repeat exposure by reviewing what your alert templates, debugging output, runbooks, and document-sharing settings actually include. Mask credentials before sharing evidence. Where a system forwards an alert into chat or a ticket, inspect the forwarded payload using a harmless test value; do not assume a vendor’s default filters or a compliance certification cover every custom secret.

What Cremit’s Shadow Key item means

CRE-002 includes an active or manually active credential with a finding in a connected source type other than GitHub, GitLab, or Bitbucket, or an observed external exposure. Slack, Jira, Confluence, and other supported connections can provide such findings when configured and within connector permissions. This is a triage category, not a reconstruction of how a value traveled between systems. A connector that is not enabled or a log system that is not connected is outside that observation. Cremit does not infer that every copy was found or rotate the key automatically.

Questions to close before marking the response complete

Where exactly was the key visible, and to whom? Is the old value now rejected by its issuer? Which workload received a replacement? What do issuer logs show about access, and where are the gaps? Were the approved source copies redacted, and was the path that put the value there corrected? Keep these answers with the finding so a closed ticket means a verified response rather than a deleted message.

Primary sources

OWASP Non-Human Identities Top 10 — Secret Leakage

GitHub Docs — Secret scanning scope

Stripe Docs — API key types and rotation