Exposed API key with an unknown blast radius

The scenario

A support engineer pastes a cURL example into a team chat channel to help a colleague reproduce a customer issue. The example includes a live API key for the internal order service. Six months later the same key is found in three more places: a test fixture that a contractor committed to a public repository, a runbook on the internal wiki and a screenshot attached to a ticket. A secret scanner raises an alert for the repository. The on-call engineer rotates the key, closes the alert and moves on.

Nobody asks what the key could do. It authenticates as order-service-admin, an integration identity created for a migration that finished two years ago. That identity can read every order, issue refunds and export customer records. Rotating the key changes the string. It does not change the fact that an identity with refund authority sat in a public repository for a hundred and forty days, that nobody has checked whether it was used, or that the contractor's fork still holds a copy.

Why it happens

• Credentials travel to wherever work happens. Chat, tickets, wikis, fixtures and screenshots are all places a secret can land, and scanners cover only some of them.
• The alert is about a string, not an identity. Secret detection reports a pattern match; it rarely knows which identity the credential authenticates, who owns it or what it can reach.
• Rotation feels like closure. Replacing the key satisfies the ticket, but it leaves the over-broad identity in place, the stale integration alive and the question of what was accessed unanswered.
• Leakage compounds with longevity. In OWASP's Non-Human Identities Top 10, NHI2, secret leakage, is far more dangerous alongside NHI7, long-lived secrets: a leaked key that never expires gives an attacker all the time they need.

How Trustivan helps

• Map the credential to its identity. The key resolves to order-service-admin, with its creation date, owner of record and the service it authenticates to. Identity is not the credential, and the response has to address both.

  Available

• Correlate every exposure location. Exposures reported to the platform through its ingestion API, from a repository, a ticket or a chat, attach to one credential record, so the response covers every copy rather than the one that fired the alert. Trustivan ships no scanner.

  Available

• Size the blast radius before deciding. The identity graph shows what the identity behind that key can reach, as an upper bound, alongside any activity submitted through the ingestion API since the first exposure.

  Available

• Propose the revocation with the evidence attached. A revocation is proposed from the finding and approved by a second person. Nothing executes it at the provider today, so the key is revoked in the provider console and the platform records the decision.

  Available

• Retire the identity if its purpose is gone. Lifecycle data shows the migration finished two years ago. A decommission can be proposed and approved on that evidence; quarantine inside the platform is what takes effect today, and the gate then denies the identity every action.

  Available

What the evidence looks like

A credential finding has to carry the identity behind the string, or it is just another alert to close. For the order-service key, illustratively:

Related capabilities

• Credential Security — credential metadata, identity mapping, exposure and rotation-overdue findings
• Credential Security — every key the connectors read, tied to an identity, an owner and a blast radius
• Rotation & Expiry — rotation-overdue and expiry findings; Trustivan does not rotate customer credentials
• Blast Radius — what becomes reachable when a credential leaks
• Research: identity is not the credential