April 6, 2026

Your Security Agent Never Takes a Day Off.

It thinks like an attacker so your team doesn't have to.

Your app works. Users log in, create data, interact with each other. Everything looks fine. But a security researcher changes a number in the URL and accesses another user's private data. An attacker pastes a script tag into a comment field and steals session cookies. A leaked API key from a commit six months ago gives full database access. None of these show up in your test suite. All of them can end your company.

The Security subagent assumes every input is hostile and every boundary is permeable. It thinks like an attacker to defend like a professional.

The OWASP Top 10 as a Mental Checklist

The Security agent works through a structured threat model on every conversation.

Broken access control is the number one vulnerability in web applications. Can user A see user B's data by changing an ID in the URL? Can a regular user reach admin endpoints? Are ownership checks enforced on the server, or only hidden in the UI? The fix is always the same: enforce access control server-side on every single request, and use row-level security in the database so even a code bug can't expose the wrong rows.

Injection is the classic attack. SQL injection happens when user input gets concatenated into a database query instead of being parameterized — allowing an attacker to run arbitrary SQL. Cross-site scripting (XSS) happens when user-generated content is rendered without escaping, letting an attacker inject JavaScript that runs in other users' browsers. Command injection happens when user input reaches a shell command. The fix for all of them: parameterize everything, escape on output, set Content Security Policy headers, and never use eval() on user input.

Cryptographic failures are silent until they're catastrophic. Passwords must be hashed with bcrypt, scrypt, or argon2 — not MD5 or SHA-256, which are fast hash functions designed for data integrity, not password storage. JWTs should be signed with RS256 or ES256, not HS256 with a weak secret. API responses should never leak fields they shouldn't — password hashes, internal IDs, or personally identifiable information.

Beyond the Obvious

The Security agent catches subtler issues too. Business logic flaws: can a user skip the payment step? Apply a discount code twice? Approve their own expense report? Rate limiting: can an attacker brute-force login attempts, OTP codes, or expensive API endpoints? Error messages: do they reveal whether a username or email exists in the system (enabling enumeration)?

For authentication, it checks session management (secure, httpOnly, sameSite cookies), token lifecycle (access tokens under 15 minutes, refresh token rotation), and password policies (minimum length, check against breached password databases).

Secrets management is non-negotiable: no secrets in code or config files committed to git. API keys scoped to minimum permissions. Everything in the client-side bundle assumed public — because it is.

Every Finding Has a Fix

Every security finding includes the vulnerability, the exact file or endpoint, a step-by-step exploit scenario, the worst-case impact, the specific code change to fix it, and a severity classification. Critical means remote code execution, auth bypass, or mass data exposure — fix immediately. High means privilege escalation or stored XSS — fix within days. Medium means missing rate limiting or CSRF — fix within the sprint.

The most secure teams aren't the ones with the best audits. They're the ones where security thinking is in every conversation.