Break locally first: security review on your machine

The idea in one paragraph

"Break locally first" means looking for security weaknesses on your own machine, against your own local copy of the app, before the code reaches a shared environment or production. Paqad supports this with a security review workflow your AI tool can run on request. It reviews the code, runs a few helper scripts, and writes a playbook of test commands for you to run yourself against localhost. It is a structured self-review that helps you harden code before a professional penetration test. It does not replace one, and it does not prove the app is secure.

When the security review runs

It runs when you ask for it. Prompts such as "run a pentest", "security audit" or "check the app for vulnerabilities" are routed to the pentest workflow, and "retest" requests to pentest-retest. See Workflow routing.

It does not start by itself because a task touches login or payment code, and paqad-ai doctor does not run it. The security capability that holds these instructions is switched on automatically whenever the coding capability is on, and cannot be toggled on its own. See paqad-ai capabilities.

What "local" means in practice

• The playbook is written, not run. The workflow writes docs/pentest/<timestamp>-local-playbook.md with example curl commands per suspected problem, each with the response you should expect if the app is safe. The instructions say the playbook is never executed automatically and must never be pointed at production.
• Some checks do touch a running app. If a target address is available (from your request, APP_URL in .env, or the project profile), a helper script sends plain GET requests to a short list of paths such as /, /admin and /.env and records the status codes. The instructions also ask the AI to probe security headers, CORS, error pages, redirects and login rate limiting (about ten quick requests). Make sure that address is a local or test instance. With no address, the step is recorded as blocked and the run continues.
• Dependency checks may use the network. Audits run through your package manager (npm audit, pnpm audit or composer audit), which contact their registries. The workflow can also look packages up in the public OSV vulnerability database (api.osv.dev), which means sending package names and locked versions.

Who does what

Part	Done by
Following the steps, reviewing code for each category, writing findings and the playbook	The AI, following Paqad's written instructions (model judgment)
Dependency audits, pattern searches for secrets, route listing, status-code probes, progress tracking	Scripts, whose output the AI then interprets
Running the playbook, deciding what is a real problem, fixing it	You

Because the core of the review is AI judgment, two runs can differ, and a clean report does not mean there are no problems. Treat findings as leads to confirm.

What it does not do

• It does not block your work. No setting in 1.91.1 stops implementation until a security review is clean. The require_adversarial_review and escalate_security_findings settings exist in .paqad/.config, but paqad-ai config effective lists no running code that reads them.
• It does not run a separate, fuller scan in your CI pipeline.
• It does not attack a live system for you.

Where to go next

The steps, outputs and retest flow are described in The security review workflow. How the checks relate to OWASP guidance is in How the checks relate to OWASP. For what Paqad stores and sends in general, see Security.