Escaneo triple superficie
Bases de datos de brechas externas + repositorios internos + actividad del IdP en una sola vista.
Secretos robados, tokens filtrados, rotación débil — detectados pronto.
La exposición de credenciales monitoriza tres superficies — externa (bases de datos de brechas, sitios de pegado, dark web), interna (tus repositorios de código, buckets de S3, wikis internas) e identidad (registro de auditoría de tu IdP) — y ordena los hallazgos por antigüedad de la exposición × privilegio × actividad actual. Una contraseña filtrada de una cuenta inactiva es prioridad baja; un PAT (token de acceso personal) filtrado de una cuenta de servicio activa hace cinco minutos exige avisar al ingeniero de guardia de inmediato.
Bases de datos de brechas externas + repositorios internos + actividad del IdP en una sola vista.
Credenciales usadas suben primero. Cuentas dormidas más abajo.
Claves AWS, tokens GitHub, secretos Stripe, webhooks Slack. Hooks pre-commit opcionales.
Pasos de rotación auto-sugeridos atados a tu IdP y secret manager.
Vigilancia continua de volcados de brechas, sitios de pegado y repositorios públicos. Sin revisiones manuales.
Forzar rotación de credenciales filtradas antes de que las prueben.
Captura tokens de vida larga, rotación débil, grants sobre-privilegiados.
Detección antes del commit y tras el push. Revocación y rotación automáticas donde sea posible.
| Fuentes | Volcados de brechas, sitios de pegado y repositorios públicos |
| Cobertura de repositorios | GitHub, GitLab, Bitbucket, Azure DevOps |
| Tipos de detección | Patrones integrados para tokens de cloud, SCM y SaaS, más regex personalizado |
| Integraciones IdP | Okta, Entra, Auth0, Google |
Cifras de pruebas internas; método y fecha de medición pendientes de publicar.
Una credencial filtrada solo importa si alguien puede usarla. El trabajo de un SOC es saber si la cuenta existe, si tiene privilegios, si está activa y qué hay que rotar. Este bloque compara Protoxol KEY, el módulo de exposición de credenciales, con cinco alternativas relevantes: tres servicios de exposición de identidades, uno centrado en inteligencia sobre identidades y uno centrado en secretos en repositorios. Compara fuentes, contexto, respuesta y licencia, no volumen de datos.
Cada celda indica el estado y el alcance. Los estados se explican debajo de la tabla.
Desliza la tabla horizontalmente para ver todas las columnas.
| Criterio | Protoxol KEY (exposición de credenciales) | SpyCloud Workforce Threat Protection | Recorded Future Identity Intelligence | Flare Identity Exposure Management | Constella Hunter DRP / Hunter+ e Intelligence Data API | GitGuardian Secrets Security (monitorización interna y pública) |
|---|---|---|---|---|---|---|
| Fuentes de exposición | DisponibleVolcados de brechas, sitios de pegado y repositorios públicos; la visión general añade dark web, tus repositorios y el log de tu IdP. | DisponibleBrechas con contraseñas en claro, logs de infostealers, capturas de phishing y combolists. Pastes y repositorios no se describen. ↗ | DisponibleLogs de infostealers, dark web, sitios de pegado, volcados de bases de datos, mercados de credenciales y combo lists. ↗ | DisponibleLogs de stealers, dark web, Telegram, sitios de pegado y de filtraciones de ransomware, más GitHub y registros de paquetes y contenedores. ↗ | DisponibleWeb superficial, profunda y dark web, brechas, sitios de pegado, foros y Telegram, además de logs de infostealers. ↗ | DisponibleRepositorios Git, CI/CD, Slack, Teams, Jira, Confluence, contenedores y GitHub público. No describe volcados de brechas ni dark web. ↗ |
| Logs de infostealers | No confirmadoLas páginas no mencionan logs de infostealers ni cookies de sesión robadas. Falta confirmarlo con el equipo de producto. | DisponibleLogs con cookies de sesión y huellas de dispositivo. El detalle por equipo infectado va en Endpoint Threat Protection, otro producto. ↗ | DisponibleCada exposición trae familia de malware, datos del equipo, marca de tiempo de exfiltración e información del dispositivo. ↗ | DisponibleLogs de stealers de familias como RedLine, Vidar o Lumma, recogidos de forma continua. ↗ | DisponibleCubre logs de infostealers y cookies de sesión robadas; en 2025 lo cita como vector en crecimiento. ↗ | No confirmadoLas páginas consultadas no describen logs de infostealers; su alcance es el secreto en código y herramientas de equipo. |
| Identidades y dominios vigilados | DisponibleVigila el registro de auditoría de Okta, Entra, Auth0 y Google. Cómo se asocian dominios y correos a las brechas no está descrito. | DisponibleDominios de correo corporativos más cuentas personales que repiten patrón de contraseña con las corporativas. ↗ | Según configuraciónCredenciales de empleados y de clientes. Ampliar dominios se pide a soporte; las detecciones nuevas suelen aparecer en un día laborable. ↗ | DisponibleCredenciales y cuentas de empleados corporativos, con vista del radio de impacto sobre servicios conectados. ↗ | DisponibleCredenciales de empleados, exposición del dominio corporativo, perfiles de directivos y suplantación de marca. ↗ | Según configuraciónVigila repositorios públicos de la organización, de desarrolladores y palabras clave de la empresa. No monitoriza correos o dominios en brechas. ↗ |
| Frescura del dato | No confirmadoLa página habla de vigilancia continua sin revisiones manuales, pero no indica cuánto tarda en aparecer una exposición nueva. | DisponibleSegún su página, brechas y phishing aparecen en días; los logs de infostealers, en horas o días. ↗ | DisponibleEl vendor describe los logs de malware como inteligencia en tiempo real y las brechas como datos que pueden tener meses. ↗ | DisponibleDescribe la detección como casi en tiempo real; no publica el retraso concreto desde que el dato aparece en el mercado. ↗ | Según configuraciónHabla de notificaciones en tiempo real. No indica cuánto tarda un dato nuevo en entrar en su base. ↗ | DisponibleAfirma avisar segundos después de que un secreto se publica en GitHub. Es una cifra del vendor, no medida. ↗ |
| Validación y contexto | DisponiblePrioriza por antigüedad, privilegio y actividad actual, y cruza con EDR y NDR para ver si la cuenta se usa. No prueba la contraseña. | DisponibleIndica qué empleados tienen la contraseña expuesta, de qué fuente y cuándo. Comprobar si sigue vigente en tu IdP no se describe. ↗ | DisponibleComplejidad de la contraseña, URL de autorización, detalles del malware y puntuación de riesgo para priorizar casos de alta confianza. ↗ | Requiere integraciónComprueba contra Microsoft Entra ID si la contraseña expuesta sigue siendo válida y calcula el radio de impacto. ↗ | DisponibleIdentity Fusion deduplica, fecha y verifica cada registro, y enlaza alias, correos y actores de amenaza. ↗ | DisponibleComprueba si el secreto sigue activo con llamadas HTTP no intrusivas cuando es posible, y filtra falsos positivos por contexto. ↗ |
| Alertas y acciones de remediación | DisponiblePasos de rotación sugeridos y playbooks desde la alerta: forzar cambio, revocar token o abrir ticket. Una persona aprueba antes de ejecutar. | DisponibleReseteo de contraseña, revocación de sesiones y disparadores de acceso condicional, también de forma automática. ↗ | Requiere integraciónReseteo de contraseña, desafío MFA y restricción de acceso, ejecutados mediante la integración con Okta o Entra ID. ↗ | Requiere integraciónReseteo de contraseña, revocación de sesiones y bloqueo de cuenta vía Entra ID, incluso fuera de horario. ↗ | Requiere integraciónRemediación con un clic a través de herramientas SOAR o IAM; no detalla qué acciones concretas ejecuta. ↗ | Según licenciaPlaybooks de remediación con Slack, Jira o ServiceNow desde el plan Growth; avisa también al desarrollador implicado. ↗ |
| Integración con identidad, endpoint y SIEM | DisponiblePlaybooks ligados a Okta, Entra, Auth0 y Google, y misma consola que EDR y NDR. Conectores con SIEM de terceros: sin detallar. | Requiere integraciónOkta, Entra ID, Active Directory, SIEM, SOAR y EDR como CrowdStrike o Defender, mediante integraciones o SpyCloud Connect. ↗ | Requiere integraciónOkta, Entra ID, Cortex XSOAR, Splunk, Swimlane y Tines; la prueba cita también Microsoft Sentinel. ↗ | Requiere integraciónEntra ID y Okta, Splunk y Azure Sentinel, Jira, Slack y Teams. EDR no aparece en la lista consultada. ↗ | Requiere integraciónSOAR, IAM, MDR/XDR y Maltego. No nombra productos concretos de identidad o endpoint en la página consultada. ↗ | Requiere integraciónSIEM, ITSM, tickets y mensajería. No describe reseteo de contraseñas en un IdP ni acciones sobre endpoints. ↗ |
| Tratamiento de contraseñas en claro | No confirmadoLas páginas no explican si se almacenan o muestran contraseñas en claro ni quién puede verlas. | Según configuraciónLos datos incluyen contraseñas en claro; el vendor cita cifrado y controles de acceso. Quién las ve en tu equipo no está documentado. ↗ | Según configuraciónOfrece hashes de las contraseñas (SHA1, MD5, SHA256, NTLM) para comparar; si muestra la contraseña en claro no consta. ↗ | No confirmadoLas páginas consultadas no explican cómo se tratan o muestran las contraseñas en claro. | No confirmadoLas páginas consultadas no explican cómo se tratan las contraseñas en claro. | No confirmadoLas páginas consultadas no explican cómo se almacenan o muestran los secretos detectados. |
| Secretos en repositorios | DisponibleGitHub, GitLab, Bitbucket y Azure DevOps; patrones integrados para tokens de cloud, SCM y SaaS, regex propio y hooks pre-commit opcionales. | No confirmadoNo describe escaneo de tus repositorios. Menciona claves de API y webhooks solo como tipo de dato recapturado. | No confirmadoNo se describe detección de secretos en repositorios en las páginas de Identity Intelligence consultadas. | Según configuraciónTokens en GitHub público, npm, PyPI, RubyGems y DockerHub. El escaneo de tus repositorios privados no se describe. ↗ | No confirmadoNo se describe detección de secretos en repositorios de código. | DisponibleGitHub, GitLab, Azure DevOps (repositorios Git) y Bitbucket; detectores por proveedor y genéricos; CLI ggshield para pre-commit y pre-push. ↗ |
| API y exportación | Según configuraciónLa plataforma exporta por webhooks, REST y OTEL. No hay una API documentada específica de KEY. | DisponibleAPI directa y SpyCloud Connect, un servicio gestionado de integraciones para flujos a medida. ↗ | Según configuraciónAcceso a API a medida bajo petición, según la FAQ de la prueba; no se detalla el alcance. ↗ | DisponibleMenciona endpoints de API e integraciones para llevar los datos a tus flujos de trabajo. ↗ | DisponibleIntelligence Data API pensada para incrustar riesgo de identidad en otros productos, MDR/XDR e investigaciones. ↗ | DisponibleAPI REST y CLI. El plan Starter limita las llamadas mensuales a la API. ↗ |
| Modelo de licencia | Según licenciaMódulo que se activa por separado. Complemento en Team, incluido en Enterprise y no listado en Starter; precio por endpoint protegido según plan. | Según licenciaPor número de cuentas de empleados o clientes protegidas, o por consultas en la API de investigación; descuentos por volumen. Sin precios públicos. ↗ | Según licenciaDos tipos de licencia, Employee Credentials y User Credentials; módulo suelto o dentro de ofertas mayores. Precio no publicado. ↗ | No confirmadoNo hay planes ni unidad de facturación publicados en las páginas consultadas; se pide demo o presupuesto. | Según licenciaDos vías: licencia de API para construir y suscripción a la plataforma para investigar; canal para MSSP y revendedores. Sin precios públicos. ↗ | Según licenciaPor desarrollador activo (con commits en 90 días). Starter gratis, Growth y Enterprise por presupuesto; la vigilancia pública completa es de Enterprise. ↗ |
Una por producto, con el plan que se ha comparado.
Plan o edición: Línea Enterprise Protection (la página en /employee-ato-prevention se titula Workforce Threat Protection); la edición concreta no se publica
SpyCloud Workforce Threat Protection encaja cuando lo que decide la compra es el dato de exposición: brechas con contraseñas en claro, logs de infostealers y capturas de phishing, con reseteo y revocación de sesión sobre Okta, Entra ID o Active Directory. Ahí va por delante de Protoxol KEY, que no confirma logs de infostealers. La diferencia de KEY es operativa: la exposición aparece en la misma consola que EDR, NDR y correo, y la rotación la aprueba una persona. Condición: SpyCloud se licencia por cuentas protegidas y necesita un SIEM o SOAR donde actuar, algo que conviene tener resuelto antes de contratarlo.
Plan o edición: Módulo de la Intelligence Cloud; licencias Employee Credentials o User Credentials
Recorded Future Identity Intelligence aporta lo que más ayuda a un analista al abrir una exposición: familia de malware, datos del equipo infectado, hora de exfiltración y una puntuación de riesgo, además de hashes para comparar contraseñas. KEY no confirma ese nivel de detalle sobre infostealers. Lo que sí hace KEY es mirar tus propios repositorios y cruzar la cuenta con la actividad de EDR y NDR. Recorded Future encaja si ya trabajas con su Intelligence Cloud o con XSOAR, Splunk o Sentinel. Condición: las dos licencias, Employee Credentials y User Credentials, cubren casos distintos, y los dominios adicionales se piden a soporte.
Plan o edición: Parte de la plataforma Threat Exposure Management; los planes no son públicos
Flare Identity Exposure Management parte de los logs de stealers y los valida contra Microsoft Entra ID antes de resetear la contraseña y cerrar sesiones. Ese paso de validación es lo que KEY no confirma. También vigila GitHub público y registros de paquetes y contenedores, pero no queda claro que escanee tus repositorios privados, que KEY sí cubre con GitHub, GitLab, Bitbucket y Azure DevOps. Flare encaja en equipos con Entra ID como directorio principal. Condición: sus planes no son públicos y EDR no figura entre sus integraciones, así que la actividad de la cuenta en el endpoint la tendrías que mirar en otra herramienta.
Plan o edición: Plataforma Hunter (suscripción) o licencia de API; la edición no se publica
Constella destaca por la profundidad del dato de identidad: enlaza alias, correos y actores, cubre infostealers y cookies de sesión, y ofrece una API para incrustarlo en otros productos. Es una herramienta de investigación y de riesgo digital más amplia que KEY, con foco en empresas grandes, sector público y MSSP. Para un equipo pequeño que solo quiere saber qué cuentas expuestas se usan y rotarlas, puede ser más de lo que necesita, y no describe escaneo de repositorios. KEY queda más cerca de la operación diaria: alerta, actividad de la cuenta y playbook. Condición: los precios y las acciones de remediación concretas no son públicos.
Plan o edición: Growth (de pago) y Enterprise; existe un plan Starter gratuito hasta 25 desarrolladores
GitGuardian es la referencia si el problema son los secretos en código: detectores por proveedor, comprobación de que el secreto sigue vivo, escaneo de CI/CD, Slack y Jira, y un CLI para pre-commit. En ese terreno va por delante de KEY. No es un servicio de brechas: sus páginas no describen volcados, infostealers ni la cuenta de un empleado en un IdP, que es lo que KEY junta en una vista. Encaja con equipos de desarrollo que ya gestionan incidentes en Jira o ServiceNow. Condición: se factura por desarrollador activo, y la vigilancia pública completa solo está en Enterprise, con la limitada en Growth.
Las páginas de producto no los mencionan, así que no podemos afirmarlo. Si ese es tu caso principal, pídelo en la demo antes de decidir. SpyCloud, Recorded Future, Flare y Constella sí los describen en sus páginas.
Expuesta es que aparece en un volcado, un pegado o un repositorio. Comprometida es que alguien puede usarla ahora. Para decidirlo miras si la contraseña sigue vigente, qué privilegios tiene la cuenta y si ha tenido actividad reciente. KEY prioriza con privilegio y actividad; no prueba la contraseña.
Depende de lo que cubras. GitGuardian cubre secretos en código y herramientas de equipo. KEY añade brechas, sitios de pegado y el log de tu IdP, pero en detección de secretos en repositorios GitGuardian documenta más. Pueden convivir.
KEY es un módulo que se activa por separado. En los planes publicados es un complemento en Team, está incluido en Enterprise y no aparece en Starter. El precio se calcula por endpoint protegido según plan.
Revisado el 2 de octubre de 2026. Revisado por Equipo de Protoxol.
Las capacidades de Protoxol se basan en la documentación comercial vigente de esta web y no se han validado técnicamente en esta revisión; lo no documentado figura como «No confirmado». Los datos de cada fabricante proceden de su documentación pública en la fecha indicada y pueden haber cambiado.
Repositorios, IdP y bases de datos de brechas en una sola vista.
Credenciales usadas suben primero.
Playbooks de rotación atados a tu IdP, lanzados desde la propia alerta.
Es la comprobación continua de si las credenciales, claves de API y tokens de tu organización han aparecido donde no deberían: volcados de brechas, sitios de pegado, repositorios públicos. Cuando ocurre, recibes una alerta ligada a la cuenta o al activo afectado para rotarla antes de que alguien la use.
SpyCloud es un servicio dedicado a exposición de identidades con su propia recopilación de datos de brechas. KEY es un módulo de la consola de Protoxol: sus exposiciones caen en la misma línea temporal de incidente que tus eventos de endpoint, identidad y correo, y la respuesta, como forzar un cambio de contraseña o aislar un equipo, se ejecuta desde el mismo sitio. Si ya usas SpyCloud, KEY puede ingerir sus alertas como fuente.
Sí, cuando los conectas. KEY vigila los secretos que se suben a los repositorios que autorices y avisa de tokens y claves expuestos, incluido el historial de commits. No necesita permisos de escritura.
La alerta indica la cuenta, la fuente donde se ha visto y los activos que la usan. Desde ahí un playbook puede forzar el reinicio de contraseña, revocar el token o abrir un ticket, con una persona aprobando la acción.
Treinta minutos. Tu entorno. Los módulos que encajan. Sin diapositivas.