Let Your Coding Agent Block Attackers and Add Rate Limits Over MCP

The person who sees an attack should be able to stop it. Increasingly, that "person" is the coding agent already open in your terminal. With SecureNow's MCP server, the agent can read your production traffic, find out who is behind an attack, propose a block or a rate limit scoped to exactly what's being hit, and apply it when you say yes, without a code change or a deploy.

This guide is the workflow we used in Academy Episode 8 and Episode 9, with every prompt ready to copy.

Connect once

npm install securenow
npx securenow login
claude mcp add securenow -- npx securenow mcp

For Cursor, add the same server to .cursor/mcp.json:

{
  "mcpServers": {
    "securenow": { "command": "npx", "args": ["securenow", "mcp"] }
  }
}

Codex and other MCP clients run the same command, and a hosted endpoint with OAuth is available at https://api.securenow.ai/mcp. Your app needs the SDK running (node -r securenow/register app.js) for rules to be enforced; see the quick start.

The two-step workflow

1. Investigate read-only. The agent gets only tools that read: traces, logs, forensic queries, firewall hits, rule lists. It proposes rules and changes nothing.
2. Approve, then apply. You review the proposal. The agent gets the write tools for this step only, applies exactly what you approved, and verifies it.

In an interactive Claude Code session, the agent asks before each tool you haven't allowed, so you approve the write call itself. In a headless run, pass the tools explicitly. These are the flags from our run:

# step 1: read-only
claude -p "$(cat investigate.txt)" \
  --allowedTools "mcp__securenow__securenow_traces_list,mcp__securenow__securenow_traces_show,mcp__securenow__securenow_ip_traces,mcp__securenow__securenow_logs_list,mcp__securenow__securenow_forensics_query,mcp__securenow__securenow_forensics_query_status,mcp__securenow__securenow_firewall_hits,mcp__securenow__securenow_blocklist_list,mcp__securenow__securenow_rate_limit_list"

# step 2: same session, write tools allowed
claude -p "Approved: apply rules 1 and 2 now, then verify them." --resume <session-id> \
  --allowedTools "mcp__securenow__securenow_blocklist_add,mcp__securenow__securenow_firewall_test_ip,mcp__securenow__securenow_firewall_hits"

Prompt: stop an attack that's happening now

Production for the <app> app is getting hammered right now. Using SecureNow, find out what
is hitting it in the last 10 minutes and who is behind it. Then propose exactly how to stop
it without changing any code: which blocks to add, scoped as narrowly as possible (IP or
range, route, method, environment) and for how long. Don't apply anything yet.

What came back in our run, in about four minutes:

• Signups: 241 addresses in 203.0.113.10–.250, each returning only every ~92 seconds, so the app's own per-IP signup limit never fired. 466 fake accounts so far.
• Export: one address calling GET /api/notes/export about every 265 ms.
• Proposal: block 203.0.113.0/24 only on POST /api/auth/register, block the scraper only on the export, both in production for 24 hours, plus two rate limits in case the attacker switches addresses.

Prompt: approve and verify

Approved: apply rules 1 and 2 (the two blocks) now. Then verify them: test the four addresses
you listed, wait a minute, and show me the firewall hits for the last 5 minutes.

The agent called securenow_blocklist_add twice, then securenow_firewall_test_ip four times: the range on register was blocked, the same address fetching a CSRF token was allowed, the scraper on the export was blocked, and a normal user's address on the export was allowed. The first 403s arrived ten seconds after the first call, and four ordinary users browsing the whole time never saw an error.

Prompt: a limit that isn't working

Someone is still pulling <route> on <app> production, even though we put a
<N>-per-minute-per-IP rate limit on it. Using SecureNow, find out why that limit isn't
stopping it, and propose a rate limit that will, without changing any code.
Don't apply anything yet.

In our run the agent found about 245 requests a minute from 100 addresses, none above 3 a minute: rotating addresses behind one login. It proposed counting by the session cookie, checked that no ordinary client had gone above 5 a minute, and after approval called securenow_rate_limit_create:

{ "method": "GET", "pathPattern": "/api/notes/export", "pathMatchMode": "exact",
  "keyBy": "cookie", "keyName": "lab_auth", "limit": 10, "windowSeconds": 60,
  "environment": "production", "duration": "2h" }

Six seconds later, securenow_firewall_hits showed 60 rate-limited requests from 60 different addresses, all on one cookie. The full story is in Why per-IP rate limits fail against rotating IPs.

More prompts to copy

Protect a new endpoint the day it ships:

We just shipped <METHOD> <route>. Look at its traffic in SecureNow since the deploy and
propose a rate limit that leaves normal use untouched: which key (IP, session cookie,
API key header or global), limit, window and duration. Show me the numbers you based it on.
Don't apply anything yet.

Tighten during an incident, for a bounded time:

Lower the limit on POST /api/auth/login to 3 per minute per IP for the next 2 hours using
securenow_rate_limit_update, then confirm with securenow_rate_limit_test and show me the
rate-limit hits for the last 15 minutes.

Review what your rules are doing:

Using securenow_firewall_hits for the last 24 hours, list every block and rate limit that
stopped traffic on <app>: hits, distinct addresses, last hit. Flag any rule that stopped
nothing in 7 days and any that might be hitting real users.

Clean up after an incident:

List the blocks and rate limits created for <app> today. For each one, show whether it
still stopped traffic in the last hour, then propose which to remove. Don't remove anything yet.

The tools

Write tools refuse to run without an explicit confirm: true and a written reason, so an agent can't change rules by accident while reading, and every change says why it was made.

Guardrails that make this safe

• Read first, write second. Never give the write tools to the investigation step.
• Scope narrowly. Ask for the smallest rule that stops the attack: one range on one route and method, in one environment. Our agent explained why it didn't block the scraper's whole /24: real users shared that range.
• Always set a duration. Incident rules should expire (2h, 24h); make a rule permanent only after watching its hits.
• Verify every change with securenow_firewall_test_ip or securenow_rate_limit_test and the hits.
• Everything is reversible and recorded. securenow_blocklist_unblock keeps the history and the block report; rate limits can be disabled, updated or removed.

Related

• Academy Episode 8: Block attackers in seconds, outside your code
• Academy Episode 9: Rate limits outside your code
• Block an IP, a range or one route without a deploy
• Rate limit per API key, per session or per IP in Node.js
• How to automate IP threat investigation with AI in your SOC
• CLI + MCP · The SecureNow firewall