Com IA, os ataques ficaram mais rápidos, mais sofisticados e mais difíceis de perceber. A Hify usa agentes de IA para atacar seus sistemas primeiro, com a sua autorização. Especialistas confirmam o que é risco real, e você acompanha num painel se a empresa está ficando mais segura.
Segurança da empresa
2 aplicações · atualizado há 2 min
298% menor desde a Hify
| Mês | Índice |
|---|---|
| janeiro (antes da Hify) | 86 |
| fevereiro (antes da Hify) | 90 |
| março (Hify ativada no fim do mês) | 89 |
| abril | 5 |
| maio | 3 |
| junho | 4 |
| julho | 2 |
| agosto | 3 |
| setembro | 2 |
Maior risco hoje: contas e acessos, 4 de 100. Nenhum crítico aberto.
Endpoints novos sobem e regras de acesso mudam a cada deploy. Na Hify, cada aplicação entra em ciclos pela ordem de risco, e uma mudança relevante dispara um teste direcionado. Você acompanha, mês a mês, se a exposição cai.
Testes por aplicação52 semanas de deploys
Pentest anual: as aplicações A, B e C são testadas uma vez, nas três primeiras semanas do ano. Depois disso ficam 49 semanas sem teste, e 9 de 10 mudanças relevantes chegam ao ar sem teste.
Mapeia o que está exposto, testa com o contexto do seu negócio e entrega achado com prova. Cada tela abaixo responde a uma pergunta do seu time.
Visão geral
2 aplicações · 308 rotas · atualizado em 26/09
| Mês | Crítica | Alta | Média |
|---|---|---|---|
| março (Hify ativada no fim do mês) | 5 | 8 | 9 |
| abril | 0 | 1 | 2 |
| maio | 0 | 1 | 1 |
| junho | 0 | 0 | 2 |
| julho | 0 | 1 | 1 |
| agosto | 0 | 0 | 2 |
| setembro | 0 | 1 | 1 |
| Mês | Dias |
|---|---|
| janeiro (antes da Hify) | 22 dias |
| fevereiro (antes da Hify) | 20 dias |
| março (Hify ativada no fim do mês) | 21 dias |
| abril | 5 dias |
| maio | 4 dias |
| junho | 5 dias |
| julho | 4 dias |
| agosto | 4 dias |
| setembro | 3 dias |
Ativos e cobertura
2 aplicações · último teste em 25/09
Nova rota detectada POST /v1/pix/devolucao
api.exemplo.com.br/v1 · desde 22/09 · ainda não testada
| Aplicação | Rotas | Testadas | Não testadas | Abertos |
|---|---|---|---|---|
| app.exemplo.com.brWeb · último teste 25/09 | 212 | 175 | 37 | 1 |
| api.exemplo.com.br/v1API · último teste 25/09 | 96 | 88 | 1 nova8 | 1 |
Escopo importado de OpenAPI v3 Postman HAR
Achados
1 em reteste · 3 corrigidos · 1 aguardando validação
| Achado | Severidade | Estado e prazo | Dono |
|---|---|---|---|
| Campo role aceito no corpoHFY-0148validado por especialistaPATCH /v1/accounts/{id} | Crítica | Corrigidoem 24/09 | Plataforma |
| Limite diário burlado com requisições paralelasHFY-0157validado por especialistaPOST /v1/transfers | Crítica | Corrigidoem 25/09 | Cartões |
| Token de redefinição reutilizávelHFY-0160POST /reset | Alta | Observadoaguarda validação | após validação |
| Enumeração de usuário por CPFHFY-0151validado por especialistaPOST /login | Média | Em retestedesde 24/09 | Contas |
| Leitura de dados de outra contaHFY-0142validado por especialistaGET /v1/accounts/{id} | Alta | Corrigidoem 18/09 | Contas |
Prazos definidos pelo seu time: Crítica 7 d · Alta 15 d · Média 30 d · Baixa 90 d · contagem a partir de Validado
Matriz de autorização
api.exemplo.com.br/v1 · esperado definido pelo seu time
| Endpoint | cliente PF | PJ admin | PJ operador |
|---|---|---|---|
| GET /v1/accounts/{id}conta de outro cliente | esperado: negar · obtido: 200 em 14/09HFY-0142 corrigido | negado | negado |
| PATCH /v1/accounts/{id}alterar o campo role | negado | permitido | esperado: negar · obtido: 200 em 22/09HFY-0148 corrigido |
| POST /v1/transfersa partir da própria conta | permitido | permitido | permitido |
| GET /v1/invoices/{id}fatura da própria conta | permitido | permitido | negado |
Testado com contas de teste por perfil; login gravado com OTP de teste e renovação de sessão.
Relatórios
Ciclo de setembro de 2026 · 2 aplicações · 4 achados validados, 1 aguardando validação
Exemplo S.A. · segurança da empresa em setembro
O índice de risco caiu de 89 para 2 desde que a Hify entrou, no fim de março. Nenhum risco crítico aberto: os 2 encontrados em setembro foram corrigidos em até 3 dias.
Índice de risco
2 de 100 · baixo
Tendência, janeiro a setembro
| Mês | Índice |
|---|---|
| janeiro (antes da Hify) | 86 |
| fevereiro (antes da Hify) | 90 |
| março (Hify ativada no fim do mês) | 89 |
| abril | 5 |
| maio | 3 |
| junho | 4 |
| julho | 2 |
| agosto | 3 |
| setembro | 2 |
| Risco | Impacto | Dono | Corrigido em |
|---|---|---|---|
| Qualquer usuário consegue virar administrador | Acesso a contas de todos os clientes | Plataforma | 2 d |
| Limite diário de transferência pode ser burlado | Perda financeira direta | Cartões | 3 d |
Conformidade
Achados do ciclo, com evidência e correção
Atestado de teste de segurança
Mapeamento dos achados
Evidência da camada de aplicação para PCI DSS v4.0.1, req. 11.4, e para os testes periódicos da Res. CMN 4.893 e da Res. BCB 85 (instituições de pagamento). A camada de rede segue com o pentest do seu plano.
Veja estas telas rodando, com as perguntas do seu time.
Agendar demonstraçãoO pentest anual aprofunda, mas vale para uma data. O scanner roda sempre, mas não conhece a regra do seu negócio. O bug bounty depende de quem aparece. A Hify testa em ciclos, com vários perfis, e cada achado chega validado.
| Pentest anualconsultoria, com data marcada | Scanner (DAST)varredura automática | Bug bountypesquisadores externos, pago por achado | Hifyagentes de IA e validação por especialista | |
|---|---|---|---|---|
| Frequência | 1 vez por ano | a cada varredura agendada ou build | enquanto o programa estiver aberto | em ciclos, pela ordem de risco, e após mudança relevante |
| Falhas de autorização e lógica de negócio IDOR/BOLA | sim, dentro do período do teste | limitado: não conhece a regra do negócio | depende do pesquisador | sim, com agentes de autorização e de regra de negócio |
| Testes autenticados com vários perfis | sim, com as contas fornecidas | sim | depende do acesso que o programa dá | sim, cada perfil contra as rotas da matriz de autorização |
| Prova de exploração reproduzível | sim, no relatório final | alerta com a requisição, sem o caminho de ataque | sim, no relato do pesquisador | requisição e resposta em cada achado |
| Quem filtra falso positivo | o consultor | seu time | a triagem do programa, depois seu time | especialista Hify, antes de chegar ao seu time |
| Reteste da correção | se estiver no contrato | na próxima varredura | depende do pesquisador | no mesmo caminho de ataque, com o antes e o depois |
| Mostra o que não foi testado, e por quê | depende do relatório | mostra o que rastreou, sem o motivo | não | sim, rota por rota, com o motivo |
| Encaixa no deploy CI | não | sim | não | sim, um passo no pipeline dispara um teste direcionado |
| Previsibilidade de custo | valor fixo por projeto | assinatura | variável, pago por achado | por aplicação, conforme o plano; não varia com o número de achados |
| Rede interna, engenharia social e teste físico | sim, quando contratado | não | raramente no escopo | fora do escopo da plataforma |
Comparação geral: contratos de pentest, scanners e programas de bug bounty variam. Para rede interna, engenharia social e teste físico, o pentest tradicional continua sendo o caminho.
Ver um achado do escopo ao retesteVeja o que seu time recebe em cada achado: requisição, resposta, impacto, correção e a prova de que a correção funcionou. Caso fictício, com dados sintéticos.
Alvo, nível de acesso, contas de teste e rotas proibidas ficam registrados antes da primeira requisição. O que está fora da lista, a política bloqueia.
O agente de autorização testou três hipóteses: uma se reproduziu, duas foram descartadas. Seu time recebe o que se sustenta, não uma lista de suspeitas.
Requisição e resposta ficam no achado, com dados pessoais mascarados. O desenvolvedor reproduz sozinho, sem pedir detalhes a ninguém.
Um especialista Hify confirma a falha e descreve o que vaza, quem é afetado e o que o ataque exige. A severidade chega justificada, pronta para priorizar.
A orientação aponta a causa e as 11 rotas com o mesmo padrão. O achado vira ticket com dono, e o prazo segue a política de SLA que você definiu.
A mesma requisição roda de novo depois do ajuste. O achado só fecha com prova no histórico: 200 OK antes, 404 depois.
Só H-01 segue para validação. As descartadas ficam no registro da execução.
Requisiçãosessão de conta-a
GET /v1/accounts/7f3c…e21 Authorization: Bearer ‹sessão conta-a›
O ID 7f3c…e21 pertence a conta-b. A sessão é de conta-a, e a API responde mesmo assim.
Respostadados de conta-b
HTTP/1.1 200 OK
{
"id": "7f3c…e21",
"nome": "Mar*** S***",
"email": "m***@exemplo.com.br",
"cpf": "***.***.***-12"
}
Por que Alta, e não Crítica: expõe dados pessoais de qualquer cliente, mas exige sessão válida e permite só leitura.
Validar no servidor se o account_id pertence à sessão antes de responder. Responder 404, e não 403, para não confirmar que o ID existe.
if (account.id !== session.account_id) {
return res.status(404)
}
11 rotas recebem identificador de conta e seguem o mesmo padrão
Na demonstração, você percorre este achado no painel, do escopo ao reteste. O especialista Hify valida, AppSec prioriza, Engenharia corrige e o CISO acompanha.
Agendar demonstraçãoVocê define hosts, rotas, contas de teste, janela e limite de requisições. Toda requisição fica registrada, e o que está fora do escopo é bloqueado pela política antes de sair.
Agente autônomo assusta porque decide o próximo passo sozinho. Na Hify, ele só alcança o que está na allowlist, com as contas de teste que você cadastrou, dentro da janela e do limite. Seu WAF reconhece o tráfego pelos IPs fixos e pelo cabeçalho da execução, e o que está na denylist nunca é tocado.
Quem usa AppSec monta o escopo, o CISO aprova e a infraestrutura libera os IPs no WAF.
Escopo e guardrails
Aprovado por CISO (exemplo) em 11/09
Relatório no fim do teste não mostra o que o agente tentou no caminho. Na atividade, cada hipótese aparece com rota, resposta e resultado, e o especialista revisa o que se sustenta. Se algo sair do previsto, seu time pausa a execução por aqui.
Quem usa O CISO acompanha e pausa se precisar. AppSec audita o registro.
Atividade
Início 25/09 22:00 · 7 agentes · 5 req/s
Antes de aprovar um agente, o time de risco quer saber para onde vão os dados. Estas são as cinco perguntas que o questionário de segurança da Hify responde por escrito.
Pedir o questionário na demonstraçãoAs cinco respostas vêm por escrito no questionário de segurança, entregue sob NDA.
Ticket com dono e prazo, alerta no canal do time, link para o PR da correção e reteste quando o deploy sai. Sem planilha, sem PDF perdido no e-mail.
Ticket e alerta nascem quando o especialista valida. O backlog recebe achado reproduzido, não alerta bruto.
Limite diário burlado com requisições paralelas
especialista Hify (exemplo), 22/09
Regra de envio Crítica validada: ticket em SEG, alerta em #seguranca-appsec
No projeto do time dono, com evidência, correção sugerida e o prazo da sua política. Ninguém redigita achado de PDF.
SEG-231 · Limite diário burlado com requisições paralelas
Descrição
O time fica sabendo no dia da validação, não na reunião do mês. O alerta leva ao achado e ao ticket.
Hify app 22/09
Novo achado validado: HFY-0157 Crítica em api.exemplo.com.br/v1 (homologação) · dono time de Cartões · prazo 29/09
1 resposta · time de Cartões
O PR da correção aparece no achado. AppSec acompanha o andamento sem cobrar status em reunião.
Trava de limite diário por conta (#812)
fix/seg-231 para main
Depois do merge, o pipeline faz o deploy em homologação e chama a Hify para refazer o ataque. O achado só fecha com a prova no histórico.
Ao entrar na main
$ hify run --app api.exemplo.com.br --finding HFY-0157 --wait
reteste agendado para o merge
Depois do deploy, o reteste refaz o mesmo caminho de ataque. Se não reproduz, o achado fecha com a prova no histórico. Em retesteCorrigido
O achado validado chega ao Claude Code, ao Cursor ou ao Codex com a requisição, a resposta e a correção sugerida. O agente prepara o PR, um desenvolvedor revisa e a Hify refaz o ataque antes de fechar o risco.
Claude Code
Cursor
Codex
GitHub Copilot
Windsurf> corrija o achado HFY-0157 hify.get_finding HFY-0157 · Crítica · validado por especialista Limite diário burlado com requisições paralelas POST /v1/transfers · evidência e correção sugerida editando src/transfers/limit.ts testes 42 passaram PR aberto #812 Trava de limite diário por conta hify.request_retest reteste agendado para o merge
JiraAbre no projeto do time dono, com evidência, correção sugerida e prazo. O estado do achado acompanha o ticket.
Slack
Microsoft TeamsAviso no canal do time quando um achado é validado e lembrete quando o prazo está perto de vencer.
E-mail
WhatsAppSlackO especialista da Hify fala direto com o seu time: resumo de cada ciclo por e-mail, aviso imediato de risco crítico no WhatsApp e conversa no canal compartilhado do Slack.
GitHub
GitLab
GitHub ActionsGitLab CIO PR da correção fica ligado ao achado, com o check de reteste. Um passo no pipeline dispara um teste direcionado depois do deploy.
Claude CodeCursorCodexGitHub CopilotWindsurfPelo servidor MCP da Hify, o agente lê o achado validado com a evidência, prepara a correção e pede o reteste.
PDF executivo, técnico ou atestado para clientes. Achados em CSV e requisições da execução em HAR.
Papéis Admin, AppSec, Desenvolvedor e Leitura. Quem mudou escopo, estado ou acesso fica no log de auditoria.
Depois do deploy em homologação, um passo no pipeline testa de novo só as rotas que mudaram. Os webhooks são assinados: seu sistema confere a origem de cada evento.
env: HIFY_TOKEN: ${{ secrets.HIFY_TOKEN }} jobs: teste-hify: needs: deploy-homologacao runs-on: ubuntu-latest steps: - name: Hify nas rotas alteradas run: > hify run --app api.exemplo.com.br --scope changed-routes --wait
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" } }
Não precisa abrir tudo de uma vez. A primeira execução cobre uma aplicação, só pela visão externa ou com duas contas de teste. As outras entram depois, cada uma com a sua cadência, na ordem de risco que seu time define.
A plataforma rodando num ambiente parecido com o seu: uma execução, um achado com prova, o reteste e o relatório.
O que você abre nesta etapa
Você cadastra as URLs e cria contas de teste por perfil. Importar o OpenAPI é opcional. O NDA vem antes de qualquer dado sensível.
Escopo · exemplo
Os agentes testam dentro do escopo e um especialista revisa o que eles reproduziram. Os achados aparecem no painel com prova, severidade e dono.
No painel · HFY-0142 · exemplo
Cada aplicação ganha uma cadência pela ordem de risco: no exemplo, a API a cada dois meses e a web a cada quatro. Rota nova no escopo recebe um teste direcionado.
Cadência · próximos 12 meses
Teste direcionado na rota nova POST /v1/pix/devolucao
Exemplos com dados fictícios.
Não há tabela de preço pública. O valor do plano depende destes três pontos e é definido depois da demonstração.
Quanto mais acesso, mais o teste enxerga.
Uma empresa de produto, com dois fundadores construindo a plataforma. Um já levou uma startup do zero até a venda; o outro vem da consultoria em segurança de agentes de IA. Ao lado deles, como advisor, um membro do conselho de administração do Nubank.
Cofundador e CEO
Igor fundou a Hackr Ads em 2019 e levou a empresa a 45 mil clientes e a R$ 380 milhões por mês em anúncios geridos pela plataforma. Em 2022, vendeu a Hackr Ads para a Conta Simples. Na Hify, aplica o que aprendeu construindo software usado todo dia por milhares de empresas.
Cofundador e Chief AI Officer
Lucas trabalha com segurança de agentes de IA e prestou consultoria nessa área para a Dreamer, cuja equipe depois foi incorporada pela Meta (Facebook). Na Hify, cuida dos agentes que atacam os sistemas dos clientes: o que cada um pode testar, como é controlado e como o resultado chega ao especialista.
Advisor e membro do conselho de administração do Nubank
Rogério é membro do conselho de administração do Nubank desde 2021 e preside o comitê de auditoria e riscos. Antes, foi sócio de auditoria da PwC e diretor financeiro da Bunge Brasil, do Unibanco, do Itaú Unibanco e do HSBC Brasil. Conhece de perto o que um conselho pergunta quando o assunto é risco.
Respostas curtas sobre como a plataforma testa, valida e guarda o que encontra. O detalhe do seu caso fica para a demonstração.
Não, complementa. Scanner e DAST procuram padrões conhecidos, uma requisição por vez. A Hify segue caminhos de várias etapas com sessão real, como usar a sessão da conta-a para ler o registro da conta-b, usa a regra de negócio da aplicação (quem pode ver, aprovar ou transferir o quê) e entrega cada achado com a prova: requisição, resposta e impacto.
Em aplicações web e APIs, a plataforma testa com muito mais frequência que um pentest anual, e todo achado passa por um especialista antes de virar Validado. Rede interna, engenharia social e teste físico ficam fora; para eles, o pentest manual continua no seu plano.
No ambiente que você define no escopo, com janela de horário, limite de requisições por segundo e métodos destrutivos bloqueados. Os exemplos desta página usam homologação.
Onde ficam, por quanto tempo e quem acessa são respondidos no questionário de segurança, sob NDA, antes de qualquer dado sensível. Na evidência, dados pessoais aparecem mascarados, como m***@exemplo.com.br.
Primeiro o agente reproduz o sinal com outros IDs e outra conta. Depois um especialista confere a regra de negócio, avalia o impacto e descarta o falso positivo. Só vira Validado o que foi reproduzido e revisado, e a linha do tempo do achado registra quando o especialista validou.
Não para começar. Dá para partir da visão externa ou de duas contas de teste, que já mostram se uma conta consegue ler dados da outra. Código entra quando você autorizar, e o teste passa a enxergar mais.
Jira, com o ticket no projeto do time dono e o estado do achado acompanhando o ticket. Slack e Microsoft Teams, com aviso quando um achado é validado e lembrete de prazo. GitHub e GitLab, com o PR ligado ao achado e o check de reteste, além de GitHub Actions e GitLab CI. Também webhooks assinados, API REST e exportação em PDF, CSV e HAR. O acesso ao painel usa SSO (SAML ou OIDC), papéis Admin, AppSec, Desenvolvedor e Leitura, e log de auditoria.
Sim. Um passo no CI, como hify run --app api.exemplo.com.br --scope changed-routes --wait no GitHub Actions ou no GitLab CI, dispara um teste direcionado nas rotas que mudaram. Os ciclos completos seguem a cadência de cada aplicação.
Nenhum achado não quer dizer ambiente seguro. O relatório registra o que foi testado, com quais acessos, e o que ficou de fora e por quê, como uma rota que exige MFA de hardware.
Não. Os achados ficam entre a Hify e o seu time, sob NDA. Nada que identifique sua empresa é publicado sem autorização por escrito.
Por aplicação, conforme o plano. O peso de cada uma depende da complexidade: quantas URLs, APIs e integrações ela envolve. Frequência e nível de acesso também contam. O valor do plano é definido depois da demonstração; não há tabela pública.
Conte quantas aplicações estão em produção e com que frequência vocês publicam. Na demonstração, você acompanha o ciclo inteiro, do escopo ao reteste.
Revise e envie a mensagem para [email protected]. Se nenhum app de e-mail abrir, copie o texto abaixo e mande para esse endereço.