| name | ai-pentesting |
| description | Run autonomous AI-driven penetration tests on web applications using tools like Shannon, PentAGI, and similar frameworks. Use when tasks involve setting up automated penetration testing pipelines, combining AI agents with security tools (nmap, subfinder, nuclei, sqlmap), building autonomous exploit chains, generating pentest reports with proof-of-concept exploits, or integrating AI pentesting into CI/CD pipelines. Covers the full pentest lifecycle from reconnaissance to reporting using AI orchestration. |
| license | Apache-2.0 |
| compatibility | Docker, Python 3.10+, Go 1.21+ for security tools |
| metadata | {"author":"terminal-skills","version":"1.0.0","category":"devops","tags":["pentesting","ai-security","autonomous","vulnerability","owasp"]} |
AI Pentesting
Overview
Use AI agents to autonomously conduct penetration tests on web applications. Combine LLM reasoning with security tools (nmap, subfinder, nuclei, sqlmap, browser automation) to find and prove vulnerabilities with minimal human intervention.
Instructions
Methodology
AI pentesting follows the same phases as human pentesting, but the AI orchestrates each phase autonomously:
Phase 1: RECONNAISSANCE
├── Subdomain enumeration (subfinder)
├── Technology fingerprinting (whatweb, wappalyzer)
├── Port scanning (nmap)
├── API schema discovery (crawling, OpenAPI/GraphQL introspection)
└── Source code analysis (if white-box)
AI decides: which tools to run, in what order, based on findings
Phase 2: VULNERABILITY ANALYSIS
├── Known CVE scanning (nuclei)
├── Web vulnerability scanning (OWASP ZAP, nikto)
├── API fuzzing (schemathesis)
├── Code-level vulnerability hunting (semgrep, CodeQL)
└── Data flow analysis (input → dangerous function)
AI decides: which findings are likely exploitable
Phase 3: EXPLOITATION
├── SQL injection (sqlmap, manual payloads)
├── XSS (reflected, stored, DOM)
├── SSRF (internal access, cloud metadata)
├── Authentication bypass (broken auth, privilege escalation)
├── Business logic flaws (price manipulation, race conditions)
└── Browser-based exploitation (Playwright/Puppeteer)
AI decides: exploitation order, payload selection, chaining
Phase 4: REPORTING
├── Proof-of-concept for each finding
├── Reproducible steps (curl commands, screenshots)
├── Severity rating (CVSS score)
├── Remediation guidance
└── Executive summary
AI generates: structured, evidence-based report
Setting Up Shannon
Shannon is an open-source AI pentester that automates the full lifecycle:
git clone https://github.com/KeygraphHQ/shannon.git
cd shannon
export ANTHROPIC_API_KEY="your-api-key"
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000
./shannon start URL=https://your-app.com REPO=./your-repo
./shannon logs
open http://localhost:8233
Shannon's architecture:
- Reconnaissance agent: Maps attack surface using nmap, subfinder, whatweb
- Vulnerability agents: Specialized per OWASP category (injection, XSS, SSRF, auth bypass)
- Exploitation agent: Uses browser automation to prove vulnerabilities with real exploits
- Reporting agent: Generates findings with copy-paste PoC commands
Building a Custom AI Pentest Pipeline
For cases where Shannon doesn't fit, build a custom pipeline:
import subprocess
import json
from openai import OpenAI
client = OpenAI()
class AIPentester:
"""Autonomous AI penetration tester.
Orchestrates security tools using LLM reasoning
to find and prove vulnerabilities.
"""
def __init__(self, target_url: str, scope: list[str] = None):
self.target = target_url
self.scope = scope or [target_url]
self.findings = []
self.recon_data = {}
async def run_pentest(self) -> dict:
"""Execute full penetration test lifecycle.
Returns:
Dict with findings, evidence, and recommendations
"""
self.recon_data = await self._recon()
targets = await self._analyze_attack_surface(self.recon_data)
for target in targets:
finding = await self._exploit(target)
if finding:
.findings.append(finding)
report = ._generate_report()
report
() -> :
recon = {}
result = subprocess.run(
[, , ._get_domain(), ],
capture_output=, text=, timeout=
)
recon[] = result.stdout.strip().split()
result = subprocess.run(
[, .target, , , ],
capture_output=, text=, timeout=
)
recon[] = json.loads(result.stdout) result.stdout {}
result = subprocess.run(
[, , , , , , ._get_domain()],
capture_output=, text=, timeout=
)
recon[] = result.stdout
result = subprocess.run(
[, , .target, , ,
, ],
capture_output=, text=, timeout=
)
recon[] = [
json.loads(line) line result.stdout.strip().split()
line.strip()
]
recon
() -> :
response = client.chat.completions.create(
model=,
messages=[
{: , :
},
{: , :
}
],
response_format={: }
)
json.loads(response.choices[].message.content).get(, [])
() -> | :
vuln_type = target.get(, ).lower()
handlers = {
: ._test_injection,
: ._test_xss,
: ._test_ssrf,
: ._test_auth_bypass,
}
key, handler handlers.items():
key vuln_type:
handler(target)
() -> :
response = client.chat.completions.create(
model=,
messages=[
{: , :
},
{: , :
}
]
)
{
: .target,
: (.findings),
: .findings,
: response.choices[].message.content
}
CI/CD Integration
Run AI pentests on every deployment:
name: AI Penetration Test
on:
push:
branches: [main]
schedule:
- cron: '0 2 * * 1'
jobs:
pentest:
runs-on: ubuntu-latest
services:
app:
image: your-app:${{ github.sha }}
ports:
- 8080:8080
steps:
- uses: actions/checkout@v4
- name: Run Shannon Pentest
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
git clone https://github.com/KeygraphHQ/shannon.git
cd shannon
./shannon start \
URL=http://localhost:8080 \
REPO=../ \
MAX_CONCURRENT=3
./shannon wait
cp workspace/report.md $GITHUB_WORKSPACE/pentest-report.md
Report Structure
A professional AI-generated pentest report should include: executive summary (scope, duration, methodology, overall risk, findings count by severity), individual findings (each with CVSS score, affected endpoint/parameter, evidence with reproducible curl commands, impact description, and specific remediation guidance), and a remediation priority list ordered by severity with recommended fix timelines.
Examples
Run an autonomous pentest on a web application
Set up Shannon to run a full penetration test on our staging environment at https://staging.ourapp.com. The source code is in the current repository. Configure it to test for: SQL injection, XSS, SSRF, and broken authentication. Run with maximum concurrency and generate a report with reproducible proof-of-concept exploits for every finding. Flag any critical vulnerabilities that need immediate attention.
Build a custom AI pentest pipeline
Build a custom AI pentesting pipeline that combines subfinder (subdomain discovery), whatweb (tech fingerprinting), nuclei (CVE scanning), and schemathesis (API fuzzing) orchestrated by an LLM agent. The LLM should analyze results from each tool, decide what to test next, and generate exploitation payloads. Target: our API at api.example.com with the OpenAPI spec at /docs/openapi.json. Produce a structured findings report.
Integrate AI pentesting into CI/CD
Add automated penetration testing to our GitHub Actions pipeline. It should run on every push to main and weekly on a schedule. The app runs in Docker (docker-compose up), exposed at localhost:8080. Use Shannon for the pentest, upload the report as an artifact, and fail the build if any critical or high severity vulnerabilities are found. Include Slack notification for findings.
Guidelines
- Only run penetration tests against systems you have explicit written authorization to test — unauthorized testing is illegal
- AI pentesters can cause real damage (data modification, service disruption) — always test against staging environments, never production
- Review AI-generated exploitation attempts before running them — LLMs can hallucinate or generate overly aggressive payloads
- Treat pentest reports as confidential — they contain vulnerability details and proof-of-concept exploits
- Set time limits and scope boundaries for autonomous testing to prevent runaway scans
- Validate AI findings manually — false positives in automated reports erode trust with stakeholders
- Store API keys and credentials used for pentesting securely — never hardcode them in CI configurations
