Requires Human and Alert Review: what SecureNow won't decide alone

SecureNow decides most things on its own. What it won't decide alone waits in two queues on the dashboard. This is what each one asks, what you can answer, and how to hand both to your own coding agent. Everything below is from real runs on 2026-10-29, with securenow@8.19.

What never waits for you

• Rules armed to block stop a request the moment it matches.
• Automations block, rate-limit or challenge an address when one of their alerts fires.
• An address with a bad reputation that is clearly attacking is blocked as it shows up.
• Every alert's addresses are investigated: an AI reads the requests, the traces and the history, and writes a verdict with its evidence.

The rule behind both queues: when the verdict is only the AI's opinion, SecureNow doesn't block. It asks. A "malicious" verdict creates a block that waits for a yes.

Two queues, two questions

Work Alert Review first. A wrong rule doesn't make one bad row, it makes hundreds: on our own dashboard, one probing rule had produced 125 rows in Requires Human.

Alert Review: is this rule right?

A run lands here in three ways: the rule fired on more than 20 unknown addresses in one run, on 1,000 or more at once (a storm), or it wanted an address blocked that SecureNow treats as your own infrastructure. SecureNow stops investigating that run and usually pauses the rule.

npx securenow review                         # open runs, grouped by root cause
npx securenow review show 1                  # rule, route, addresses, context, its runs
npx securenow review keep <id> --reason "Correct detection" --yes
npx securenow review group 1 --outcome rule_tuning --reason "Guard added" --preview

• Keep it on when the rule is right: credential stuffing from forty addresses should fire on forty addresses. Keeping it on also stops it pausing itself next time.
• Tune it when it catches normal traffic (securenow alerts rules change <id> "..."), then close its runs with --outcome rule_tuning.
• Close or dismiss a run with a reason. Closing never blocks or unblocks anyone.

Requires Human: what do we do about this?

Most rows are one address with a verdict: block recommended, risk 95/100, with the requests and traces behind it. A row waits because the verdict is the AI's (and the AI doesn't block alone), because the rule that caught it is still in test mode (it alerts, never blocks), or because the AI isn't sure. Other rows are plans: tighten this rule, add this exclusion, check this server.

npx securenow human --search my-app
npx securenow human show 1
npx securenow human block 1 --reason "..." --yes
npx securenow human close 1 --outcome deferred --reason "Not worth a block" --yes

The trap: approving a plan to tune a rule only records your decision. It changes nothing. Change the rule first, then approve.

Hand both queues to your agent

Connect SecureNow's MCP server to your agent (the dashboard's Run With Your Agent page has the setup for Claude Code, Codex and Cursor):

claude mcp add --transport http securenow https://api.securenow.ai/mcp \
  --header "Authorization: Bearer $SECURENOW_API_KEY"

The API key is the real limit. Start with the Read Only preset: the agent reads everything and changes nothing, even by mistake. To let it act, add notifications:write, alerts:write and rate_limits:write.

The runbook ships with SecureNow: npx securenow agent prompt patrol prints it. Alert Review first, then Requires Human, up to 10 groups and 10 rows per pass, and a report at the end.

Pass 1: read-only, the whole queue

claude -p "$(npx securenow agent prompt patrol)" --allowedTools "$READ_TOOLS,$DRY_RUN_TESTS"

Five alert runs and 435 rows. Eight minutes and 53 SecureNow calls later:

• All five Alert Review rules were right. It traced the backup-file alert to the scan step of our own attack script.
• A real rule bug: a rule on our API alerted on SecureNow's own SDK telemetry, 3,582 times since August. It wrote a guard, dry-ran it twice, and showed what it would stop (the four SDK exporters) and what would still alert (a probe on the server's address).
• 7 blocks prepared, 3 tuning plans rejected, and where its proof was thin: four of the blocks rested only on the rule's counts, because the traces had expired.
• Nothing was written. Every decision was a prepared call.

Pass 2: allowed to act, one app

claude -p "$(npx securenow agent prompt patrol --search lab-auth --confirm-writes)" \
  --allowedTools "$READ_TOOLS,$DRY_RUN_TESTS,$QUEUE_WRITES"

• Alert Review: it kept the lab's three rules on. One had been paused for ten days only because a run was flagged.
• Requires Human: it closed 20 rows without blocking anyone. Every address was one of our own simulated attackers: it read the attack scripts, checked the traces, and saw the requests arrive from the lab machine with the "attacker" address set as X-Forwarded-For.
• It flagged the one real internet address probing the lab's sign-in pages (150 of 154 requests not found or denied) as a strong block candidate, for a person to decide.
• The lab's queue went from 41 rows to 18, every decision written on its alert with the reason.

We had started this pass twice by mistake. The two sessions noticed each other and split the rows. Don't count on that: make sure a scheduled pass can't overlap the last one (on Linux, wrap it in flock -n).

Schedule it

# crontab -e: every 30 minutes, one bounded pass
*/30 * * * * claude -p "$(npx -y securenow@latest agent prompt patrol)" --allowedTools "mcp__securenow" >> $HOME/securenow-patrol.log 2>&1

On Windows, Task Scheduler runs the same command. Without a machine of your own, Claude Code's /schedule runs it as a scheduled cloud task, reaching SecureNow through a claude.ai connector. Blocking and notifications never wait for the agent, so every 30 minutes is plenty.

Give it autonomy one step at a time:

1. Plans only: Read Only key, the default prompt. You apply its plan.
2. One app: a key that can act, --search <app> --confirm-writes. Read every decision for a few days.
3. Everything: drop --search.

What you just did

Two queues, two questions: is this rule right, and what do we do about this address or plan. Fix rules first, then rows. And let your agent take the routine work, read-only first.