Pular para o conteúdo
use-cases / weekly-canary-agent / hero
CRON · AGENT · SNAPSHOTS

Um canário semanal que tenta quebrar a produção

Todo domingo às 7h, uma entrada hoody-cron acorda um hoody-agent num container novo. O prompt do agente: comporte-se como um usuário malicioso. Ele sonda formulários de login, faz fuzz na API, testa o rate limiter — contra um snapshot da produção, nunca a produção em si. Até as 9h ele escreve um relatório de descobertas em uma URL.

use-cases / weekly-canary-agent / mechanism

Como o canário acorda, ataca e se aposenta

Três chamadas HTTP em sequência. A entrada de cron dispara um snapshot da prod, um container de agente é spawnado contra o snapshot com um prompt de ataque, e o relatório é PUT em uma URL quando o agente encerra. Nenhuma infraestrutura long-running entre os domingos.

1 · cron.hoody.com
POST · domingo 07:00
# A managed cron entry wakes the canary every sunday.POST cron.hoody.com/users/root/entries{ schedule: "0 7 * * 0", // sunday 07:00 command: "/usr/local/bin/canary-run.sh", comment: "weekly-canary-agent"}
snapshot primeiro, ataque depois
2 · api.hoody.com
POST · snapshot + agent
# Snapshot prod first — the agent never touches the live container.POST api.hoody.com/api/v1/containers/$PROD/snapshots{ alias: "canary-2026-05-03" }# Spawn an agent task against the snapshot URL.POST agent.containers.hoody.com/api/v1/agent/tasks{ target: "https://canary-snap.containers.hoody.com", prompt: "behave like a malicious user — top 20 OWASP, fuzz the API"}
relatório, depois aposentadoria
3 · files.containers.hoody.com
PUT · relatório estático
# Agent writes the report as a static html file. Anyone can read it.PUT files.containers.hoody.com/api/v1/files/canary/last-sunday.html# Container is destroyed. The snapshot stays for 30 days.200 OK · 3 findings · agent terminated · snapshot retained 30d

As três peças — Cron, Container Snapshots e o serviço Agent — já existem no Kit. Conectá-las é um shell script. Não há plataforma de canário a instalar.

use-cases / weekly-canary-agent / sunday

O que o agente realmente faz num domingo

Duas horas, do início ao fim. O agente lê o próprio prompt como um runbook. Cada descoberta é documentada com passos de reprodução para que o engenheiro que ler na segunda consiga verificar em menos de um minuto.

  1. 07:00ACORDA

    O cron dispara. O script runner faz POST para o endpoint de snapshots e depois para o serviço de agente. Um alias canary-2026-05-03 é criado.

  2. 07:02RECON

    O agente abre o hoody-browser contra a URL do snapshot. Ele enumera rotas pela spec OpenAPI e pelos links da homepage, montando um mapa da superfície.

  3. 07:30ATAQUE

    OWASP top 20 em ordem: SQLi, XSS, IDOR, SSRF, race conditions, bypass de rate-limit. Antes de cada requisição arriscada, o agente tira um sub-snapshot para que um payload destrutivo não envenene os testes seguintes.

  4. 08:45TRIAGEM

    Cada resposta non-error recebe uma severidade, uma receita de reprodução e um fix sugerido. As descobertas que o próprio agente consegue verificar com uma segunda requisição recebem um score de confiança.

  5. 09:00RELATÓRIO

    Relatório enviado via PUT para /canary/last-sunday.html. Container destruído. O cron termina com 0. A próxima entrada não dispara por mais sete dias.

Duas horas de domingo de manhã produzem um relatório estático que seu time pode ler com um café. Não há dashboard para logar nem agente para babá enquanto trabalha.

use-cases / weekly-canary-agent / powers

Por que um snapshot é a vantagem injusta

Um pen-tester não pode soltar um agente em produção. Com Container Snapshots, o agente tem um clone exato para quebrar — e o sistema vivo não sente.

ISOLAMENTO

A prod nunca é o alvo

O snapshot que o agente ataca é um clone copy-on-write do filesystem e da config da prod. Um exploit bem-sucedido modifica o clone, não o container vivo. Quando o agente se aposenta, o clone se aposenta com ele.

REPLAY

Toda descoberta pode ser re-executada

O snapshot é retido por trinta dias. Os passos de reprodução no relatório apontam para uma URL de snapshot, então um engenheiro pode re-rodar qualquer payload na segunda contra exatamente o estado que o agente viu no domingo.

RAIO DE EXPLOSÃO

Nenhum fuzz contamina dados reais

Quando o agente envia mil payloads de lixo, eles vão parar num banco que será descartado. Sem ticket de suporte sobre um usuário fantasma, sem reembolso real creditado por engano, sem log de auditoria cheio dos experimentos do agente.

use-cases / weekly-canary-agent / economics

Como era o contrato

A resposta padrão para 'precisamos fazer pen-test no app' é um contrato anual de US$ 40.000 que cobre duas semanas da agenda de outra pessoa. O canário roda todo domingo no servidor Hoody de tarifa fixa que você já aluga — cron é o gatilho, não a unidade de cobrança.

ANTES · CONTRATO ANUALduas contratações por ano
$40,000 / yr

Duas janelas de duas semanas com uma firma externa de pen-test fazendo escopo, varredura e escrevendo um PDF que você lê uma vez. Descobertas com seis meses de defasagem quando o próximo contrato começar.

  • agendamento2× / ano
  • cadência de relatórioPDF · 6 meses defasado
  • custoUS$ 40.000+
você lê uma vez e depois esquece
DEPOIS · CRON SEMANALuma entrada de cron, cinquenta e dois relatórios por ano
1× cron entry

Uma entrada gerenciada do Hoody Cron. Um shell script curto. O snapshot vive trinta dias. O container existe por duas horas. Não há firma para contratar nem agenda para coordenar.

# crontab.weekly-canary0 7 * * 0 /usr/local/bin/canary-run.sh
cinquenta e dois relatórios de descobertas por ano

Enquadramento de custo. O número de US$ 40 mil é um engagement típico de pen-test no mid-market, não uma cotação Hoody. O canário roda no servidor de tarifa fixa que você já paga; a conta do servidor é a mesma se o agente roda duas horas ou vinte. As chamadas de LLM do agente vão via Hoody AI Gateway (custo do provedor + markup de 5%, tirado do AI Balance) ou via sua própria chave de provedor (caminho BYO, provedor cobra separadamente). Dois saldos, firewalled: Saldo Geral financia o servidor; Saldo de IA financia o gateway. Um agente descontrolado não pode drenar seu orçamento de infraestrutura.

use-cases / weekly-canary-agent / punchline

Todo domingo de manhã, um agente ganha o pão tentando quebrar o que você construiu.

CADÊNCIA52× / anoum relatório todo domingo — nunca com seis meses de defasagem
SUPERFÍCIE DE ATAQUEsnapshota prod nunca é o alvo — o clone é
OPERAÇÕES1× cronsem plataforma a instalar · sem firma a agendar
Ler a API de snapshots
use-cases / weekly-canary-agent / replaces

O que isto substitui

As ferramentas padrão para quando você quer pressão adversária contínua sobre o seu próprio produto. Cada uma cobra um contrato, um assento de plataforma ou um marketplace de bug-bounty. O canário roda no servidor Hoody de tarifa fixa que você já paga; a linha de cron é configuração, não uma unidade de cobrança.

  • contratantes de red-teamDuas contratações por ano para um PDF com seis meses de defasagem
  • Synack pentestingTesters crowdsourced e uma taxa de plataforma por assento
  • scripts custom de chaos-monkeyUm projeto de fim de semana que ninguém mantém ou atualiza
  • passagens manuais de QA semanaisA manhã de segunda de um engenheiro toda semana, para sempre
  • plataforma Gremlin de chaos engineeringUm assento de plataforma para o que é basicamente cron + container snapshots
  • BugBounty as a servicePaga por descoberta apenas depois que uma descoberta chega à prod
use-cases / weekly-canary-agent / cta

Conecte o cron, aponte para um snapshot, dê ao agente seu prompt — e leia as descobertas na segunda com seu café.

use-cases / weekly-canary-agent / related

Leia os outros