Triple-surface scanning
External breach corpora + internal repos + IdP activity in one view.
Stolen secrets, leaked tokens, weak rotation — caught early.
Credential Exposure monitors three surfaces — external (breach corpora, paste sites, dark web), internal (your code repos, S3 buckets, internal wikis) and identity (your IdP's audit log) — and ranks findings by exposure age × privilege × current activity. A leaked password from a dormant account is low priority; a leaked PAT from a service account active 5 minutes ago demands an immediate page to the on-call engineer.
External breach corpora + internal repos + IdP activity in one view.
Used credentials surface first. Dormant accounts ranked lower.
AWS keys, GitHub tokens, Stripe secrets, Slack webhooks. Pre-commit hooks optional.
Auto-suggested rotation steps tied to your IdP and secret manager.
Continuous monitoring of breach dumps, paste sites and public repositories. No manual checks.
Force rotation on leaked credentials before attackers test them.
Catch long-lived tokens, weak rotation, over-privileged grants.
Pre-commit + post-push detection. Auto-revoke + rotate where possible.
| Sources | Breach dumps, paste sites and public repositories |
| Repo coverage | GitHub, GitLab, Bitbucket, Azure DevOps |
| Detection types | Built-in patterns for cloud, SCM and SaaS tokens, plus custom regex |
| IdP integrations | Okta, Entra, Auth0, Google |
Figures from internal testing; test method and date to be published.
A leaked credential only matters if someone can use it. The SOC's job is to know whether the account exists, what privileges it has, whether it is active and what needs rotating. This block compares Protoxol KEY, the credential exposure module, with five relevant alternatives: three identity exposure services, one identity intelligence provider and one focused on secrets in code repositories. It compares sources, context, response and licensing, not data volume.
Each cell shows the status and the scope. Statuses are explained below the table.
Scroll the table sideways to see every column.
| Criterion | Protoxol KEY (credential exposure) | SpyCloud Workforce Threat Protection | Recorded Future Identity Intelligence | Flare Identity Exposure Management | Constella Hunter DRP / Hunter+ and Intelligence Data API | GitGuardian Secrets Security (Internal and Public Monitoring) |
|---|---|---|---|---|---|---|
| Exposure sources | AvailableBreach dumps, paste sites and public repositories; the overview adds dark web, your repos and your IdP log. | AvailableBreach data with plaintext passwords, infostealer logs, phishing captures and combolists. Pastes and repositories are not described. ↗ | AvailableInfostealer logs, dark web channels, paste sites, database dumps, credential marketplaces and combo lists. ↗ | AvailableStealer logs, dark web, Telegram, paste sites and ransomware leak sites, plus GitHub and package and container registries. ↗ | AvailableSurface, deep and dark web, breaches, paste sites, forums and Telegram, plus infostealer logs. ↗ | AvailableGit repositories, CI/CD, Slack, Teams, Jira, Confluence, containers and public GitHub. It does not describe breach dumps or dark web. ↗ |
| Infostealer logs | Not confirmedThe pages do not mention infostealer logs or stolen session cookies. Needs confirming with the product team. | AvailableLogs with session cookies and device fingerprints. Per-device detail of an infection sits in Endpoint Threat Protection, a separate product. ↗ | AvailableEach exposure carries malware family, host details, exfiltration timestamp and device information. ↗ | AvailableStealer logs from families such as RedLine, Vidar or Lumma, collected continuously. ↗ | AvailableCovers infostealer logs and stolen session cookies; it cites this as a growing vector in 2025. ↗ | Not confirmedThe pages consulted do not describe infostealer logs; its scope is secrets in code and team tools. |
| Identities and domains monitored | AvailableWatches the audit log of Okta, Entra, Auth0 and Google. How domains and emails are matched to breaches is not described. | AvailableCorporate email domains plus personal accounts that reuse password patterns of corporate ones. ↗ | Depends on setupEmployee and customer credentials. Extra domains are requested through support; new detections typically appear within one business day. ↗ | AvailableCorporate employee credentials and accounts, with a view of the blast radius across connected services. ↗ | AvailableEmployee credentials, corporate domain exposure, executive profiles and brand impersonation. ↗ | Depends on setupWatches public repos of the organisation and its developers, plus company keywords. It does not monitor emails or domains in breaches. ↗ |
| Data freshness | Not confirmedThe page says continuous monitoring with no manual checks, but gives no delay between an exposure appearing and showing up. | AvailablePer its page, breach and phishing data appear within days; infostealer logs within hours to days. ↗ | AvailableThe vendor describes malware logs as real-time intelligence and breaches as data that may be months old. ↗ | AvailableDescribes detection as near real time; does not publish the actual delay from a listing appearing on a market. ↗ | Depends on setupSpeaks of real-time notifications. It does not say how long a new record takes to enter its database. ↗ | AvailableClaims alerts seconds after a secret is published on GitHub. That is the vendor's figure, not measured. ↗ |
| Validation and context | AvailableRanks by age, privilege and current activity, and joins EDR and NDR to see whether the account is in use. It does not test the password. | AvailableShows which employees have exposed passwords, from which source and how recent. Checking it is still valid in your IdP is not described. ↗ | AvailablePassword complexity, authorization URLs, malware details and risk scoring to prioritise high-confidence cases. ↗ | Needs integrationChecks against Microsoft Entra ID whether the exposed password is still valid and maps the blast radius. ↗ | AvailableIdentity Fusion deduplicates, timestamps and verifies each record, and links aliases, emails and threat actors. ↗ | AvailableChecks whether the secret is still live with non-intrusive HTTP calls where possible, and filters false positives by context. ↗ |
| Alerting and remediation actions | AvailableSuggested rotation steps and playbooks from the alert: force a reset, revoke a token or open a ticket. A person approves before anything runs. | AvailablePassword reset, session revocation and conditional access triggers, including automated runs. ↗ | Needs integrationPassword reset, MFA challenge and access restriction, run through the Okta or Entra ID integration. ↗ | Needs integrationPassword reset, session revocation and account lockdown through Entra ID, including outside business hours. ↗ | Needs integrationOne-click remediation through SOAR or IAM tools; it does not detail which actions it runs. ↗ | Depends on licenceRemediation playbooks with Slack, Jira or ServiceNow from the Growth plan; it also notifies the developer involved. ↗ |
| Identity, endpoint and SIEM integration | AvailablePlaybooks tied to Okta, Entra, Auth0 and Google, on the same console as EDR and NDR. Connectors to third-party SIEMs: not detailed. | Needs integrationOkta, Entra ID, Active Directory, SIEM, SOAR and EDRs such as CrowdStrike or Defender, through integrations or SpyCloud Connect. ↗ | Needs integrationOkta, Entra ID, Cortex XSOAR, Splunk, Swimlane and Tines; the trial FAQ also names Microsoft Sentinel. ↗ | Needs integrationEntra ID and Okta, Splunk and Azure Sentinel, Jira, Slack and Teams. EDR is not in the list consulted. ↗ | Needs integrationSOAR, IAM, MDR/XDR and Maltego. It names no specific identity or endpoint products on the page consulted. ↗ | Needs integrationSIEM, ITSM, ticketing and messaging. It does not describe password resets in an IdP or endpoint actions. ↗ |
| Handling of plaintext passwords | Not confirmedThe pages do not say whether plaintext passwords are stored or shown, or who can see them. | Depends on setupThe data includes plaintext passwords; the vendor cites encryption and access controls. Who sees them in your team is not documented. ↗ | Depends on setupOffers password hashes (SHA1, MD5, SHA256, NTLM) for comparison; whether it shows the plaintext password is not stated. ↗ | Not confirmedThe pages consulted do not explain how plaintext passwords are handled or displayed. | Not confirmedThe pages consulted do not explain how plaintext passwords are handled. | Not confirmedThe pages consulted do not explain how detected secrets are stored or displayed. |
| Secrets in repositories | AvailableGitHub, GitLab, Bitbucket and Azure DevOps; built-in patterns for cloud, SCM and SaaS tokens, custom regex and optional pre-commit hooks. | Not confirmedDoes not describe scanning your repositories. API keys and webhooks appear only as a type of recaptured data. | Not confirmedSecret detection in repositories is not described on the Identity Intelligence pages consulted. | Depends on setupTokens in public GitHub, npm, PyPI, RubyGems and DockerHub. Scanning your private repositories is not described. ↗ | Not confirmedSecret detection in code repositories is not described. | AvailableGitHub, GitLab, Azure DevOps (repositorios Git) and Bitbucket; provider-specific and generic detectors; ggshield CLI for pre-commit and pre-push. ↗ |
| API and export | Depends on setupThe platform exports through webhooks, REST and OTEL. There is no KEY-specific API documented. | AvailableDirect API plus SpyCloud Connect, a managed integration service for custom workflows. ↗ | Depends on setupCustom API access on request, per the trial FAQ; scope is not detailed. ↗ | AvailableMentions API endpoints and integrations to bring the data into your workflows. ↗ | AvailableIntelligence Data API meant to embed identity risk in other products, MDR/XDR stacks and investigations. ↗ | AvailableREST API and CLI. The Starter plan caps monthly API calls. ↗ |
| Licensing model | Depends on licenceModule activated separately. Add-on in Team, included in Enterprise and not listed in Starter; priced per protected endpoint by plan. | Depends on licenceBy number of employee or customer accounts protected, or by queries on the investigations API; volume discounts. No public prices. ↗ | Depends on licenceTwo licence types, Employee Credentials and User Credentials; standalone module or part of broader offerings. Price not published. ↗ | Not confirmedNo plans or billing unit are published on the pages consulted; demo or quote required. | Depends on licenceTwo paths: API licensing to build on, and a platform subscription to investigate; channel for MSSPs and resellers. No public prices. ↗ | Depends on licencePer active developer (commits in the last 90 days). Starter free, Growth and Enterprise by quote; full public monitoring is Enterprise. ↗ |
One per product, naming the plan that was compared.
Plan or edition: Enterprise Protection line (the page at /employee-ato-prevention is titled Workforce Threat Protection); the specific edition is not published
SpyCloud Workforce Threat Protection fits when the exposure data itself decides the purchase: breach data with plaintext passwords, infostealer logs and phishing captures, with password reset and session revocation through Okta, Entra ID or Active Directory. It is ahead of Protoxol KEY there, since KEY does not confirm infostealer logs. KEY's difference is operational: the exposure lands in the same console as EDR, NDR and email, and a person approves the rotation. One condition: SpyCloud is licensed by accounts protected and needs a SIEM or SOAR to act in, which is worth settling before buying.
Plan or edition: Intelligence Cloud module; Employee Credentials or User Credentials licences
Recorded Future Identity Intelligence gives an analyst opening an exposure the most useful context: malware family, details of the infected host, exfiltration time and a risk score, plus password hashes for comparison. KEY does not confirm that level of infostealer detail. What KEY does do is look at your own repositories and join the account with EDR and NDR activity. Recorded Future fits if you already work with its Intelligence Cloud or with XSOAR, Splunk or Sentinel. Condition: the two licences, Employee Credentials and User Credentials, cover different cases, and extra domains are requested through support.
Plan or edition: Part of the Threat Exposure Management platform; plans are not public
Flare Identity Exposure Management starts from stealer logs and validates them against Microsoft Entra ID before resetting the password and ending sessions. KEY does not confirm that validation step. Flare also watches public GitHub and package and container registries, but it is not clear that it scans your private repositories, which KEY covers across GitHub, GitLab, Bitbucket and Azure DevOps. It suits teams whose main directory is Entra ID. Condition: its plans are not public and EDR is not among its listed integrations, so you would check the account's endpoint activity in another tool.
Plan or edition: Hunter platform (subscription) or API licence; the edition is not published
Constella stands out for the depth of its identity data: it links aliases, emails and actors, covers infostealers and session cookies, and offers an API to embed the data in other products. It is a wider investigation and digital risk tool than KEY, aimed at large companies, the public sector and MSSPs. For a small team that only wants to know which exposed accounts are in use and rotate them, it may be more than needed, and it describes no repository scanning. KEY sits closer to daily operations: alert, account activity and playbook. Condition: prices and the specific remediation actions are not public.
Plan or edition: Growth (paid) and Enterprise; a free Starter plan exists for up to 25 developers
GitGuardian is the reference if the problem is secrets in code: provider-specific detectors, a check that the secret is still live, scanning of CI/CD, Slack and Jira, and a CLI for pre-commit. It is ahead of KEY in that area. It is not a breach-data service: its pages describe no dumps, infostealers or an employee's account in an IdP, which KEY puts in one view. It suits development teams that already handle incidents in Jira or ServiceNow. Condition: it is billed per active developer, and full public monitoring is Enterprise only, with a limited version in Growth.
The product pages do not mention them, so we cannot claim it. If that is your main case, ask in the demo before deciding. SpyCloud, Recorded Future, Flare and Constella describe them on their pages.
Exposed means it shows up in a dump, a paste or a repository. Compromised means someone can use it now. To tell, you check whether the password is still valid, what privileges the account has and whether it showed recent activity. KEY ranks by privilege and activity; it does not test the password.
It depends on what you cover. GitGuardian covers secrets in code and team tools. KEY adds breaches, paste sites and your IdP log, but for secret detection in repositories GitGuardian documents more. They can run side by side.
KEY is a module activated separately. In the published plans it is an add-on in Team, included in Enterprise and not listed in Starter. Price is calculated per protected endpoint by plan.
Reviewed on October 2, 2026. Reviewed by The Protoxol team.
Protoxol capabilities are based on the current commercial documentation on this site and were not technically validated in this review; anything undocumented is shown as “Not confirmed”. Vendor data comes from each vendor's public documentation on the date shown and may have changed.
It is the continuous check of whether your organisation's credentials, API keys and tokens have shown up where they should not: breach dumps, paste sites, public repositories. When they do, you get an alert tied to the account or asset affected so you can rotate it before someone uses it.
SpyCloud is a dedicated identity-exposure service with its own breach-data collection. KEY is a module of the Protoxol console: its exposures land in the same incident timeline as your endpoint, identity and email events, and the response, such as forcing a password reset or isolating a host, runs from the same place. If you already use SpyCloud, KEY can ingest its alerts as a source.
Yes, when you connect them. KEY watches for secrets committed to the repositories you authorise and alerts on exposed tokens and keys, including in commit history. It does not need write access.
The alert names the account, the source where it was seen and the assets that use it. From there a playbook can force a reset, revoke the token or open a ticket, with a person approving the action.
Thirty minutes. Your environment. The modules that fit. No slideware.