Three "apps" orbit a central vault, each needing a database credential. In static mode every app is issued one password at start-up and keeps it forever — the grey line to the vault never breaks. In dynamic mode an app instead sends a short request pulse to the vault, the vault mints a brand-new username/password pair on the spot, and a countdown bar over the app burns down the lease. When the bar hits zero the credential is auto-revoked, the line goes dark, and — after a short pause — the app requests a fresh one. That request → issue → expire → revoke cycle repeats indefinitely.
Simulate leak marks one app's current credential as stolen by an attacker (red pulsing beam). In static mode that beam never disappears on its own — the password is still valid until a human rotates it by hand, so the exposure clock counts up without limit. In dynamic mode the stolen credential is still bound to its own lease: the moment that lease expires the vault revokes it automatically, and the attacker's access is cut regardless of whether anyone noticed the leak.
exposure_static = now − leak_time (unbounded)
exposure_dynamic = min(now, lease_expiry) − leak_time (bounded by TTL)
- Lease TTL — how long each dynamic credential lives before automatic revocation; shorter TTL means smaller blast radius but more rotation traffic.
- Active leases — number of dynamic credentials currently valid across all apps.
- Rotations issued — cumulative count of fresh dynamic secrets minted since reset.
- Exposure window — how long a leaked credential remains usable by an attacker.
Real-world relevance: this mirrors how HashiCorp Vault (and similar centralized secret stores) replace long-lived hardcoded database passwords with just-in-time, uniquely-scoped credentials — the core reason "dynamic secrets" shrink the impact of a leak from indefinite to a fixed, known window.