AI Agents for Security Auditing and Penetration Testing

Why security needs specialized agents

General-purpose AI assistants can spot obvious vulnerabilities — an unsanitized SQL query, a hardcoded API key. But security auditing requires a different mindset. A security auditor doesn't just read code line by line. They think about how an attacker would use a system, how components interact under adversarial conditions, and which assumptions break when inputs are malicious.

A security agent encodes that mindset. It tells your AI assistant to think like an attacker: what happens if this input is 10MB? What if this user ID belongs to someone else? What if this webhook payload is forged? Generic agents won't ask these questions. Security agents will.

The difference shows up in output quality. A generic review might flag "this input isn't validated." A security agent produces: [CRITICAL] Line 23: User-supplied redirect_url is passed to res.redirect() without validation. An attacker can craft a URL that redirects users to a phishing site (open redirect, CWE-601). Validate against an allowlist of permitted domains.

What security agents check for

OWASP Top 10

The most effective security agents are structured around the OWASP Top 10 — the industry-standard list of the most critical web application security risks. Good agents check for each category systematically:

• Injection — SQL, NoSQL, OS command, LDAP injection through unsanitized inputs
• Broken authentication — weak session management, credential stuffing vectors, missing rate limits
• Sensitive data exposure — unencrypted data in transit or at rest, secrets in logs, PII leaks
• Broken access control — IDOR vulnerabilities, missing authorization checks, privilege escalation paths
• Security misconfiguration — default credentials, verbose error messages, unnecessary features enabled
• Cross-site scripting (XSS) — reflected, stored, and DOM-based XSS through unescaped output

Agents that reference OWASP categories explicitly tend to be more thorough than those that use vague instructions like "check for security issues."

Authentication and authorization flaws

Security agents should examine how identity and permissions flow through the application. This means checking:

• Whether every API endpoint verifies authentication
• Whether authorization checks use the authenticated user's identity, not user-supplied values
• Whether session tokens are generated securely and expire appropriately
• Whether password reset flows are resistant to enumeration and token reuse
• Whether JWT tokens are validated correctly (algorithm, expiration, issuer)

These checks require the agent to understand the application's auth model, not just individual lines of code.

Input validation and injection

Every point where external data enters the system is a potential attack surface. Security agents should examine:

• Database queries for injection vulnerabilities (SQL, NoSQL, ORM-level)
• Shell commands constructed from user input
• File paths built from user-supplied values (path traversal)
• Redirect URLs and callback URLs (open redirect)
• Template rendering with user data (template injection)
• Deserialization of untrusted data

The best agents don't just check if input is validated — they check whether the validation is sufficient for the context. A regex that strips <script> tags isn't adequate XSS protection if the output is rendered in an HTML attribute.

Secrets and configuration

Hardcoded secrets are one of the most common security findings. Security agents should flag:

• API keys, tokens, and passwords in source code
• Secrets in configuration files that might be committed to version control
• Default credentials in Docker configurations or environment templates
• Overly permissive CORS policies or CSP headers
• Debug modes enabled in production-facing configurations

Dependency vulnerabilities

Some security agents extend beyond your code to examine dependencies. They check:

• Known vulnerabilities in package versions (cross-referencing CVE databases)
• Deprecated packages with known security issues
• Unnecessary dependencies that increase attack surface
• Lock file integrity and supply chain risks

Common use cases

Pre-merge security review

Run a security agent on every pull request before merging. This catches vulnerabilities early, when they're cheapest to fix. The agent examines the diff, focuses on security-relevant changes, and produces a structured report with severity levels.

This works best for incremental changes. A security agent reviewing a 50-line diff can be thorough. Reviewing an entire codebase in one pass is less effective.

Focused security audit

Point a security agent at a specific subsystem — your authentication module, payment processing code, or API gateway — and ask for a deep review. This is useful before launching a new feature, after a security incident, or as part of a regular audit cycle.

For this use case, look for agents that define a systematic audit process: enumerate entry points, trace data flow, identify trust boundaries, then check each boundary for weaknesses.

Threat modeling assistance

Some security agents help with threat modeling — identifying what could go wrong before you write the code. Given an architecture description or API specification, a threat modeling agent identifies potential attack vectors, trust boundary violations, and data flow risks.

This is a higher-level use case that works well during design reviews, not just code reviews.

Compliance checking

For teams operating under regulatory requirements (SOC 2, HIPAA, PCI-DSS, GDPR), security agents can check for compliance-relevant patterns: data encryption at rest and in transit, access logging, data retention policies, PII handling, and audit trail completeness.

What makes a good security agent

Attacker mindset

The best security agents instruct the AI to think adversarially. Instead of "check for security issues," they say things like "For each user input, consider what happens if an attacker provides unexpected, malicious, or extremely large values." This framing produces different — and better — findings.

Severity classification with CWE references

Security findings need prioritization. Effective agents use a severity scale (critical, high, medium, low, informational) and reference Common Weakness Enumeration (CWE) IDs when applicable. This makes findings actionable and traceable to industry-standard vulnerability classifications.

Remediation guidance

Identifying a vulnerability is half the job. Good security agents include remediation steps: what to change, which library to use, what pattern to follow. "Use parameterized queries" is better than "SQL injection found." "Use db.query('SELECT * FROM users WHERE id = $1', [userId]) instead of string concatenation" is better still.

Scope awareness

A security agent that reviews infrastructure code should know about container security, network policies, and IAM permissions. One that reviews API code should know about authentication patterns, rate limiting, and input validation. Look for agents that match your stack and context.

Building your own security agent

If existing agents don't cover your team's specific security requirements, you can build your own. A good starting point:

1. Define the attacker model. Who are you defending against? Script kiddies, sophisticated attackers, insiders?
2. List your check categories. OWASP Top 10 is a good baseline. Add categories specific to your domain.
3. Specify output format. Include severity, CWE reference, location, description, and remediation for each finding.
4. Add your stack-specific rules. If you use Django, include Django-specific security checks. If you use AWS, include IAM and S3 policy checks.
5. Include examples. Show the agent what a good finding looks like and what a false positive looks like.

See the agent definition guide for general best practices on structuring agent definitions.

Get started

Browse security agents on Agent Shelf. Every agent is a plain Markdown file you can read before installing. Find one that matches your stack and security requirements, or publish your own to share with the community.