Automated penetration testing (authorised)

Manual penetration tests happen once or twice a year and cover only a sample of an organisation's systems, while code and infrastructure change daily. AI-driven pentest tools chain reconnaissance, exploitation of known weakness classes and validation of findings, so that web apps, APIs and internal networks can be tested continuously and fixes retested. Human testers stay responsible for scope, risk decisions and novel, business-logic-heavy attack paths.

Policy and architecture level only. Use exclusively on systems you own or are contractually authorised to test. Testing third-party systems without written permission is a criminal offence in most EU states (e.g. Section 202c StGB in Germany, Directive 2013/40/EU).

Problem & value

• Today: annual or ad hoc manual pentests (days to weeks of expert time) plus vulnerability scanners that list thousands of unverified, often non-exploitable findings. Fixes are rarely retested until the next engagement; new releases ship untested in between.
• AI value: (1) validation — prove that a finding is actually exploitable, which cuts false positives and helps prioritisation; (2) coverage and cadence — test every release or weekly rather than yearly; (3) attack-path reasoning — combine low-severity issues (credentials, misconfigurations, trust relationships) into realistic chains; (4) retest after remediation.
• Capability: autonomous agents have reached the top of public bug-bounty rankings (XBOW on the HackerOne US leaderboard in 2025) and perform well on web-vulnerability benchmarks, but results on realistic multi-host networks and business-logic flaws remain markedly weaker [1][2].
• Regulatory pull: NIS2 requires risk-management measures including vulnerability handling and effectiveness assessment, and DORA requires threat-led penetration testing (TLPT) for designated financial entities and regular resilience testing for others; both raise demand for repeatable testing [3][4].

Variants

• External attack-surface validation: automated discovery plus safe exploit verification on internet-facing assets.
• Web application and API testing (DAST+): agentic authenticated crawling, business-flow testing (IDOR, broken access control) against staging environments.
• White-box / code-aware testing: agent reads source code, proposes an exploit hypothesis and proves it against a running test instance (reduces false positives of SAST, see SEC-004).
• Internal network/AD and cloud paths: attack-path discovery with safe-by-design exploits.
• Public sector: stricter scope control; OT/ICS excluded unless agreed. Private use: home lab only.

How it works

1. scope & rules of engagement (signed, machine-readable allow-list, time window, forbidden actions)
2. recon (asset discovery, tech fingerprinting, API/spec ingestion)
3. hypothesis generation (LLM planner: likely weakness classes per asset)
4. controlled testing (tool calls: scanners, HTTP client, browser, exploit frameworks in safe mode)
5. validation (reproduce with a harmless proof, e.g. read a canary file; capture evidence)
6. triage & de-duplication (severity, reachability, business impact)
7. human review gate (tester/security engineer approves critical or intrusive steps and findings)
8. report + tickets / fix PRs
9. retest loop

• Planner/executor agents: a reasoning LLM plans; specialised sub-agents (recon, web, auth, network) call real tools (e.g. nmap, nuclei, Burp-style proxies, Metasploit-class frameworks, a headless browser). The model rarely "invents" exploits; it orchestrates and adapts tools.
• Guardrails are the product: hard scope enforcement outside the model (network allow-lists, egress proxy, rate limits, kill switch), forbidden-action policy (no data exfiltration of real personal data, no destructive payloads, no denial of service), and immutable action logs.
• Human-in-the-loop: scope sign-off, approval of intrusive or production-impacting steps, review of every high/critical finding before it reaches developers, final report accountability.

Data preparation

Data needs are low and mostly organisational rather than technical: scope definition, an asset and IP list, architecture diagrams, and test accounts. In an SMB this lives in the IT documentation, firewall configuration, a wiki or the head of the one administrator.

Typical gaps: outdated or missing asset inventory, unknown internet-facing services (shadow IT, forgotten test systems), no written authorisation from system owners and hosting providers, no test or staging copy, and unclear contacts for incidents during the test.

Preparation steps: 1. Create or update the asset inventory and external attack surface list (PREP-001, PREP-005). 2. Write the rules of engagement: scope, allowed techniques, time windows, emergency contacts, data handling. 3. Obtain written permission from owners, hosters and cloud providers where required. 4. Prepare test accounts with realistic roles and a staging environment with synthetic or pseudonymised data (PREP-022). 5. Make sure backups and monitoring are working before the test.

The effort share is small, around 10 to 15 percent of the total, but missing authorisation or scope is the most common reason for projects to fail or become legally risky. GUIDE-003 helps with the inventory part.

Implementation paths

Which path for whom

• SMB: Path A. A certified pentest provider or an established automated scanning/pentest service is the safe choice; building own tooling is not worth it.
• Enterprise: Path B. Own red teams extend their toolchain with LLM agents via APIs under strict scoping, while remaining free in tool choice.
• Developer: Path C. Open-source frameworks and local models on HW3 allow experiments in lab environments without sending target data out.
• Public: Path A. Qualified, certified providers (e.g. BSI-recognised) with clear liability are usually required for public systems.

Path A — Buy (recommended for most organisations)

• Autonomous pentest / AI pentest platforms: Horizon3.ai NodeZero (internal/external, AD and cloud paths), XBOW (autonomous web/app offensive testing), Pentera (automated security validation), Ethiack (EU, Portugal), Hadrian and Cymulate (exposure validation/BAS), Escape (EU, France; API and DAST), Synack and other PTaaS providers combining AI with human testers.
• Choose A when: you lack an in-house red team, need audit-ready evidence quickly and can define scope clearly. Check: scope enforcement controls, safe-exploit policy, EU data residency of findings and credentials, reproducible evidence, retest included, liability and insurance terms.

Path B — Build on cloud APIs

• Orchestrate a reasoning LLM (Claude, GPT, Gemini or Mistral models in EU regions) with a tool layer via the Model Context Protocol (MCP) or function calling; frameworks such as LangGraph or the Claude Agent SDK.
• Wrap each tool behind a policy proxy that enforces the allow-list and logs requests.
• Check each provider's acceptable-use policy: dual-use security work usually needs an explicit authorised-testing context or a verified cyber programme; refusals are a practical risk.
• Choose B when: you are a security team automating retests or white-box checks on your own applications inside CI/CD.

Path C — Self-host (open source)

• Open-source agents/tools: PentestGPT (research-origin LLM pentest assistant), Strix and similar open agentic scanners, Nuclei, OWASP ZAP (with automation framework), Metasploit and Caldera (MITRE adversary emulation).
• Models: strong open-weight code/reasoning models (e.g. Qwen3-Coder family, DeepSeek, gpt-oss, Mistral/Devstral families) served via vLLM or Ollama inside an isolated lab network.
• Hardware: HW3 (one 48–141 GB GPU) for ~30–120B models; HW2 works for narrow tasks.
• Choose C when: data (source code, credentials) must not leave the premises or for research. Expect weaker autonomy than frontier models.

Path D — Custom training

Rare: distilling or fine-tuning on own past reports and CTF environments to cut cost at high volume.

State of the art (2026)

• Agentic offensive security moved from demos to products: autonomous platforms report validated findings on web apps and networks; academic work (PentestGPT, benchmarks such as Cybench and CVE-Bench) shows rapid but uneven progress, with the best systems solving a substantial share of web CTF-style tasks but far fewer long-horizon, multi-step real-world scenarios [2][5].
• Strengths: broad coverage, tireless retesting, quick exploit validation of known vulnerability classes, report drafting.
• Limits and failure modes: hallucinated or unreproducible findings; poor handling of complex business logic, multi-factor authentication and fragile production systems; scope drift or unintended impact (account lockouts, data modification, load); prompt injection from tested targets steering the agent; limited creativity versus elite human testers; non-determinism that complicates audit evidence. Treat output as triage-quality evidence, not a certified pentest, unless a qualified provider signs off.

Shared resources & combinations

• Same stack (llm-reasoning, llm-code, agent-framework): SEC-004 (vulnerability management and auto-fix) feeds fixes from validated findings; SEC-014 (AI red teaming) reuses the same agent harness against LLM apps; SEC-010 hardens the apps found weak.
• Upstream/downstream: SEC-012 defines what to test; SEC-009 turns reports into compliance evidence; SEC-001/SEC-008 use findings to tune detection. Announce tests to the SOC.

Effort, cost & KPIs

• Effort: A weeks (subscription per asset); B 2–4 months (token cost per run); C 3–6 months plus GPU.
• KPIs: share of findings validated as exploitable, false-positive rate, mean time to detect and to remediate critical findings, test coverage (assets/APIs tested per quarter), retest cycle time, scope violations (target: zero), cost per validated finding.

People & change

Authorised testing is a team effort with clear sign-offs; unauthorised testing is a criminal matter.

• Management gives written authorisation and owns the risk; legal/compliance checks contracts with hosters, customers and the pentest provider (liability, confidentiality).
• IT and IT security define scope, monitor during the test and fix findings; data owners and suppliers must agree if their systems or data are touched.
• Works council: depends. Technical tests of systems normally do not monitor staff. Co-determination (§87(1) no. 6 BetrVG) becomes relevant if tests log user behaviour, or if phishing and social-engineering simulations are part of the scope; inform the works council in good time in any case (§90(1) no. 3).
• DPO: involve if tests can touch personal data; agree on AVV with the provider (Art. 28 GDPR) and on handling of personal data in findings.
• AI literacy: support the security team in understanding limits and hallucinated findings of AI agents (Art. 4 AI Act).
• Communication and pilot: tell the IT team and SOC that a test runs, start with a non-critical system.
• Typical concern: "will it break production?" Answer with staging first, time windows, rollback plans, and human approval for every exploit step.

See GUIDE-013, GUIDE-005 and GUIDE-004.

Risks, regulation & compliance

• Authorisation first: written permission from the system owner (and cloud/hosting providers where their policy requires it); EU member-state computer-misuse law applies (Directive 2013/40/EU).
• EU AI Act: minimal risk for defensive security testing of own systems; AI literacy (Art. 4) applies. No Art. 5 prohibition is triggered by pentesting, but the tool must not be repurposed for profiling or manipulating individuals. If used to test safety components of critical infrastructure, the tested system may be high-risk, not the pentest tool. General-purpose AI model providers carry their own obligations.
• GDPR: tests may expose personal data; use test data or synthetic data, minimise evidence capture, define a data-processing agreement with the vendor, store findings in the EU, and treat discovered personal data as a potential incident to be assessed under Art. 33.
• NIS2/DORA/ISO 27001: supports testing obligations; DORA TLPT requires qualified testers and TIBER-style processes where applicable, so AI tools complement but do not replace them [4].
• Mitigations: staging first, rate limits, kill switch, immutable logs, human approval of intrusive steps, agent sandboxing against prompt injection.

Getting started

1. Inventory assets and write a precise scope and rules-of-engagement document (allow-list, hours, forbidden actions, contacts, emergency stop).
2. Pilot on a staging replica of one web app or API with a Path A product or open-source ZAP/Nuclei plus an LLM agent; compare against your last manual pentest report.
3. Measure validated-finding rate and false positives; require evidence for every finding.
4. Integrate into CI/CD and ticketing (retest on fix); inform the SOC and data protection officer.
5. Keep an annual human-led pentest for business logic, social engineering and compliance-mandated tests.

Sources

1. XBOW — autonomous penetration testing and HackerOne results — https://xbow.com/blog
2. Deng et al. — PentestGPT: LLM-empowered automatic penetration testing — https://arxiv.org/abs/2308.06782
3. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
4. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
5. Cybench: framework for evaluating cybersecurity capabilities of language models — https://arxiv.org/abs/2408.08926
6. Horizon3.ai NodeZero documentation — https://docs.horizon3.ai
7. OWASP ZAP automation framework — https://www.zaproxy.org/docs/automate/automation-framework/
8. Nuclei project — https://github.com/projectdiscovery/nuclei
9. MITRE Caldera — https://github.com/mitre/caldera
10. Directive 2013/40/EU on attacks against information systems — https://eur-lex.europa.eu/eli/dir/2013/40/oj
11. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj