Security auditing is not a side interest for me. I founded xCyberSecurity, and OWASP-style audits of Laravel apps, WordPress sites, and AWS accounts are billable work I have done for years. The agent in this post is that workflow encoded into Claude Code, and building it taught me the thesis of this whole piece: an AI security scanner lives or dies on architecture, not prompting. Specifically, you must separate the methodology (a skill) from the execution (sub-agents with fresh context), because audit quality degrades in exact proportion to how full the context window is when the auditor reaches your code.
Why one big "scan my repo" prompt fails
I tried the naive version first, one session, one instruction: audit this codebase against the OWASP Top 10. The failure pattern was consistent enough to be predictable. The first two categories got genuinely careful analysis. By the fifth, the context was stuffed with file contents from the earlier passes, and the model was skimming. By the ninth, it was pattern-matching filenames. The report format also drifted between runs, which matters more than people think: an audit you cannot diff against last month's audit is a one-off, not a security process.
Human auditors have the same failure mode, which is why real audit firms use checklists and fresh reviewers per domain. The fix maps one-to-one.
The architecture: a skill for the rules, sub-agents for the reading
The skill is the senior auditor's methodology, written down once. Mine contains four sections:
- Scope and category mapping. The OWASP Top 10 mapped to what each category concretely means in the stacks I audit. Abstract categories produce abstract findings; the skill translates them.
- A severity rubric. Critical, high, medium, low, with definitions tied to exploitability and blast radius, so severity is assigned by rule rather than by vibe. This is the section clients actually pay for, and it took the most iterations.
- A fixed report format. Finding, file and line, category, severity, evidence snippet, remediation, confidence. Every run, same shape, so runs are comparable over time.
- Hard rules. Read-only, always: the scanner never edits code. Report everything including low-confidence findings, marked as such, because a triage step downstream can filter noise but cannot recover a finding that was never reported. Never echo discovered secrets into the report body; reference their location only.
The sub-agents are where the token budget goes. The orchestrating session dispatches one sub-agent per category (or per module, on big codebases), each with a clean context that reads the relevant files deeply and returns only structured findings. The orchestrator never sees raw file contents, just findings, which it merges, deduplicates, and ranks. This is the same fresh-context pattern that makes agent systems affordable in general, applied to a domain where shallow reading is not a cost problem but a correctness problem.
What the skill checks, because I check it manually
The value of encoding your own workflow, rather than downloading someone's generic security prompt, is that the checks carry your engagement history. Mine include, straight from real audits:
- Laravel: mass assignment via over-permissive
$fillableor$guarded = [], rawDB::selectwith interpolated strings, missing authorization on route model binding (the IDOR classic),APP_DEBUG=truein production configs, validation living in controllers instead of Form Requests where it gets skipped by the next endpoint, and queue jobs that trust their payloads. - WordPress: nonce checks missing on state-changing actions, capability checks confused with authentication checks, direct file access without
ABSPATHguards, and$wpdb->querywith unprepared input in custom plugins, which is where client sites actually get owned. - AWS IAM: wildcard actions on wildcard resources, users with console passwords and no MFA, and access keys older than the developer who created them.
None of that list is exotic. That is the point. Audits fail on coverage and consistency, not on cleverness, and an agent is relentless about exactly the boring things humans skip on file forty.
Testing it against an app built to fail
You do not point a new scanner at a client codebase first. I built a deliberately vulnerable note-keeping app as a test target and seeded it with the classics: MD5 password hashing, string-concatenated SQL in a search endpoint, an IDOR on the note-view route, a hardcoded API key in a config file, missing rate limiting on login, and verbose stack traces in production mode.
The scanner caught the seeded issues, which was the pass condition, but the informative results were at the edges. It flagged a session-fixation pattern I had not intentionally planted, a genuine find. It also produced false positives of a very specific flavor: code that is safe but ugly, like input that was validated upstream in a way the category sub-agent could not see. That taught me to have sub-agents report the assumption behind each finding ("assumes $request->input reaches this query unvalidated"), which turns a false positive from noise into a one-second dismissal. And it confirmed the consistency claim: three runs on the same commit produced materially identical reports, which is the property that makes the agent CI-worthy.
Wiring it into the workflow
Two integration points earn their keep. A pre-commit or pre-merge scan runs diff-scoped, categories relevant to the changed files only, cheap enough to run on every PR. A scheduled full scan runs weekly against main with the complete category sweep, and its report gets diffed against the previous week's. New findings page me; disappeared findings get verified as actually fixed rather than accidentally hidden. If you run agents with this much repo access, the permission and onboarding side of agent security deserves as much thought as the scanning side; a scanner with write access is itself a finding.
Where this breaks, honestly
The agent does not understand your business logic. It can see that a route lacks an authorization check; it cannot know that "users may only see invoices for their own organization unless they are a reseller" was the intent. Business-logic authorization remains human work informed by the agent's map. It does not test runtime behavior, so it complements rather than replaces dependency scanners and DAST tools; it reads code, and running systems misbehave in ways code review cannot see. And it does not sign the report. When findings go to a client, a human who can defend every line puts their name on it. Mine.
I would also not hand this to someone who has never audited anything, because the skill encodes judgment you have to possess before you can encode it. The agent made my audits faster and more consistent. It did not make them possible; the years of doing them manually did.
Want the audit, not the build?
If what you actually need is your Laravel app, WordPress site, or AWS account audited, that is literally what I do, with this agent as the first pass and my eyes as the second. The security side of my services covers OWASP-style code audits through remediation, and every engagement ends with the diffable report format described above rather than a PDF of screenshots. Bring me a codebase; I will bring the scanner and the signature.
