Skip to content
use-cases / weekly-canary-agent / hero
CRON · AGENT · SNAPSHOTS

A weekly canary that tries to break production

Every Sunday at 7am a hoody-cron entry wakes a hoody-agent in a fresh container. The agent's prompt: behave like a malicious user. It probes login forms, fuzzes the API, tests the rate limiter — against a snapshot of prod, never prod itself. By 9am it writes a findings report to a URL.

Read the agent docs
use-cases / weekly-canary-agent / mechanism

How the canary wakes, attacks, and retires

Three HTTP calls in sequence. The cron entry triggers a snapshot of prod, an agent container is spawned against the snapshot with an attack prompt, and the report gets PUT to a URL when the agent exits. No long-running infrastructure between Sundays.

1 · cron.hoody.com
POST · sunday 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 first, attack second
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"}
report, then retire
3 · files.containers.hoody.com
PUT · static report
# 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

The three pieces — Cron, Container Snapshots, the Agent service — already exist in the Kit. Wiring them together is one shell script. There is no canary platform to install.

use-cases / weekly-canary-agent / sunday

What the agent actually does on a Sunday

Two hours, top to bottom. The agent reads its own prompt as a runbook. Each finding is documented with reproduction steps so the engineer who reads it on Monday can verify in under a minute.

  1. 07:00WAKE

    Cron fires. The runner script POSTs to the snapshots endpoint and then to the agent service. A canary-2026-05-03 alias is created.

  2. 07:02RECON

    Agent opens hoody-browser against the snapshot URL. It enumerates routes from the OpenAPI spec and the homepage links, building a map of the surface.

  3. 07:30ATTACK

    OWASP top 20 in order: SQLi, XSS, IDOR, SSRF, race conditions, rate-limit bypass. Before each risky request, the agent takes a sub-snapshot so a destructive payload cannot poison subsequent tests.

  4. 08:45TRIAGE

    Each non-error response gets a severity, a reproduction recipe, and a suggested fix. Findings the agent itself can verify with a second request get a confidence score.

  5. 09:00REPORT

    Report PUT to /canary/last-sunday.html. Container destroyed. Cron exits 0. The next entry won't fire for another seven days.

Two hours of Sunday morning produces a static report your team can read with a coffee. There is no dashboard to log into and no agent to babysit while it works.

use-cases / weekly-canary-agent / powers

Why a snapshot is the unfair advantage

A pen-tester cannot let an agent loose on production. With Container Snapshots, the agent has an exact clone to break — and the live system never feels it.

ISOLATION

Prod is never the target

The snapshot the agent attacks is a copy-on-write clone of prod's filesystem and config. A successful exploit modifies the clone, not the live container. When the agent retires, the clone retires with it.

REPLAY

Every finding can be re-run

The snapshot is retained for thirty days. The reproduction steps in the report point at a snapshot URL, so an engineer can re-run any payload on Monday against the exact state the agent saw on Sunday.

BLAST RADIUS

No fuzz contaminates real data

When the agent submits a thousand garbage payloads, they end up in a database that gets thrown away. No support ticket about a phantom user, no real refund accidentally credited, no audit log full of the agent's experiments.

use-cases / weekly-canary-agent / economics

What the contract used to look like

The standard answer to 'we should pen-test the app' is a $40,000 annual engagement that covers two weeks of someone else's calendar. The canary runs every Sunday on the flat-rate Hoody server you already rent — cron is the trigger, not the billing unit.

BEFORE · ANNUAL CONTRACTtwo engagements per year
$40,000 / yr

Two two-week windows of an external pen-test firm scoping, scanning, and writing a PDF you read once. Findings six months stale by the time the next contract starts.

  • schedule2× / yr
  • report cadencePDF · 6mo stale
  • cost$40,000+
you read it once, then forget it
AFTER · WEEKLY CRONone cron entry, fifty-two reports a year
1× cron entry

A managed Hoody Cron entry. A short shell script. The snapshot lives thirty days. The container exists for two hours. There is no firm to hire and no calendar to coordinate.

# crontab.weekly-canary0 7 * * 0 /usr/local/bin/canary-run.sh
fifty-two findings reports a year

Cost framing. The $40k figure is a typical mid-market pen-test engagement, not a Hoody quote. The canary runs on the flat-rate server you already pay for; server cost is the same whether the agent runs two hours or twenty. The agent's LLM calls go through the Hoody AI Gateway (provider cost + 5% markup, drawn from AI Balance) or your own provider key (BYO path, provider bills separately). Two balances, firewalled: General Balance funds the server; AI Balance funds the gateway. A runaway agent can't drain your infrastructure budget.

use-cases / weekly-canary-agent / punchline

Every Sunday morning, an agent earns its keep by trying to break what you built.

CADENCE52× / yrone report every sunday — never six months stale
ATTACK SURFACEsnapshotprod is never the target — the clone is
OPERATIONS1× cronno platform to install · no firm to schedule
use-cases / weekly-canary-agent / replaces

What this replaces

The standard tools when you want continuous adversarial pressure on your own product. Each one charges you a contract, a platform seat, or a bug-bounty marketplace. The canary runs on the flat-rate Hoody server you already pay for; the cron line is configuration, not a billing unit.

  • red-team contractorsTwo engagements a year for a six-month-stale PDF
  • Synack pentestingCrowdsourced testers and a per-seat platform fee
  • custom chaos-monkey scriptsA weekend project nobody owns or upgrades
  • manual weekly QA passesAn engineer's monday morning every week, forever
  • Gremlin chaos engineering platformA platform seat for what is mostly cron + container snapshots
  • BugBounty as a servicePays per finding only after a finding ships to prod
use-cases / weekly-canary-agent / cta

Wire the cron, point it at a snapshot, give the agent its prompt — and read the findings on Monday with your coffee.

Read the agent docs
use-cases / weekly-canary-agent / related

Read the others