Descubra dónde la IA atacaría su empresa antes de que alguien lo haga.

Con la IA, los ataques se volvieron más rápidos, más sofisticados y más difíciles de detectar. Hify usa agentes de IA para atacar sus sistemas primero, con su autorización. Especialistas confirman qué es un riesgo real, y usted ve en un panel si la empresa se está volviendo más segura.

Agendar demostración Ver la plataforma
  • Usted autoriza qué se prueba
  • Un especialista confirma cada riesgo
  • Informe listo para el directorio

Seguridad de la empresa

2 aplicaciones · actualizado hace 2 min

Índice de riesgo0 a 100, menor es mejor

298% menor desde Hify

Índice de riesgo por mes, de 0 a 100
MesÍndice
enero (antes de Hify)86
febrero (antes de Hify)90
marzo (Hify activada a fin de mes)89
abril5
mayo3
junio4
julio2
agosto3
septiembre2
Dónde está el riesgopor área
  • Cuentas y accesos4
  • Datos de clientes2
  • Pagos y Pix1
  • Socios1

Mayor riesgo hoy: cuentas y accesos, 4 de 100. Ningún crítico abierto.

Riesgos críticos abiertos
0
los 2 de septiembre, corregidos en hasta 3 días
Tiempo hasta corregir
3 días
eran 21 antes de Hify
Ataques simulados en el mes
1.284
4 resultaron en riesgo confirmado
Agentes de IA ahora
  1. 14:06agente-reconEncontró 3 rutas nuevas en el deploy de hoyen el plan
  2. 14:05agente-sesionReutilizó una sesión expirada en la appbloqueado
  3. 14:04especialista HifyRepitió el ataque de HFY-0157 y confirmó la correccióncorregido
  4. 14:03agente-authzIntentó leer datos de otro cliente por la APIbloqueado
Pantalla ilustrativa · datos ficticiosResumen · Ejemplo S.A.

Un pentest al año no sigue el ritmo de los cambios.

En cada deploy aparecen endpoints nuevos y cambian las reglas de acceso. En Hify, cada aplicación entra en ciclos según su orden de riesgo, y un cambio relevante dispara una prueba dirigida. Usted ve, mes a mes, si la exposición baja.

Pruebas por aplicación52 semanas de deploys

Espera hasta probar un cambio
0 semanasla prueba sale la semana del deploy
Cambios relevantes sin prueba
9 de 10solo 1 cayó en la ventana del pentest

Pentest anual: las aplicaciones A, B y C se prueban una vez, en las tres primeras semanas del año. Después quedan 49 semanas sin prueba, y 9 de 10 cambios relevantes salen a producción sin prueba.

Ilustrativo: un año ficticio de deploys. A, B y C son aplicaciones.Su equipo define el orden de riesgo y la cadencia.

Una plataforma para todo el ciclo, de la superficie al retest.

Mapea lo que está expuesto, prueba con el contexto de su negocio y entrega cada hallazgo con evidencia. Cada pantalla responde a una pregunta de su equipo.

Resumen ¿La empresa está más segura?

El problema
Entre un pentest y otro, nadie puede decirle al directorio si el riesgo subió o bajó.
En Hify
Un panel responde con números: cuánto riesgo hay, dónde está y cuánto tarda el equipo en corregir.
Quién lo usa
CEO, CTO y liderazgo de seguridad
En la práctica
Con Hify, el índice de riesgo bajó de 89 a 2 y el tiempo de corrección, de 21 a 3 días.

Resumen

2 aplicaciones · 308 rutas · actualizado el 26/09

Índice de riesgo
2 de 100
87 puntos menos desde Hify
Críticos abiertos
0
los 2 de septiembre ya corregidos
Tiempo de corrección
3 días
eran 21 antes de Hify
Cobertura
85% de las rutas
Riesgos abiertos por gravedad
Riesgos abiertos por gravedad, por mes
MesCríticaAltaMedia
marzo (Hify activada a fin de mes)589
abril012
mayo011
junio002
julio011
agosto002
septiembre011
Tiempo de correccióndías, promedio del mes
Tiempo promedio de corrección, en días
MesDías
enero (antes de Hify)22 días
febrero (antes de Hify)20 días
marzo (Hify activada a fin de mes)21 días
abril5 días
mayo4 días
junio5 días
julio4 días
agosto4 días
septiembre3 días
Dónde está el riesgoíndice por área
  • Cuentas y accesos4
  • Datos de clientes2
  • Pagos y Pix1
  • Socios1
Requiere atención2
  • HFY-0160Enlace de cambio de contraseña sirve más de una vez AltaObservadoespera validación
  • HFY-0151Se puede saber quién es cliente por su CPF MediaEn retestdesde 24/09
Pantalla ilustrativa · datos ficticiosResumen · Ejemplo S.A.

Vea estas pantallas en funcionamiento, con las preguntas de su equipo.

Agendar demostración

Profundidad de pentest, al ritmo de sus cambios.

El pentest anual profundiza, pero vale para una fecha. El scanner corre siempre, pero no conoce las reglas de su negocio. El bug bounty depende de quién aparezca. Hify prueba en ciclos, con varios perfiles, y cada hallazgo llega validado.

Comparación entre pentest anual, scanner (DAST), bug bounty y la plataforma Hify
Pentest anualconsultoría, con fecha agendada Scanner (DAST)escaneo automático Bug bountyinvestigadores externos, pago por hallazgo Hifyagentes de IA y validación por especialista
Frecuencia 1 vez al año en cada escaneo programado o build mientras el programa esté abierto en ciclos, según el orden de riesgo, y tras un cambio relevante
Fallas de autorización y lógica de negocio IDOR/BOLA sí, dentro del período de la prueba limitado: no conoce las reglas del negocio depende del investigador sí, con agentes de autorización y de reglas de negocio
Pruebas autenticadas con varios perfiles sí, con las cuentas proporcionadas sí depende del acceso que da el programa sí, cada perfil contra las rutas de la matriz de autorización
Prueba de explotación reproducible sí, en el informe final alerta con la solicitud, sin el camino de ataque sí, en el reporte del investigador solicitud y respuesta en cada hallazgo
Quién filtra los falsos positivos el consultor su equipo el triaje del programa, luego su equipo especialista Hify, antes de llegar a su equipo
Retest de la corrección si está en el contrato en el próximo escaneo depende del investigador en el mismo camino de ataque, con el antes y el después
Muestra qué no se probó, y por qué depende del informe muestra lo que rastreó, sin el motivo no sí, ruta por ruta, con el motivo
Se integra al deploy CI no sí no sí, un paso en el pipeline dispara una prueba dirigida
Previsibilidad de costo valor fijo por proyecto suscripción variable, pago por hallazgo por aplicación, según el plan; no varía con el número de hallazgos
Red interna, ingeniería social y prueba física sí, cuando se contrata no rara vez en el alcance fuera del alcance de la plataforma

Comparación general: los contratos de pentest, los scanners y los programas de bug bounty varían. Para red interna, ingeniería social y prueba física, el pentest tradicional sigue siendo el camino.

Ver un hallazgo del alcance al retest

Un hallazgo, del alcance al retest.

Vea lo que su equipo recibe en cada hallazgo: solicitud, respuesta, impacto, corrección y la prueba de que la corrección funcionó. Caso ficticio, con datos sintéticos.

  1. Usted define el objetivo y los límites en el panel.

    Objetivo, nivel de acceso, cuentas de prueba y rutas prohibidas quedan registrados antes de la primera solicitud. Lo que está fuera de la lista, la política lo bloquea.

  2. Los agentes plantean hipótesis y prueban cada una.

    El agente de autorización probó tres hipótesis: una se reprodujo, dos se descartaron. Su equipo recibe lo que se sostiene, no una lista de sospechas.

  3. La plataforma reproduce la falla y guarda la prueba.

    La solicitud y la respuesta quedan en el hallazgo, con los datos personales enmascarados. El desarrollador la reproduce solo, sin pedirle detalles a nadie.

  4. Un especialista valida y mide lo que está en juego.

    Un especialista de Hify confirma la falla y describe qué se filtra, a quién afecta y qué exige el ataque. La severidad llega justificada, lista para priorizar.

  5. Su equipo recibe qué cambiar, con responsable y plazo.

    La guía señala la causa y las 11 rutas con el mismo patrón. El hallazgo se convierte en ticket con responsable, y el plazo sigue la política de SLA que usted definió.

  6. El retest confirma la corrección.

    La misma solicitud se ejecuta de nuevo después del ajuste. El hallazgo solo se cierra con prueba en el historial: 200 OK antes, 404 después.

HFY-0142 Entorno: homologación. Alta Corregido Validado por especialista Hify Responsable equipo de Cuentas

Lectura de datos de otra cuenta

  • GET /v1/accounts/{id}
  • OWASP API1:2023
  • CWE-639
  • api.exemplo.com.br/v1

Alcance

definido por su equipo en el panel
Objetivo
api.exemplo.com.br/v1
Nivel de acceso
Credenciales
Cuentas de prueba
cuenta-a cuenta-b
Fuera del alcance
/v1/admin/* /payments/* panel interno
Límites
5 req/s · DELETE bloqueado

Camino

agente-authz · 3 hipótesis
  1. H-01 Cambio de ID en la ruta200 en 3 de 3 IDs de otra cuenta reproducida
  2. H-02 Rol vía encabezadoel servidor ignora el encabezado descartada
  3. H-03 Token de otra sesiónsesión rechazada descartada

Solo H-01 pasa a validación. Las descartadas quedan en el registro de la ejecución.

Evidencia

reproducida el 14/09 22:15

Solicitudsesión de cuenta-a

GET /v1/accounts/7f3c…e21
Authorization: Bearer ‹sesión cuenta-a›

El ID 7f3c…e21 pertenece a cuenta-b. La sesión es de cuenta-a, y la API responde de todos modos.

Respuestadatos de cuenta-b

HTTP/1.1 200 OK
{
  "id": "7f3c…e21",
  "nome": "Mar*** S***",
  "email": "m***@exemplo.com.br",
  "cpf": "***.***.***-12"
}
datos personales enmascarados en la evidencia

Impacto

validado el 15/09 09:12 por especialista Hify (ejemplo)
Expone
nombre e-mail CPF de otra cuenta
Alcance
cualquier cuenta con ID conocido
Exige
sesión válida de cualquier cliente
Severidad
Alta

Por qué Alta y no Crítica: expone datos personales de cualquier cliente, pero exige una sesión válida y solo permite lectura.

Corrección

ticket SEG-214 en Jira

Validar en el servidor que el account_id pertenece a la sesión antes de responder. Responder 404, y no 403, para no confirmar que el ID existe.

if (account.id !== session.account_id) {
  return res.status(404)
}

11 rutas reciben un identificador de cuenta y siguen el mismo patrón

  • GET /v1/accounts/{id}
  • PATCH /v1/accounts/{id}
  • 9 más en el panel
Responsable
equipo de Cuentas
Plazo
30/09 · Alta, 15 d desde la validación

Retest

Corregido
Antes 14/09 · 200 OK · cuerpo con datos de cuenta-b
Después 18/09 · 404 Not Found
  1. agente-authzreprodujo la falla
  2. especialista Hifyvalidó · Alta
  3. equipo de Cuentasasumió · SEG-214
  4. agente-authzretest: 404 · Corregido
misma solicitud, mismas cuentas de prueba
Pantalla ilustrativa · datos ficticiosDetalle del hallazgo HFY-0142

En la demostración, usted recorre este hallazgo en el panel, del alcance al retest. El especialista de Hify valida, AppSec prioriza, Ingeniería corrige y el CISO hace el seguimiento.

Agendar demostración

Autonomía dentro de los límites que su equipo aprueba.

Usted define hosts, rutas, cuentas de prueba, ventana y límite de solicitudes. Cada solicitud queda registrada, y lo que está fuera del alcance lo bloquea la política antes de salir.

El alcance aprobado se vuelve política, verificada en cada solicitud.

Un agente autónomo inquieta porque decide solo el siguiente paso. En Hify, solo llega a lo que está en la allowlist, con las cuentas de prueba que usted registró, dentro de la ventana y del límite. Su WAF reconoce el tráfico por las IP fijas y por el encabezado de la ejecución, y lo que está en la denylist nunca se toca.

  • Allowlist y denylist de hosts y rutas
  • Cuentas de prueba y nivel de acceso
  • Reglas de negocio que la aplicación debe garantizar

Quién lo usa AppSec arma el alcance, el CISO lo aprueba e infraestructura habilita las IP en el WAF.

Alcance y guardrails

Aprobado por CISO (ejemplo) el 11/09

Política activa
Objetivosadónde pueden ir los agentes
Allowlist hosts y rutas
  • app.exemplo.com.br
  • api.exemplo.com.br/v1
Cuentas de prueba sesiones de los agentes
  • cuenta-a
  • cuenta-b
Denylist bloqueado antes de salir
  • /v1/admin/*
  • /payments/*
  • panel interno
  • servicios de terceros
Acceso y ritmocómo prueban los agentes
Nivel de acceso
Credenciales. Opciones: externo, credenciales, código.
Ventana
lun a vie, 22h-06h
Límite
5 req/s
Métodos
DELETE bloqueadodestructivos solo en cuenta de prueba
Reglas de negociodefinidas por su equipo
  • Cliente persona física solo lee su propia cuenta GET /v1/accounts/{id} HFY-0142Corregido
  • Operador de empresa no cambia el campo role PATCH /v1/accounts/{id} HFY-0148Corregido
  • Un reembolso Pix por transacción POST /v1/pix/estorno ninguna violación
Trazabilidadcómo su equipo reconoce y audita el tráfico
IP de origen fijas
203.0.113.10203.0.113.11para habilitar en el WAF
Encabezado en cada solicitud
X-Hify-Run: run_0412
Registro de solicitudes
Cada solicitud con su respuesta, exportable en HAR y CSV.
Pantalla ilustrativa · datos ficticiosAlcance y guardrails · Ejecución #0412

Usted sigue cada paso y puede pausar.

Un informe al final de la prueba no muestra lo que el agente intentó en el camino. En la actividad, cada hipótesis aparece con ruta, respuesta y resultado, y el especialista revisa lo que se sostiene. Si algo se sale de lo previsto, su equipo pausa la ejecución desde aquí.

  • Ningún hallazgo pasa a Validado sin revisión de un especialista; usted ve quién lo revisó y cuándo
  • Registro de cada solicitud, exportable

Quién lo usa El CISO sigue la ejecución y la pausa si hace falta. AppSec audita el registro.

Actividad

Inicio 25/09 22:00 · 7 agentes · 5 req/s

en curso
  1. Hipótesis512
  2. Señales14
  3. Reproducidos2
  4. En validación1HFY-0160
  5. Validados hasta ahora0
  6. Descartados por el especialista1
Registro7 agentes · desde 25/09 22:00
  1. 22:02:15agente-recon ruta nueva POST /v1/pix/devolucao, publicada el 22/09 · fuera de la lista aprobada no probada
  2. 22:04:48agente-authz GET /v1/admin/export fuera del alcanceregla de la denylist /v1/admin/* · solicitud no enviada bloqueado por la política
  3. 22:06:40agente-authz repite el camino de HFY-0142: GET /v1/accounts/7f3c…e21 con sesión de cuenta-a → 404 · sigue corregido denegado, esperado
  4. 22:08:05agente-authz cliente persona física pide GET /v1/invoices/{id} de otra cuenta → 404 denegado, esperado
  5. 22:11:12agente-sesion POST /reset con token de restablecimiento ya usado → 200 · contraseña cambiada otra vez señal
  6. 22:11:58agente-sesion repetido en cuenta-b → 200 en 2 de 2 · HFY-0160 espera validación del especialista reproducido
  7. 22:15:27agente-logica segundo reembolso de la misma transacción en POST /v1/pix/estorno → 409regla de negocio: un reembolso Pix por transacción denegado, esperado
  8. 22:19:40agente-inyeccion POST /login con comillas en el campo cpf → 400, entrada rechazada denegado, esperado
Pantalla ilustrativa · datos ficticiosActividad · Ejecución #0412

Datos e IA

Antes de aprobar un agente, el equipo de riesgo quiere saber adónde van los datos. Estas son las cinco preguntas que el cuestionario de seguridad de Hify responde por escrito.

Pedir el cuestionario en la demostración
Región de almacenamiento
¿En qué país quedan evidencias, registros e informes?
Retención de evidencias
¿Por cuánto tiempo se guardan y cómo se pide su eliminación?
Proveedores de modelos
¿Qué modelos de IA procesan solicitudes y respuestas?
Uso de sus datos para entrenamiento
¿Su tráfico y sus hallazgos entrenan algún modelo?
Custodia de credenciales de prueba
¿Dónde quedan las contraseñas de cuenta-a y cuenta-b, y quién tiene acceso?

Las cinco respuestas vienen por escrito en el cuestionario de seguridad, entregado bajo NDA.

El hallazgo llega adonde su equipo ya trabaja.

Ticket con responsable y plazo, alerta en el canal del equipo, enlace al PR de la corrección y retest cuando sale el deploy. Sin planillas, sin PDF perdido en el correo.

  1. Solo sale lo que fue validado

    El ticket y la alerta nacen cuando el especialista valida. El backlog recibe un hallazgo reproducido, no una alerta cruda.

    Crítica Validado

    Límite diario eludido con solicitudes paralelas

    Ruta
    POST /v1/transfers
    Responsable
    equipo de Tarjetas
    Plazo
    vence en 6 d

    especialista Hify (ejemplo), 22/09

    Regla de envío Crítica validada: ticket en SEG, alerta en #seguridad-appsec

    HifyhallazgoPantalla ilustrativa · datos ficticios

  2. Ticket con responsable y plazo

    En el proyecto del equipo responsable, con evidencia, corrección sugerida y el plazo de su política. Nadie transcribe hallazgos de un PDF.

    Por hacer creado por Hify

    SEG-231 · Límite diario eludido con solicitudes paralelas

    Responsable
    equipo de Tarjetas
    Fecha límite
    29/09
    Severidad
    Crítica
    Origen
    HFY-0157
    Entorno
    homologación

    Descripción

    • Pasos para reproducir
    • Solicitud y respuesta
    • Corrección sugerida
    JiraticketPantalla ilustrativa · datos ficticios

  3. Alerta en el canal del equipo

    El equipo se entera el día de la validación, no en la reunión del mes. La alerta lleva al hallazgo y al ticket.

    Hify app 22/09

    Nuevo hallazgo validado: HFY-0157 Crítica en api.exemplo.com.br/v1 (homologación) · responsable equipo de Tarjetas · plazo 29/09

    1 respuesta · equipo de Tarjetas

    Slack o TeamsalertaPantalla ilustrativa · datos ficticios

  4. Corrección vinculada al hallazgo

    El PR de la corrección aparece en el hallazgo. AppSec sigue el avance sin pedir estado en reuniones.

    abierto esperando merge · hallazgo en homologación

    Bloqueo de límite diario por cuenta (#812)

    fix/seg-231 hacia main

    Corrige HFY-0157 SEG-231

    • pruebaspasaron
    • revisiónaprobada
    • Hify retesten el merge
    GitHub o GitLabpull requestPantalla ilustrativa · datos ficticios

  5. Retest cuando sale el deploy

    Después del merge, el pipeline hace el deploy en homologación y llama a Hify para repetir el ataque. El hallazgo solo se cierra con la prueba en el historial.

    Al entrar en main

    1. build
    2. deploy en homologación
    3. Hify retest dirigido
    $ hify run --app api.exemplo.com.br --finding HFY-0157 --wait

    retest programado para el merge

    GitHub o GitLabpipelinePantalla ilustrativa · datos ficticios

Después del deploy, el retest repite el mismo camino de ataque. Si no se reproduce, el hallazgo se cierra con la prueba en el historial. En retestCorregido

Pantalla ilustrativa · datos ficticiosHFY-0157, del panel de Hify al retest · quién lo usa: ingeniería y AppSec

La corrección sale del agente de código de su equipo.

El hallazgo validado llega a Claude Code, Cursor o Codex con la solicitud, la respuesta y la corrección sugerida. El agente prepara el PR, un desarrollador lo revisa y Hify repite el ataque antes de cerrar el riesgo.

  • Claude Code
  • Cursor
  • Codex
  • GitHub Copilot
  • Windsurf
claude · exemplo/apiClaude Code con el MCP de Hify · ejemplo
> corrige el hallazgo HFY-0157

hify.get_finding HFY-0157 · Crítica · validado por especialista
  Límite diario eludido con solicitudes paralelas
  POST /v1/transfers · evidencia y corrección sugerida

editando src/transfers/limit.ts
pruebas  42 pasaron

PR abierto #812 Bloqueo de límite diario por cuenta
hify.request_retest retest programado para el merge

Integraciones y acceso

Tickets
  • Jira

Se abre en el proyecto del equipo responsable, con evidencia, corrección sugerida y plazo. El estado del hallazgo sigue al ticket.

Alertas
  • Slack
  • Microsoft Teams

Aviso en el canal del equipo cuando se valida un hallazgo y recordatorio cuando el plazo está por vencer.

Comunicación
  • Correo
  • WhatsApp
  • Slack

El especialista de Hify habla directo con su equipo: resumen de cada ciclo por correo, aviso inmediato de riesgo crítico por WhatsApp y conversación en el canal compartido de Slack.

Código y CI
  • GitHub
  • GitLab
  • GitHub Actions
  • GitLab CI

El PR de la corrección queda vinculado al hallazgo, con el check de retest. Un paso en el pipeline dispara una prueba dirigida después del deploy.

Agentes de código
  • Claude Code
  • Cursor
  • Codex
  • GitHub Copilot
  • Windsurf

A través del servidor MCP de Hify, el agente lee el hallazgo validado con la evidencia, prepara la corrección y pide el retest.

Datos
  • API REST
  • Webhooks firmados
  • PDF
  • CSV
  • HAR

PDF ejecutivo, técnico o constancia para clientes. Hallazgos en CSV y solicitudes de la ejecución en HAR.

Acceso
  • SSO SAML
  • SSO OIDC
  • Roles
  • Log de auditoría

Roles Admin, AppSec, Desarrollador y Lectura. Quién cambió alcance, estado o acceso queda en el log de auditoría.

En el pipeline y por API

Después del deploy en homologación, un paso en el pipeline vuelve a probar solo las rutas que cambiaron. Los webhooks van firmados: su sistema verifica el origen de cada evento.

Ver el paso en deploy.yml
.github/workflows/deploy.ymlGitHub Actions · ejemplo
env:
  HIFY_TOKEN: ${{ secrets.HIFY_TOKEN }}

jobs:
  teste-hify:
    needs: deploy-homologacao
    runs-on: ubuntu-latest
    steps:
    - name: Hify en las rutas modificadas
      run: >
        hify run
        --app api.exemplo.com.br
        --scope changed-routes
        --wait
Ver un evento de webhook
POST /webhooks/hifyWebhook · ejemplo
X-Hify-Event: finding.validated
X-Hify-Signature: sha256=9f2c…a41

{
  "event": "finding.validated",
  "finding": {
    "id": "HFY-0157",
    "severity": "critica",
    "state": "validado",
    "ticket": "SEG-231"
  }
}

Empiece con una aplicación.

No hace falta abrir todo de una vez. La primera ejecución cubre una aplicación, solo desde la vista externa o con dos cuentas de prueba. Las demás entran después, cada una con su cadencia, en el orden de riesgo que define su equipo.

  1. Demostración

    La plataforma funcionando en un entorno parecido al suyo: una ejecución, un hallazgo con prueba, el retest y el informe.

    Lo que usted abre en esta etapa

    Acceso a su entorno
    ninguno
    Cuentas de prueba
    todavía no
    Datos sensibles
    ninguno

  2. Alcance, NDA y cuentas de prueba

    Usted registra las URLs y crea cuentas de prueba por perfil. Importar el OpenAPI es opcional. El NDA viene antes de cualquier dato sensible.

    Alcance · ejemplo

    Objetivo
    api.exemplo.com.br/v1
    Cuentas de prueba
    cuenta-a · cuenta-b
    OpenAPI v3
    opcional
    NDA
    firmado

  3. Primera ejecución

    Los agentes prueban dentro del alcance y un especialista revisa lo que reprodujeron. Los hallazgos aparecen en el panel con prueba, severidad y responsable.

    En el panel · HFY-0142 · ejemplo

    Hallazgo
    Lectura de datos de otra cuenta
    Severidad
    Alta
    Prueba
    solicitud y respuesta
    Responsable
    equipo de Cuentas

  4. Cadencia por aplicación

    Cada aplicación recibe una cadencia según su orden de riesgo: en el ejemplo, la API cada dos meses y la web cada cuatro. Una ruta nueva en el alcance recibe una prueba dirigida.

    Cadencia · próximos 12 meses

    Prueba dirigida en la ruta nueva POST /v1/pix/devolucao

Ejemplos con datos ficticios.

Qué define el plan

No hay tabla de precios pública. El valor del plan depende de estos tres puntos y se define después de la demostración.

Aplicaciones por ciclo
Cuántas entran en cada ciclo. El peso de cada una depende de su complejidad: cuántas URLs, APIs e integraciones involucra.
Frecuencia
Cuántos ciclos al año y si corre una prueba dirigida en cada deploy.
Nivel de acceso
  1. Externo
  2. Credenciales
  3. Código

Cuanto más acceso, más ve la prueba.

Agendar demostración

Quiénes están detrás de Hify.

Una empresa de producto, con dos fundadores construyendo la plataforma. Uno ya llevó una startup desde cero hasta su venta; el otro viene de la consultoría en seguridad de agentes de IA. A su lado, como asesor, un miembro del consejo de administración de Nubank.

Igor Gontijo

Cofundador y CEO

Igor fundó Hackr Ads en 2019 y llevó la empresa a 45 mil clientes y a R$ 380 millones al mes en anuncios gestionados por la plataforma. En 2022 vendió Hackr Ads a Conta Simples. En Hify aplica lo que aprendió construyendo software que miles de empresas usan todos los días.

Lucas Fonseca

Cofundador y Chief AI Officer

Lucas trabaja en seguridad de agentes de IA y fue consultor en esa área para Dreamer, cuyo equipo luego fue incorporado por Meta (Facebook). En Hify se encarga de los agentes que atacan los sistemas de los clientes: qué puede probar cada uno, cómo se controla y cómo llega el resultado al especialista.

Rogério Calderón

Asesor y miembro del consejo de administración de Nubank

Rogério es miembro del consejo de administración de Nubank desde 2021 y preside su comité de auditoría y riesgos. Antes fue socio de auditoría de PwC y director financiero de Bunge Brasil, Unibanco, Itaú Unibanco y HSBC Brasil. Conoce de cerca lo que pregunta un consejo cuando el tema es el riesgo.

Preguntas antes de la demostración.

Respuestas cortas sobre cómo la plataforma prueba, valida y guarda lo que encuentra. El detalle de su caso queda para la demostración.

¿Hify reemplaza al scanner o al DAST?

No, lo complementa. El scanner y el DAST buscan patrones conocidos, una solicitud a la vez. Hify sigue caminos de varias etapas con sesión real, como usar la sesión de cuenta-a para leer el registro de cuenta-b, usa las reglas de negocio de la aplicación (quién puede ver, aprobar o transferir qué) y entrega cada hallazgo con la prueba: solicitud, respuesta e impacto.

¿Reemplaza al pentest manual?

En aplicaciones web y APIs, la plataforma prueba con mucha más frecuencia que un pentest anual, y todo hallazgo pasa por un especialista antes de quedar como Validado. Red interna, ingeniería social y prueba física quedan fuera; para eso, el pentest manual sigue en su plan.

¿En qué entorno corren las pruebas?

En el entorno que usted define en el alcance, con ventana horaria, límite de solicitudes por segundo y métodos destructivos bloqueados. Los ejemplos de esta página usan homologación.

¿Dónde quedan los datos de las pruebas?

Dónde quedan, por cuánto tiempo y quién accede se responde en el cuestionario de seguridad, bajo NDA, antes de cualquier dato sensible. En la evidencia, los datos personales aparecen enmascarados, como m***@exemplo.com.br.

¿Cómo se valida un hallazgo de la IA?

Primero el agente reproduce la señal con otros IDs y otra cuenta. Después un especialista revisa las reglas de negocio, evalúa el impacto y descarta el falso positivo. Solo queda como Validado lo que fue reproducido y revisado, y la línea de tiempo del hallazgo registra cuándo lo validó el especialista.

¿Tengo que entregar credenciales o código?

No para empezar. Se puede partir de la vista externa o de dos cuentas de prueba, que ya muestran si una cuenta logra leer datos de la otra. El código entra cuando usted lo autorice, y la prueba pasa a ver más.

¿Qué integraciones existen?

Jira, con el ticket en el proyecto del equipo responsable y el estado del hallazgo siguiendo al ticket. Slack y Microsoft Teams, con aviso cuando se valida un hallazgo y recordatorio de plazo. GitHub y GitLab, con el PR vinculado al hallazgo y el check de retest, además de GitHub Actions y GitLab CI. También webhooks firmados, API REST y exportación en PDF, CSV y HAR. El acceso al panel usa SSO (SAML u OIDC), roles Admin, AppSec, Desarrollador y Lectura, y log de auditoría.

¿Se puede disparar una prueba en cada deploy?

Sí. Un paso en el CI, como hify run --app api.exemplo.com.br --scope changed-routes --wait en GitHub Actions o en GitLab CI, dispara una prueba dirigida en las rutas que cambiaron. Los ciclos completos siguen la cadencia de cada aplicación.

¿Y si no se encuentra nada?

Ningún hallazgo no significa entorno seguro. El informe registra qué se probó, con qué accesos, y qué quedó fuera y por qué, como una ruta que exige MFA por hardware.

¿Ustedes divulgan lo que encuentran?

No. Los hallazgos quedan entre Hify y su equipo, bajo NDA. Nada que identifique a su empresa se publica sin autorización por escrito.

¿Cómo funciona el precio?

Por aplicación, según el plan. El peso de cada una depende de su complejidad: cuántas URLs, APIs e integraciones involucra. La frecuencia y el nivel de acceso también cuentan. El valor del plan se define después de la demostración; no hay tabla pública.

Vea a Hify probando una aplicación como la suya.

Cuéntenos cuántas aplicaciones tienen en producción y con qué frecuencia publican. En la demostración, usted sigue el ciclo completo, del alcance al retest.

  • Una ejecución de principio a fin, con el registro de los agentes.
  • Un hallazgo con prueba, responsable y plazo, hasta el retest.
  • El alcance, los límites y la pausa, que quedan en manos de su equipo.

Los campos con asterisco son obligatorios.

Comparta solo una visión general. La información sensible y los accesos quedan para la etapa de alcance.

Al enviar, su app de correo se abre con el mensaje listo para [email protected]. Usted lo revisa antes de mandarlo.

Agendar demostración