ai-pentesting

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:

# Clone and set up Shannon
git clone https://github.com/KeygraphHQ/shannon.git
cd shannon

# Configure credentials
export ANTHROPIC_API_KEY="your-api-key"
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000

# Run a pentest against your application
# Requires: Docker, target URL, source code repo
./shannon start URL=https://your-app.com REPO=./your-repo

# Monitor progress
./shannon logs

# View results in Temporal UI
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:

# ai_pentester.py
# Custom AI pentesting pipeline using LLM + security tools

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
        """
        # Phase 1: Recon
        self.recon_data = await self._recon()
        
        # Phase 2: AI-guided vulnerability analysis
        targets = await self._analyze_attack_surface(self.recon_data)
        
        # Phase 3: AI-guided exploitation
        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:

# .github/workflows/pentest.yml
name: AI Penetration Test
on:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * 1'  # Weekly Monday 2 AM

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
          
          # Wait for completion and extract report
          ./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