{"slug": "building-an-ai-assisted-pentesting-platform-without-creating-an-auto-pwn", "title": "Building an AI-Assisted Pentesting Platform Without Creating an Auto-Pwn", "summary": "Dark Spear, an AI-assisted platform for authorized security assessments, was designed to automate pentesting workflows while keeping scope enforcement, dangerous tool approval, and evidence integrity under human control. The platform's architecture separates deterministic playbooks from LLM agent orchestration, with the backend enforcing security boundaries to prevent autonomous exploitation.", "body_md": "AI agents are becoming increasingly capable of interacting with tools.\n\nIn cybersecurity, that creates an obvious opportunity: let an agent inspect a target, run reconnaissance, interpret the output and decide what to test next.\n\nIt also creates an obvious problem.\n\nWhat happens when the agent decides to do something that should not be done?\n\nThat question became one of the design constraints behind Dark Spear, an AI-assisted platform for authorised security assessments.\n\nDark Spear was not designed as an autonomous exploitation engine.\n\nThe goal was different:\n\nBuild an automated pentesting workflow that can move through an engagement while keeping scope enforcement, dangerous tool approval and evidence integrity under human control.\n\nThis article explains the architecture behind that decision.\n\nThe problem with “autonomous pentesting”\n\nAutomation is not new in offensive security.\n\nWe already automate:\n\nPort scanning.\n\nDirectory discovery.\n\nTechnology fingerprinting.\n\nCredential testing.\n\nVulnerability detection.\n\nOSINT collection.\n\nReport generation.\n\nThe difference with AI agents is that they can dynamically decide what to do next.\n\nThat flexibility is useful.\n\nA deterministic scanner can only execute what its author anticipated.\n\nAn agent can potentially react to unexpected output.\n\nBut flexibility introduces a new trust boundary.\n\nIf an AI agent has access to security tools, the system needs to answer several questions:\n\nWhat targets is the agent allowed to interact with?\n\nWhat tools can it execute?\n\nWhich actions require explicit human approval?\n\nCan the client-side agent bypass restrictions?\n\nHow are findings verified?\n\nWhat evidence proves a finding?\n\nCan the final report be defended and reproduced?\n\nDark Spear treats those questions as architecture problems rather than prompt engineering problems.\n\nArchitecture overview\n\nThe platform has three major components.\n\nThe assessment engine contains two execution modes.\n\nThe first is deterministic.\n\nThe second is agentic.\n\nThe browser orchestrates the workflow and communicates with the backend only when an approved binary needs to be executed.\n\nThe main engine includes:\n\nPTES phase orchestration.\n\nProbe definitions.\n\nVulnerability knowledge bases.\n\nFinding heuristics.\n\nLLM agent orchestration.\n\nOllama Cloud integration.\n\nBridge client communication.\n\nThe backend is the enforcement point.\n\nThis is deliberate.\n\nThe browser is not trusted to enforce security boundaries.\n\nThe backend applies:\n\nTool allowlisting.\n\nTarget scope locking.\n\nPTES phase gates.\n\nDangerous action approval.\n\nFinding persistence.\n\nEvidence hashing.\n\nEncrypted API key storage.\n\nThe client can request an action.\n\nThe server decides whether that action is allowed.\n\nThat separation is fundamental when an AI agent can generate commands dynamically.\n\nThe third component is the operational layer.\n\nSecurity testing is only part of an engagement.\n\nThe results need to be reviewed, correlated and communicated.\n\nThe console provides views for:\n\nActive engagements.\n\nTool approval.\n\nFindings.\n\nCritical vulnerabilities.\n\nAttack graphs.\n\nMITRE ATT&CK mapping.\n\nOSINT.\n\nGovernance.\n\nRisk maturity.\n\nRemediation planning.\n\nReporting.\n\nThe goal was to avoid treating the scanning engine and the reporting system as separate projects.\n\nThey are parts of the same workflow.\n\nDeterministic mode versus LLM agents\n\nOne of the design decisions was to avoid making the LLM mandatory.\n\nThe platform supports two modes.\n\nDeterministic playbooks\n\nThe deterministic mode follows a curated catalogue of security probes.\n\nIt does not require an LLM.\n\nIt does not consume inference tokens.\n\nAnd its execution path is reproducible.\n\nThe probes cover multiple categories:\n\nInjection\n\nSQL injection.\n\nNoSQL injection.\n\nReflected XSS.\n\nOpen redirects.\n\nGeneric IDOR checks.\n\nAuthentication and sessions\n\nDefault credentials.\n\nCookie security attributes.\n\nMissing security headers.\n\nJWT testing\n\nWeak HS256 secret cracking performed locally.\n\nalg=none validation where applicable.\n\nActive reconnaissance\n\nTechnology fingerprinting.\n\nContent discovery.\n\nrobots.txt analysis.\n\nCORS configuration.\n\nHTTP TRACE exposure.\n\nCode and configuration exposure\n\nAccessible .git directories.\n\nEnvironment files.\n\nBackup files.\n\nSource maps.\n\nPublic API documentation.\n\nMetrics endpoints.\n\nSecrets exposed in JavaScript bundles.\n\nCloud attack surface\n\nPassive WAF and CDN fingerprinting.\n\nCloud infrastructure hints.\n\nPublic storage references.\n\nSSRF checks against cloud metadata services within authorised scope.\n\nOSINT\n\nDNS records.\n\nRDAP and WHOIS data.\n\nCertificate transparency.\n\nHistorical URLs.\n\nThe important part is not only what the probes execute.\n\nIt is how findings are evaluated.\n\nWhy finding heuristics should be probe-local\n\nA common source of false positives in automated security workflows is context contamination.\n\nImagine a scanner that accumulates all output generated during an assessment phase.\n\nA finding heuristic later searches the entire accumulated output for a pattern.\n\nA signal produced by probe A might accidentally trigger a finding that belongs to probe B.\n\nDark Spear avoids that by evaluating each probe against its own evidence.\n\nThe model is:\n\nProbe → Evidence → Probe-specific heuristic → Proposed finding\n\nRather than:\n\nPhase → Large output blob → Generic heuristic → Finding\n\nThis makes the relationship between a finding and its evidence easier to understand and debug.\n\nIt also improves reproducibility.\n\nIf a finding is incorrect, the auditor can inspect the exact probe that generated it.\n\nAdding an LLM without making it the authority\n\nThe second execution mode uses a ReAct-style agent.\n\nThe agent can analyse the current state and decide which command or action should be attempted next.\n\nThis is useful when the deterministic catalogue does not cover a particular scenario.\n\nHowever, the agent does not become the enforcement authority.\n\nThe execution flow remains conceptually similar to this:\n\nThe agent proposes an action.\n\nThe client sends an execution request.\n\nThe backend validates the target.\n\nThe backend validates the PTES phase.\n\nThe backend validates the tool.\n\nDangerous actions can require explicit operator approval.\n\nOnly then can the command execute.\n\nThis creates an important separation.\n\nThe LLM is responsible for reasoning.\n\nThe backend is responsible for enforcement.\n\nThe human operator remains responsible for approval.\n\nHuman-in-the-loop is not a marketing checkbox\n\n“Human-in-the-loop” is becoming a popular phrase.\n\nSometimes it simply means that a person can watch an AI system running.\n\nThat is not enough.\n\nIn a security assessment, human control should exist at meaningful decision points.\n\nDark Spear introduces operator review at two levels.\n\nTool execution\n\nPotentially dangerous actions can require explicit approval.\n\nFindings\n\nA proposed finding does not automatically become part of the final report.\n\nThe operator reviews it before accepting it.\n\nThis matters because AI-generated findings can sound convincing even when the underlying evidence is weak.\n\nThe system should not confuse a plausible explanation with a validated vulnerability.\n\nEvidence integrity and chain of custody\n\nA finding should not only contain a description.\n\nIt should contain the evidence that supports it.\n\nWhen a finding is accepted, Dark Spear persists its evidence and generates an integrity hash.\n\nThis creates a more defensible workflow.\n\nInstead of asking:\n\nWhy did the AI say this vulnerability exists?\n\nThe reviewer can ask:\n\nWhat evidence produced this finding?\n\nThat distinction is particularly important in professional engagements.\n\nThe report should be derived from validated technical evidence.\n\nNot from the memory of a conversation between a model and an operator.\n\nMapping technical findings to security frameworks\n\nTechnical findings need different forms of context depending on the audience.\n\nA developer may need remediation steps.\n\nA security manager may need risk prioritisation.\n\nA compliance team may need regulatory context.\n\nDark Spear enriches accepted findings with mappings such as:\n\nCVSS v3.1.\n\nCWE.\n\nOWASP.\n\nMITRE ATT&CK.\n\nISO 27001.\n\nENS.\n\nNIS2.\n\nGDPR.\n\nThe mapping is finding-specific.\n\nThe goal is to avoid assigning frameworks purely based on severity.\n\nA critical vulnerability is not automatically associated with every critical MITRE technique.\n\nThe relationship should come from the actual type of finding.\n\nMITRE ATT&CK should describe what happened\n\nMITRE mapping is another area where automation can become misleading.\n\nA static matrix that always shows the same techniques looks impressive.\n\nBut it does not necessarily represent the actual assessment.\n\nDark Spear maps findings to ATT&CK techniques based on the characteristics of the finding.\n\nThe objective is to represent detected behaviour rather than display a decorative coverage matrix.\n\nThe project currently focuses on techniques relevant to non-destructive web security assessments.\n\nDestructive post-exploitation and impact-oriented behaviour are deliberately excluded from the intended scope.\n\nThat is a product decision as much as a security decision.\n\nA professional assessment platform should understand what it is not supposed to do.\n\nThe backend as the trust boundary\n\nOne of the strongest lessons from building this architecture is that AI agents should be treated as untrusted clients.\n\nThat statement may sound harsh.\n\nBut it simplifies the security model.\n\nThe agent can generate unexpected requests.\n\nIt can misunderstand context.\n\nIt can receive manipulated data from the target environment.\n\nIt can attempt actions outside the intended workflow.\n\nTherefore:\n\nNever rely exclusively on the agent to enforce the rules governing the agent.\n\nThe backend must independently enforce:\n\nScope.\n\nTools.\n\nExecution phases.\n\nApproval requirements.\n\nPrompt instructions are useful.\n\nServer-side enforcement is necessary.\n\nWhat I would improve next\n\nDark Spear is an ongoing project.\n\nThe architecture is designed to evolve.\n\nThe areas I am most interested in exploring next include:\n\nBetter evidence correlation.\n\nMore structured attack path visualisation.\n\nImproved agent decision auditing.\n\nStronger reproducibility controls.\n\nMore lab validation scenarios.\n\nBetter false-positive analysis.\n\nAdditional enterprise reporting workflows.\n\nThe interesting part of building an AI-assisted security platform is that the architecture keeps forcing new questions.\n\nHow much autonomy is useful?\n\nWhere should human approval happen?\n\nWhat should the agent be allowed to infer?\n\nWhat must be enforced independently?\n\nThose questions are more important than simply connecting an LLM to a terminal.\n\nFinal thoughts\n\nThe future of automated pentesting will probably include AI agents.\n\nBut autonomous execution is not automatically better automation.\n\nIn professional security assessments, control and accountability matter.\n\nA useful architecture should combine:\n\nDeterministic automation where reproducibility matters.\n\nAI reasoning where exploration adds value.\n\nServer-side enforcement for scope and execution.\n\nHuman approval for meaningful decisions.\n\nEvidence-backed findings.\n\nReporting that connects technical results to business and governance requirements.\n\nThat is the design direction behind Dark Spear.\n\nNot an auto-pwn.\n\nA controlled, evidence-driven platform for authorised security assessments.\n\nThe code is available under the MIT license:\n\nDark Spear — Yoandy Ramírez Delgado\n\nThe project is intended exclusively for authorised security testing, controlled laboratories and engagements with explicit permission.", "url": "https://wpnews.pro/news/building-an-ai-assisted-pentesting-platform-without-creating-an-auto-pwn", "canonical_source": "https://dev.to/evolve-space/building-an-ai-assisted-pentesting-platform-without-creating-an-auto-pwn-4jgd", "published_at": "2026-09-02 20:27:32+00:00", "updated_at": "2026-09-02 20:53:36.214065+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "developer-tools"], "entities": ["Dark Spear", "Ollama Cloud", "MITRE ATT&CK"], "alternates": {"html": "https://wpnews.pro/news/building-an-ai-assisted-pentesting-platform-without-creating-an-auto-pwn", "markdown": "https://wpnews.pro/news/building-an-ai-assisted-pentesting-platform-without-creating-an-auto-pwn.md", "text": "https://wpnews.pro/news/building-an-ai-assisted-pentesting-platform-without-creating-an-auto-pwn.txt", "jsonld": "https://wpnews.pro/news/building-an-ai-assisted-pentesting-platform-without-creating-an-auto-pwn.jsonld"}}