Secure a Next.js App with SecureNow Using This AI Onboarding Prompt

A copy-paste prompt that lets an AI coding agent install SecureNow, wire Next.js instrumentation, verify traces and logs, deploy to AWS, simulate attacks, and prove firewall blocking with human approval gates.

May 18, 2026·10 min read
nextjs securenow ai onboarding prompt

Secure a Next.js App with SecureNow Using This AI Onboarding Prompt

Most security onboarding docs stop at "install the package." That is not enough for a developer who needs proof.

For a Next.js app, the real checklist is longer:

  • install the latest SecureNow npm package.
  • log in and create or select the SecureNow app.
  • wire instrumentation.ts.
  • make sure next.config.* externalizes the SecureNow server package.
  • verify local traces and logs.
  • capture redacted request bodies.
  • capture multipart upload metadata without file contents.
  • generate production runtime credentials.
  • deploy to a real Node.js runtime.
  • simulate normal and hostile traffic.
  • investigate traces with SecureNow forensics.
  • block the test IP.
  • prove the same browser now receives a 403.

That is a lot of small steps, and small steps are where onboarding gets brittle. So we turned the Next.js AWS lab into a copy-paste agent prompt.

Use it with Codex, Cursor, Claude, or any coding agent that can edit files and run terminal commands. It automates most of the tutorial while stopping for the steps that should stay human-controlled: browser login, AWS cost approval, screenshots, blocking your own IP, and cloud cleanup.

If you want the case study behind this prompt, read A Next.js AWS App That Investigates And Blocks Its Own Attack.

What The Prompt Does

The full prompt gives the agent an end-to-end mission:

  1. Inspect the Next.js project.
  2. Install securenow@latest.
  3. Run npx securenow login and wait for browser auth.
  4. Run npx securenow init.
  5. Merge instrumentation.ts and next.config.* changes if the initializer cannot patch safely.
  6. Add a simple /api/health route if the app does not have one.
  7. Build and test locally.
  8. Generate production runtime credentials.
  9. Optionally deploy to AWS EC2 with AWS CLI.
  10. Simulate normal and hostile traffic.
  11. Verify traces, logs, redacted JSON bodies, multipart metadata, and security signals.
  12. Run SecureNow forensics from CLI or MCP.
  13. Ask for approval before blocking your current public IP.
  14. Add an app-scoped /32 block.
  15. Prove the live app returns 403 Access Blocked - Security Alert.
  16. Ask before unblocking and cleaning up AWS resources.

The most important part is the approval model. The prompt tells the agent not to expose secrets, not to block you early, and not to delete cloud resources without asking.

Before You Paste It

You need:

  • Node.js 20 or newer.
  • npm.
  • a Next.js app.
  • a SecureNow account.
  • AWS CLI configured if you want the full AWS demo.
  • a terminal with ssh and scp if deploying to EC2.

Choose one mode:

ModeUse It When
protect-existingYou want to protect a real Next.js app and verify SecureNow locally.
full-demo-labYou want the full AWS demo with traffic simulation, forensics, blocking, browser 403 proof, and cleanup.

For a customer walkthrough, use full-demo-lab. For a normal product integration, start with protect-existing.

The Full Agent Prompt

Paste this from the root of your Next.js project.

You are my SecureNow Next.js onboarding agent.

Project mode: full-demo-lab
AWS deploy: yes
AWS region: eu-west-3
SecureNow app name: nextjs-aws-lab
Use the included lab simulator if present: yes
Create demo API routes only if this is a demo app: yes
Block my current public IP for the final firewall proof: ask me again immediately before doing it
Cleanup AWS resources at the end: ask me before cleanup

Goal:
Protect this Next.js app with SecureNow and prove that it is sending traces, logs, redacted JSON request bodies, multipart metadata, and enforcing the SecureNow firewall. If AWS deploy is enabled, deploy the app to EC2 with AWS CLI, simulate normal and hostile traffic, use SecureNow CLI or MCP to analyze the evidence, block the controlled test IP, and verify the same browser receives a 403 block page.

Safety rules:
1. Do not print, open, paste, or summarize secrets from `.securenow/credentials.json`, `.securenow/credentials.*.json`, `snk_live_...` keys, JWTs, PEM files, AWS credentials, or `.env` files.
2. Do not commit anything unless I explicitly ask.
3. Do not run destructive git commands.
4. Do not block my IP until you have shown the pre-block app works and asked me for final approval.
5. Do not terminate AWS resources until you have asked me for final cleanup approval.
6. Keep `.securenow/`, `.aws/`, `.next/`, `node_modules/`, `reports/`, `deploy-artifacts/`, `*.pem`, and `*.tgz` ignored by git.
7. When you need me to take a screenshot, pause and tell me exactly what to capture and what to hide.

Phase 1 - inspect the project:
1. Detect whether this is a Next.js app and whether it uses App Router, `src/`, TypeScript, and `next.config.js`, `next.config.mjs`, or `next.config.ts`.
2. Check Node/npm versions and package manager.
3. Check git status and note unrelated existing changes. Do not revert them.
4. Check `.gitignore` and add missing ignore rules for SecureNow, AWS, build output, reports, and private keys.
5. Tell me the plan in a short checklist before editing.

Phase 2 - install and initialize SecureNow:
1. Run `npm install securenow@latest @opentelemetry/api` unless already installed.
2. Print the installed SecureNow version using `node -p "require('./node_modules/securenow/package.json').version"`.
3. Run `npx securenow version`.
4. Run `npx securenow login` and pause until I finish the browser login/app selection.
5. Run `npx securenow init`.
6. If `npx securenow init` cannot safely patch files, merge the required Next.js changes manually:
   - `serverExternalPackages: ["securenow"]` in `next.config.*`.
   - `output: "standalone"` when AWS deploy is enabled.
   - `instrumentation.ts` or `src/instrumentation.ts` with `registerSecureNow({ captureBody: true })` and `await import("securenow/nextjs-auto-capture")`.
7. For API routes used in verification, ensure `export const runtime = "nodejs";`.
8. Run `npx securenow env --json`, `npx securenow doctor`, and `npx securenow test-span`.

Screenshot pause:
Ask me to capture:
- SecureNow app/onboarding page.
- Terminal showing SecureNow version and `env` output with secrets hidden.
- `instrumentation.ts` and `next.config.*`.

Phase 3 - add a tiny verification surface:
1. If no health endpoint exists, add `app/api/health/route.js` or `src/app/api/health/route.js`:
   - `export const runtime = "nodejs";`
   - return `{ ok: true, service: "nextjs-securenow-demo", time: new Date().toISOString() }`.
2. If this is `full-demo-lab` and the project is a demo app, add or reuse routes that exercise:
   - JSON body capture and redaction.
   - multipart metadata capture without raw file contents.
   - SQL injection, XSS, path traversal, SSRF, and hostile multipart filename signals.
3. If a simulator exists, use it. If not, create a small `scripts/simulate-traffic.mjs` that sends normal and hostile requests and writes a report under `reports/`.

Phase 4 - local verification:
1. Run `npm run build`.
2. Start the app locally with the existing dev command.
3. Hit `/api/health`.
4. Run the simulator against `http://localhost:3000` if present.
5. Check SecureNow traces/logs for recent local traffic.
6. Stop the dev server when finished.

Screenshot pause:
Ask me to capture:
- Local app or `/api/health` returning 200.
- Simulator output if used.
- SecureNow trace/log list with recent local traffic.

Phase 5 - production runtime credentials:
1. Run `npx securenow credentials runtime --env production`.
2. Confirm `.securenow/credentials.production.json` exists without opening or printing it.

Screenshot pause:
Ask me to capture only the command success, not the credential file contents.

Phase 6 - AWS EC2 deploy, only if AWS deploy is yes:
1. Ask me to confirm AWS resource creation and possible costs before creating anything.
2. Use AWS CLI in the selected region.
3. Create a unique lab name, SSH key pair, security group, and EC2 instance.
4. Allow SSH only from my current public IP and HTTP from `0.0.0.0/0`.
5. Use the latest Amazon Linux 2023 x86_64 AMI.
6. Package the app while excluding `node_modules`, `.next`, `.securenow`, `.aws`, `reports`, and `deploy-artifacts`.
7. Upload the archive, `.securenow/credentials.production.json`, and a remote bootstrap script.
8. On the server, install Node.js 22 if needed, nginx, PM2, install dependencies, build the standalone Next.js app, copy runtime credentials to `.securenow/credentials.json`, and start PM2.
9. Verify `http://<public-ip>/api/health`, `http://<public-ip>/api/whoami` if present, and PM2 logs.

Screenshot pause:
Ask me to capture:
- AWS instance and security group.
- Public app URL before attack.
- `/api/health` 200.
- PM2 startup logs showing SecureNow tracing, logging, body capture, and firewall enabled.

Phase 7 - simulate traffic:
1. Run normal and hostile traffic against the live public URL.
2. Include normal requests, JSON POST, multipart upload, SQL injection, XSS, path traversal, SSRF, hostile multipart filename, `/admin`, `/wp-login.php`, and `/.env` probes when the demo routes exist.
3. Save the traffic report under `reports/`.

Screenshot pause:
Ask me to capture the simulator output.

Phase 8 - verify SecureNow evidence:
1. Use SecureNow UI guidance and CLI commands:
   - `npx securenow traces list --env production --limit 20`
   - `npx securenow logs list --env production --minutes 30 --limit 50`
   - `npx securenow notifications list --limit 20`
2. Open interesting traces with `npx securenow traces show <trace-id> --env production`.
3. Prove:
   - trace exists for the app.
   - logs exist for the app.
   - JSON body is captured and sensitive fields are redacted.
   - multipart metadata is captured without file contents.
   - attack signal or suspicious path is visible.
4. Record useful trace IDs in the final report.

Screenshot pause:
Ask me to capture:
- Trace list.
- JSON body span with redaction.
- Multipart metadata span.
- Logs filtered to suspicious/security events.
- Notification detail if available. If no notification has fired, explain that traces/logs/forensics are the deterministic proof and notification can be captured later.

Phase 9 - forensics and agentic decision:
1. Run a SecureNow forensics query from CLI or MCP.
2. If MCP is available, prefer MCP for the agentic demo and use write tools only with `confirm:true` and a reason.
3. Query for suspicious requests in the last 30 minutes with IPs, paths, methods, status codes, user agents, trace IDs, and suspected attack type.
4. Summarize the evidence before proposing a block.

Screenshot pause:
Ask me to capture the forensics prompt and result.

Phase 10 - firewall block proof:
1. Get my current public IP.
2. Get the SecureNow app key from `npx securenow env --json` without exposing secrets.
3. Run a baseline firewall test:
   - `npx securenow firewall test-ip <ip> --app <app-key> --env production`
4. Show that baseline is `blocked=false`.
5. Ask me for explicit final approval to block my current public IP for the demo.
6. After approval, add an app-scoped `/32` block:
   - `npx securenow blocklist add <ip>/32 --app <app-key> --env production --reason "Controlled Next.js AWS lab attack simulation"`
7. Run firewall test again and show `blocked=true`.
8. Wait 10 to 30 seconds for app firewall sync.
9. Browse the app from the same network and verify `403 Access Blocked - Security Alert`.
10. Check PM2 logs for a firewall blocked line.

Screenshot pause:
Ask me to capture:
- Baseline `blocked=false`.
- Blocklist add result.
- Post-block `blocked=true`.
- SecureNow blocklist UI row.
- Browser 403 page.
- PM2 firewall block log.

Phase 11 - unblock and cleanup:
1. Ask me before removing the block or cleaning AWS.
2. Remove the test blocklist row.
3. Confirm `/api/health` returns 200 again if the EC2 instance is still running.
4. If approved, terminate the EC2 instance, delete the security group, and delete the key pair.
5. Confirm no secrets or private keys were committed.

Final report:
Give me a concise final report with:
- SecureNow npm version.
- Next.js version.
- Node version.
- SecureNow app name and masked app key.
- AWS region and public URL, if deployed.
- Verification results for traces, logs, body, multipart, firewall.
- Important trace IDs.
- Forensics job/result summary.
- Blocklist entry ID if one was created.
- Whether the test IP was unblocked.
- AWS cleanup status.
- Screenshots still needed, if any.

Short Local-Only Prompt

If you only want to protect an existing app and stop before AWS, use this instead:

Add SecureNow to this Next.js app. Install `securenow@latest`, run `npx securenow login` and pause for my browser auth, then run `npx securenow init`. Merge `instrumentation.ts` and `serverExternalPackages: ["securenow"]` if needed. Add a small `/api/health` Node.js route if none exists. Make sure `.securenow/credentials.json`, `.securenow/credentials.*.json`, `.next/`, `node_modules/`, `reports/`, `.aws/`, `*.pem`, and `*.tgz` are gitignored; do not ignore the whole `.securenow/` directory. Run `npx securenow env --json`, `npx securenow doctor`, `npx securenow test-span`, and `npm run build`. Do not show or commit secrets. Pause and tell me when to screenshot the SecureNow app page, instrumentation files, terminal verification, local `/api/health`, and trace/log evidence.

What To Screenshot

For a public customer walkthrough, capture the evidence in this order:

  1. SecureNow CLI version and env output with secrets hidden.
  2. SecureNow onboarding/app page.
  3. instrumentation.ts and next.config.*.
  4. Local /api/health returning 200.
  5. AWS EC2 instance and security group, if using the full demo.
  6. Live app before attack.
  7. Traffic simulator output.
  8. Trace list.
  9. JSON request body span with redaction.
  10. Multipart metadata span.
  11. Logs filtered to security events.
  12. Forensics query and result.
  13. Baseline firewall test showing blocked=false.
  14. Blocklist add result.
  15. Post-block firewall test showing blocked=true.
  16. Browser 403 page.
  17. Runtime logs showing the firewall block.
  18. Unblock and cleanup proof.

The order matters. If you block your current IP before recording the pre-block app state, your browser will stop loading the app and the demo gets awkward.

What Success Looks Like

At the end of the full demo, you should be able to say:

  • the app is instrumented through the Next.js Node.js runtime.
  • SecureNow receives production traces.
  • SecureNow receives production logs.
  • JSON request bodies are captured with sensitive fields redacted.
  • multipart uploads expose metadata, not raw file contents.
  • suspicious traffic is visible in trace/log evidence.
  • SecureNow forensics can summarize the attack window.
  • the firewall can block a single app-scoped IP.
  • the browser is denied by the same app it attacked.

That last point is the whole story. The agent did not just add an SDK. It proved the app is protected.

Related Reading

Frequently Asked Questions

Can the prompt protect an existing Next.js app?

Yes. Use protect-existing or the short local-only prompt. The agent installs SecureNow, runs login and init, merges instrumentation.ts and next.config changes, adds a tiny health route if needed, then verifies traces, logs, body capture, and firewall status.

Will the agent block my IP automatically?

No. The prompt explicitly tells the agent to ask again before blocking your current public IP. The block step is useful for a controlled demo, but it should happen only after screenshots and explicit human approval.

Do I need MCP for this workflow?

No. The prompt works with the SecureNow CLI first. If MCP is available, the agent can use MCP for the forensics and blocklist demo, but CLI commands are included as the fallback path.

Is this for Vercel or AWS?

The full demo path is for a self-hosted Next.js Node.js runtime on AWS EC2. The local-only path still applies to any Next.js app. Vercel Edge has different runtime constraints and should be handled separately.

Recommended reading

Adding Backend Tracing to a Sentry Stack with OpenTelemetry

If your team uses Sentry for frontend errors and needs backend distributed tracing without doubling the Sentry bill, here's the OpenTelemetry path that doesn't make you choose.

May 9
How to Block Bot Traffic in Express With No Extra Infra

Five approaches to bot blocking in Express, ranked by effort vs. effectiveness. From a 5-line allowlist to a full IP-reputation firewall — all without Cloudflare, AWS WAF, or any new infrastructure.

May 9
How to Block Bot Traffic in Fastify With No Extra Infra

Fastify hooks (onRequest) and the SecureNow preload both work cleanly. Here's the production setup for IP blocking and user-agent filtering.

May 9