Employee breach exposure console for your security team

Build me an employee breach exposure console that my security team opens every morning. It is a single standing board, not a scheduled report: one row for every email alias on our verified company domain that Have I Been Pwned has seen in a breach, with enough identity context and triage state that the team can work the list top to bottom and pick up where they left off the next day.

On load, call Have I Been Pwned Get Subscribed Domains to find the domains our subscription has verified, and if there is more than one, show a domain picker at the top with the first selected by default. For the selected domain, call Get Breached Email Addresses for a Domain, which returns each breached alias on the domain along with the list of breach names that alias appeared in. That response is the spine of the board: one row per alias.

The domain response only gives breach names, so resolve the details with Get a Single Breach for each distinct breach name across the whole result set, and cache those lookups so a breach shared by fifty people is fetched once. From the resolved breach records fill in each row's breach count, the most recent breach date, and the union of exposed data classes such as passwords, email addresses, phone numbers, or physical addresses.

Add a stealer log column. Call Get Stealer Logs by Email Domain once for the selected domain to find the aliases whose credentials were captured in infostealer logs, and flag those rows prominently, since a captured credential is a live password problem rather than a historical one.

Enrich every row from Okta. Pull the directory once with List Users using a SCIM search rather than making a call per row, and match rows to Okta users on login email. Show whether the person is still active, when they last signed in, and which groups they belong to, using Retrieve User for the per person detail view and List User Groups for group membership. Aliases with no matching Okta user, plus users whose Okta status is deprovisioned or suspended, count as dead accounts.

Separate dead accounts from live ones visually. A breached alias for someone who left the company two years ago is not the same emergency as a breached alias for an active admin, so put dead accounts in their own collapsed section below the live list or clearly de-emphasize them, and keep them out of the default risk ranking.

The app has to hold triage state itself, in its own storage, keyed by email alias so it survives reloads and page navigation and is shared across everyone on the team. Each row carries a status of New, Investigating, Password Reset, or Dismissed, an owner, and a free text notes field. Status and owner are editable inline from the row, notes from the row detail panel. Rows that appear for the first time on a later refresh default to New, and refreshing breach data must never overwrite triage state a teammate has already set.

Let people act straight from the row. Give each live row an Okta Expire User Password action that forces a password change at next sign in, and a Suspend User action that blocks sign in, both behind a confirmation step that names the person, and both disabled for dead accounts. After a successful password expiry, offer to move that row's status to Password Reset. Add multi select checkboxes and a button that pushes a summary of the selected rows into our security channel with the Slack Bot Send a Message operation, formatted as a readable list showing each person's alias, risk level, breach count, stealer log flag, Okta status, and current triage status and owner.

Put a Build remediation brief button on each person that kicks off a background agent for that one alias. The agent pulls their full history with Get Breaches for Account, Get Pastes for Account, and Get Stealer Logs by Email, reads the underlying breach records with Get a Single Breach so it can say exactly what was exposed in each one, then checks their Okta status, last sign in, and group membership with Retrieve User and List User Groups to work out whether they hold privileged access. It writes a ranked, plain English remediation brief back into the app on that person's row, stored with the row so the whole team can read it later and it survives reloads. The brief should lead with the single most urgent action, then list the specific exposures that justify it, then note anything reassuring such as the account already being deactivated. Show a pending state on the row while the agent runs, and show the finished brief in the row detail panel with the time it was generated and a re-run option.

Rank the default view by real risk rather than raw breach count. A recent stealer log capture is the strongest signal and should float to the top, followed by recent breaches whose exposed data classes include passwords. Weight recency so a password exposure from this year outranks one from 2013. Membership in a privileged Okta group raises the score. Old marketing or mailing list leaks that only exposed email addresses should sink to the bottom even when one person has a dozen of them. Show the computed risk level on each row with a short reason so the ranking is explainable, and let the team re-sort by breach count, most recent breach date, or triage status.

A few API details to respect. The domain endpoints only work on domains verified inside our Have I Been Pwned subscription, so if Get Subscribed Domains comes back empty, show an explanatory empty state telling the admin to verify a domain rather than an error. Treat a 404 from Have I Been Pwned as a clean result meaning no breaches or pastes were found, never as a failure. Request the full breach model rather than the truncated one so the exposed data classes are actually present. The domain search and domain stealer log endpoints have their own lower rate limits, so fetch them once per refresh and cache the results, and surface a friendly retry message on a rate limit rather than a stack trace.