Launching a Security Review

Prompt patterns for asking an AI agent to review your repository, prioritize findings, and suggest fixes without replacing a professional audit.

An AI agent can read your repository and surface likely security issues faster than a manual skim. Treat the result as a triage aid: it can miss real bugs, over-flag harmless code, and it is not a substitute for dedicated security testing, threat modeling, or compliance sign-off.

Read Understanding Security with AI agents first if you are new to the threat model. The prompts below are starting text; add your stack, deployment model, and what is in scope (for example backend only, no third-party SaaS).

Limits

Models do not “run” your production environment. They infer from source and config. Verify every finding in code and in your real deployment. Rotate secrets if you suspect exposure, even if the report was noisy.

Before you prompt

Say what matters. Mention language, framework, how the app is exposed (public web API, internal service, CLI), and any compliance context (PII, PCI) in one short paragraph.

Prefer read-only first. For a pure review, Plan mode (or equivalent) keeps the session analytical so you get a report before anyone applies patches.

Ask for a structured answer. Request severity (for example critical / high / medium / low / informational), location (file path and symbol or route), why it matters, and concrete remediation or references (OWASP, CWE) when possible.

Prompts you can copy and adapt

Full repository pass

Use when you want a wide first cut across the codebase.

You are doing a security review of this repository. Assume the code may ship to production.

Scan the codebase for common web and application security issues, including but not limited to:
injection (SQL, command, XSS), broken access control and IDOR, insecure deserialization,
misconfigured auth (sessions, JWTs, cookies), secrets or API keys in source, unsafe use of
filesystem or subprocess, SSRF, path traversal, weak crypto or misuse of TLS, dependency
risk (deprecated or risky patterns), verbose errors or debug endpoints, and CORS/CSP issues.

For each finding, output:
- Severity (critical / high / medium / low / informational)
- Location (file path and brief pointer: function, route, or line range if you can)
- Description of the risk in plain language
- Suggested fix or mitigation
- Confidence: high / medium / low, and what you would verify manually

If something cannot be determined from the repo alone, say what is unknown and what to check in deployment config or infrastructure.
List "no issues spotted" areas only briefly. Prioritize the top issues first.

Focused passes

Use when you already know where risk lives or you want a second opinion on one layer.

Authentication and authorization

Review authentication, authorization, and session handling in this repo. Look for missing
checks on sensitive routes, IDOR patterns, privilege escalation, insecure cookie or JWT
settings, and trust of client-supplied identifiers. Output findings with severity, file paths,
and concrete code-level fixes.

Secrets and configuration

Search the repository for secrets, API keys, tokens, private keys, and unsafe defaults in
config files. Include example env vars that should never be committed. For each hit, say
whether it looks like a real secret or a placeholder, and recommend rotation or cleanup steps.

Dependencies and supply chain

Review package manifests and lockfiles. Flag outdated, deprecated, or commonly exploited
dependencies where you can infer from versions. Suggest upgrades or replacements and note
where you need `npm audit`, OSV, or GitHub Dependabot to confirm.

API and input surface

Focus on HTTP or RPC handlers: input validation, file uploads, deserialization, rate limiting,
and error handling that might leak internals. Tie each finding to a route or handler name and
suggest validation or hardening patterns appropriate to this stack.

Follow-up after a first report

From your previous security findings list, take only the critical and high items. For each one,
propose the smallest safe code change to mitigate it, and list any tests or manual checks I
should run to confirm the fix. Do not introduce new features; security fixes only.

Getting better results

Paste constraints: Do not suggest changing our public API contract. We use Supabase RLS; check that assumptions.
Narrow the tree: Limit the review to /apps/api and /packages/auth.
Run again after fixes: a second pass on the same prompt helps catch regressions and false negatives.

Human review still wins

Use the agent to shorten the list you must think about, not to replace judgment. When severity is high or you handle regulated data, involve your security process before you rely on chat output alone.

Exercise: security-demo

Try the prompts on the security-demo sample shipped with this workshop. It is a small .NET 10 minimal API in its own repository. The code is intentionally vulnerable so you have something real to fix. Do not deploy it or expose it to untrusted networks.

dotnet run

Open that folder in your agent-enabled editor or terminal and point the agent at it.

Run a review using the patterns above. Start with the full repository pass prompt. Add context: ASP.NET Core minimal API with SQLite, deliberately broken teaching sample, the model should be thorough.

Use focused passes where it helps (for example API and input surface plus secrets and configuration) so you do not miss whole categories.

Fix findings in order of severity. Apply the smallest safe changes, then re-run the same review prompts until the agent reports no critical or high issues (or only items you can justify as false positives). Verify fixes yourself: run the app, exercise the endpoints, and confirm behavior.

Optional check: ask for a final pass with assume this will ship to production and compare against your own reading of Program.cs and DemoDatabase.cs.

The goal is not a perfect pentest report. It is to practice launching reviews, structuring prompts, and closing the loop until you are confident nothing obvious remains.