API Key and Token Service  ·  View 15 of 22  ·  Act 5 · Runtime

Leak to Containment

Five lanes across six stages: who does what between a public commit and a dead key.

Editable source SVG draw.io All views
Leak Detect Confirm Decide Contain Account Outside world Key pushed to public repo Scanner matches prefix Sends candidate string Platform — detection Own repo and log scanners Live-or-not endpoint rate-limited, one bit Anomaly signal new country, new scope Platform — response Resolve kid → tenant Tenant policy revoke | downgrade | quarantine Bulk revocation Feed publish Decision trail what triggered it Data plane Key verifies normally Overlay updated p99 ≤ 10 s Denials counted per kid Customer Webhook: leak_detected Successor key issued Audit export to SIEM Blast radius report Leak to Containment — who does what, in what order Auto-revocation on a confirmed partner match is the default. Auto-revocation on anomaly alone is opt-in, because a false positive here is an outage the customer did not cause. v 1.0 · owner Security Platform Architecture · date 2026-09

Decisions

  • Auto-revocation on a confirmed partner match is the default. Auto-revocation on anomaly alone is opt-in, because a false positive there is an outage the customer did not cause and did not choose.
  • Every automated action is reversible and attributable, with the trigger retained — a customer disputing an auto-revocation gets an answer rather than an apology.

The first lane is the point

  • In the Leak stage the key verifies normally, everywhere, and nothing in the system is wrong. That row is why the prefix format, the partner integration and the propagation SLO are all architecture rather than operations.

Assumptions

  • Leak-to-action p99 ≤ 60 s from partner notification; three partners integrated.
  • Scanner feed silence for 24 hours is itself alerted — a partner integration that has quietly stopped looks exactly like a month with no leaks.