AI Security Auditing, Part 1: Set Up Your AI Agent to Audit Your Code

AI Security Auditing series — Part 1 of 5. Part 1: Setup · Part 2: Authentication · Part 3: API & OWASP · Part 4: Injection & XSS · Part 5: Runtime detections

This series walks through auditing a real application's security using the AI coding agent you already have open — one threat category at a time, all of it local, none of it uploaded. By the end you'll have found the vulnerabilities in your code and wired up the runtime detections that catch anyone trying to exploit them.

Part 1 is the setup: getting your agent ready and running one small audit so you can see the whole loop end to end. If you want the big-picture overview first, read How to audit your app's security with AI. Otherwise, let's set up.

What you need

Two things:

1. An AI coding agent that can read your repository. Claude Code, Cursor, Codex, or similar. Open it at the root of your project — the audit is only as good as the code the agent can see.
2. The SecureNow package installed in the project (optional account login for the detection half).

That's the entire toolchain. No SaaS onboarding, no scanner to configure.

Install

In your project's terminal:

npm install securenow

Then, optionally, connect it to your free account so generated detection rules reference your real setup:

npx securenow login

Why "optional"? The audit has two halves. The code-findings half reads your files and needs no account at all. The detection-and-mitigation half proposes runtime rules, and login lets those rules ground themselves in your actual rule names and telemetry columns. If you're only after the code audit today, skip the login and come back to it in Part 5.

How the audit works

Before running anything, it helps to understand the shape of what's about to happen. Each SecureNow threat-modeling prompt tells your agent to do four things:

1. Inventory the code relevant to one category — for authentication, that's your login routes, session middleware, password-reset flow, and auth config.
2. Enumerate the concrete threats that apply to your implementation.
3. Audit your real files against each threat, recording every weakness with a file:line and a severity.
4. Write the results to disk as a report.

The whole thing runs in your environment. The agent reads local files and writes local files. Your source code is never sent to SecureNow — the only network call is the optional CLI talking to your own account.

Run your first audit

Let's do a full dry run so you see the output before it matters. Go to /threat-modeling and pick a category — for a first run, choose one you already understand well so you can sanity-check the findings. Authentication is a good first target for most apps.

1. Open the category page and click Copy prompt.
2. Paste it into your agent, opened at your project root.
3. Let it run. It will read your code, enumerate threats, and audit each file.

When it finishes, it writes four files into a new folder:

threat/<category>/
├─ <category>-code-findings.html        # the code audit — open this
├─ <category>-code-findings.md
├─ <category>-detection-mitigation.html # rules & defenses — open this
└─ <category>-detection-mitigation.md

Double-click the two .html files. They're self-contained — no server, no internet, no trackers — so they open straight in your browser and work offline. The .md versions are for diffing in version control.

Read the output like a reviewer, not an oracle

Open <category>-code-findings.html first. You'll see a severity-ranked list, each item pointing at a file:line with the risk and the described fix.

Two habits will keep you honest:

• Confirm the high-severity findings before acting. The AI is a fast, thorough first reviewer — treat its output as a prioritized list to verify, not a verdict. Most findings will be real; the occasional false positive is the cost of speed.
• Don't expect it to touch your code. The prompt is read-only by design. It describes fixes; you apply them. That keeps you in control of every change.

Now open <category>-detection-mitigation.html. This is the other half — the detections that would catch each threat in live traffic. Skim it now; we'll turn it into running rules in Part 5.

Put the reports in version control

Commit the threat/<category>/*.md files. Two reasons:

• You get a diff of your security posture across releases — new findings show up in the PR that introduced them.
• You can wire the audit into CI so pull requests touching sensitive code get re-checked automatically. Because the prompts are free and local, there's no per-run cost to worry about.

What's next

You've now run the full loop once. In the rest of the series we go deep on the categories that matter most:

• Part 2 — Audit authentication & sessions: credential stuffing, brute force, session fixation, MFA bypass, password-reset and magic-link abuse.
• Part 3 — Audit your API against the OWASP API Top 10: BOLA, broken auth, sensitive business flows, SSRF, and inventory drift.
• Part 4 — Find injection, XSS & SSRF: SQLi/NoSQLi, command injection, SSTI, and client-side injection.
• Part 5 — Turn findings into runtime detections: make the audit permanent.

Start with the category that carries the most risk for your app. Browse all 25 free prompts →