Skip to main content
NEW · Blast Radius: a field playbook for leaked API keys on AWS, GCP and Azure

ProductThreat Detection

Found in public. Still usable?

A public location tells you where a credential appeared. It does not tell you whether the key still works. Cremit brings together the location, the latest supported issuer check, and available AWS or GCP permission details so a responder can decide what to do next.

See a demoHow scanning works
  • Threat analyst
  • Security lead
  • Service owner
Public repositoryPublic websiteShared documentAKIA••••••••K7Q2Still valid

Who does the work

The people this feature hands work to, and what each of them does with it.

  • Threat analyst

    Triages keys found on public surfaces and separates still-valid ones from dead ones.

  • Security lead

    Escalates a valid public key to an incident with an owner and a priority.

  • Service owner

    Contains the key at the issuer and checks access logs for use.

One finding, three different questions

Treat each piece of evidence as a separate answer before assigning an incident.

  1. 01

    Where was the credential found, and was that source public?

  2. 02

    Was its validity checked at the issuer? When, and with what result?

  3. 03

    For supported AWS or GCP keys, what identity, policies or API restrictions are available?

  4. 04

    Who can contain the exposure and rotate or revoke the key at its issuer?

Cremit threat investigation: location, validity, scope and response
The real product interface, shown with a fictional sample organization.

Read the evidence in order

Location, validity and permission data answer different questions. None alone describes the entire incident.

  • LOCATION

    Where it appeared

    Review the source and recorded locations, including whether a scanned source is public.

  • VALIDITY

    Whether it works

    For supported types, inspect the latest issuer-side check and its time. Human-confirmed results are marked separately.

  • SCOPE

    What it may reach

    Where analysis succeeds, inspect AWS key identity and policies or GCP API-key targets and restrictions.

A status needs its basis

The same label can be misread if the verification method and history are left out.

Confirmed active

An issuer check can confirm a supported key is active. A person can also mark a key active after manual review; that is human evidence, not an automated issuer check.

Not yet confirmed

Pending, unverifiable or manual-review-required findings should remain visible. They are not evidence that the credential is safe.

No longer usable

A failed issuer check or manual judgment can mark a key unusable. Without evidence it previously worked, do not describe that status as a completed revocation.

Common questions

Does a public finding mean the key is live?

No. Public exposure and validity are separate checks. For supported types, review the latest issuer result and its timestamp; otherwise confirm manually.

Does a permission view show what an attacker accessed?

No. AWS policy and GCP API restriction data describe available permission context. Actual use requires issuer-side activity logs and investigation.

Will every finding send an immediate alert?

No. Notifications depend on an enabled rule, supported trigger conditions, source timing and the configured channel. Incident actions require an incident workflow.

Hand the finding to the right person

Use the relationship view to confirm source and ownership evidence. Configure a workflow for the signals that merit a response, then verify the issuer-side fix.