Scenario Brief
A live Stripe key is exposed in public logs, forcing a tradeoff between forensic visibility and rapid containment.
At 16:45 UTC, a security researcher emails you: your API key for Stripe is visible in your public Datadog logs. The key has full read/write access to your Stripe account — charges, refunds, customer data. You don't know how long the key has been exposed. You don't know if anyone has used it. And it's actively being used in production right now. The pressure is conflicting: security wants immediate containment, payments wants zero checkout disruption, and legal wants a defensible story about customer impact before any external disclosure. You have incomplete evidence in all three directions.
Timeline
- 16:45 UTC: Security researcher reports the exposed key.
- 16:49 UTC: Payments team confirms the key is still serving live traffic.
- 16:53 UTC: Legal asks whether the incident is already reportable.
- 16:55 UTC: Support reports one customer asking about duplicate refunds, but no one has confirmed whether it is related.
Stakeholder Pressure
- Legal: Do we have evidence that customer data was accessed?
- Payments: If you revoke now, checkout will fail until the rollout completes.
- Security: We should assume compromise until proven otherwise. Why is the key still live?
Constraints
- Immediate revocation could break revenue-critical production flows.
- Every minute of delay increases the window for malicious use.
- You do not yet know whether the suspicious activity signal is noise or the first sign of active abuse.
Current Telemetry
Key exposure window
Unknown — logs public for 30+ days
Key permissions
Full read/write (charges, refunds, customers)
Active transactions
~40/min through this key
Unauthorized charges detected
Unknown — not yet checked
Production services using key
3 (payments, subscriptions, webhooks)
Secrets manager
Not in use — key in env vars