Security playbook · AI Employee: Sig

Compromised Credential Response

Attacker window collapsed to minutes

Install this playbookBack to marketplace
The problem

A credential leak is detected — via GitHub secret scanning, HaveIBeenPwned, dark-web monitoring, or a security researcher's disclosure. Every minute between detection and revocation is an attacker window. The manual response — page security, verify the leak, coordinate with the account owner, rotate — takes hours. In that time the attacker is already in.

At a glance
Trigger
Monitor event
Approvals
Security decision on account lock for high-risk accounts
What it does
Writes to your systems
Systems
Okta · Identity · Password vault · EDR
How it feels in production

An hour-by-hour walkthrough.

Sunday 11:47pm. GitHub secret scanning fires: an AWS access key was committed 8 minutes ago to a public repo, then force-pushed away 30 seconds later. The key is still valid. Sunday 11:47pm + 15 sec. Sig receives the alert. Confirms the key is active in AWS IAM. Immediately: rotates the key (new one issued to the same IAM user), disables the leaked key at the API level, and revokes all active sessions using it. In parallel: hunts for API calls made using this key in the past 30 minutes. Sunday 11:47pm + 45 sec. API-usage log shows no unauthorized calls yet (attackers hadn't tried it in the 8 minutes it was public). Sig posts to the security on-call channel: "Leaked AWS key kIA-XXX rotated + revoked. Owner: Priya (eng). No unauthorized usage detected. Full incident details attached." Sig also pages the developer (Priya) with a Slack DM: "AWS key committed to public repo was auto-rotated. New key emailed to you securely. Recommend: never commit real keys again; use `.env` files. Runbook link attached." Monday morning security team reviews: the auto-response resolved the incident in under 60 seconds. Post-mortem written mostly by Sig; team focuses on the developer education loop, not on the rotation itself.
How it works

Step by step.

  1. 01

    Detect credential leak

    Ingest from multiple sources: GitHub secret scanning webhooks, HaveIBeenPwned watchlist, dark-web monitoring feeds, researcher-disclosure email. Every source auto-triggers investigation.

    GitHub · HaveIBeenPwned · Vault monitoring · Threat intel
  2. 02

    Force password reset + MFA re-enrol

    For password leaks: force reset via Okta / Entra, revoke active sessions, require MFA re-enrol on next login. User receives explanation immediately.

    Okta · Microsoft Entra ID · HashiCorp Vault
  3. 03

    Rotate API keys / tokens

    For API key leaks: generate new key, disable old key at the API level (AWS IAM, GitHub, third-party APIs), notify the owning developer with new key delivered securely.

    AWS IAM · GCP IAM · HashiCorp Vault · Vendor APIs
  4. 04

    Kill active sessions

    Invalidate every session using the compromised credential. Session tokens revoked at the SSO layer + at the resource level for anything still holding a live token.

    Okta · Microsoft Entra ID · Vendor APIs
  5. 05

    Hunt for abuse

    Scan logs for API calls or logins using the compromised credential in the exposure window. Any unauthorized access flags as a security incident; unauthorized-access investigation kicks off.

    SIEM · CloudTrail · Application logs
  6. 06

    Notify user + hunt for related

    User notified in Slack / email with what happened + what to do (immediate + long-term). Related credentials (same team, same repo, same access pattern) flagged for proactive rotation.

    Slack · Email · Security queue
Systems and wiring

What you connect to make this run.

GitHub secret scanning

trigger

GitHub webhook for detected secrets. Every commit + force-push scanned; even briefly-exposed keys trigger response.

HaveIBeenPwned · dark-web monitoring

read

Watchlist per company domain. Password leaks trigger reset flows; API key exposures trigger rotation.

Okta · Microsoft Entra ID

write

Password reset, session revocation, MFA re-enrol. Zero-latency response — the compromised session is gone before the user reads the notification.

AWS IAM · GCP IAM · HashiCorp Vault

write

Key rotation via IAM API. Old key disabled at the same time new key is issued — no gap where both are valid.

Slack · Email · Security queue

write

User notification, security-team incident record, escalation for unauthorized-access findings.

What changes

Before and after, honestly.

Time from leak detection to credential revoked
Before
1-24 hours (manual security-team response)
After
Under 60 seconds (automated)
% of leaks with unauthorized-access opportunity
Before
30-50% (attackers exploit the gap)
After
< 5% (revocation faster than attacker automation)
Post-incident audit completeness
Before
Incomplete; timeline reconstruction takes hours
After
Complete; timeline is the automated response log
Developer credentials hygiene improvement
Before
Rare — developers didn't know they leaked
After
Real-time education loop drives measurable improvement quarterly
Related

Playbooks that pair with this one.

Security

Secret & API Key Rotation

The preventive cadence; compromised-response is the reactive backstop.

Security

Anomalous Login

Detects login attempts using the compromised credential; complementary detection.

Security

Security Alert Triage & Context

General-case alert enrichment pattern.

Security

Incident Response Orchestration

If unauthorized access is confirmed, escalates to full incident response.

Frequently asked

Answers about this playbook.

What if the compromised credential is for a critical shared service?

Configurable rotation strategies. For critical shared services, Sig can trigger a coordinated rotation with pre-scheduled maintenance window rather than immediate cutover. Human-in-the-loop required for critical-service rotations.

How does Sig handle vendor API key leaks (not our own)?

Detects via secret-scanning (matches vendor key patterns like sk_stripe, xoxb slack, etc.). Auto-notifies our team + the vendor (if opt-in) with the exposure details. Cannot rotate vendor keys autonomously; provides the developer with the vendor's key-rotation instructions.

What about false-positive detections?

Sig verifies the key is actually active before rotation. GitHub secret scanning has ~5% false-positive rate; verification catches most before they cause user friction.

Can we integrate with our SIEM for detection?

Yes — SIEM correlations feed compromised-credential detection. Anomalous login patterns, impossible-travel signals, unusual API activity all feed the same response playbook.

How is this different from just enabling GitHub secret scanning?

Secret scanning detects; Sig responds. Detection without response is just an alert queue. The auto-rotation + hunt-for-abuse + user-notification chain is what makes the exposure window materially small.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Security playbooks