AI agents are becoming increasingly capable of interacting with tools.
In cybersecurity, that creates an obvious opportunity: let an agent inspect a target, run reconnaissance, interpret the output and decide what to test next.
It also creates an obvious problem.
What happens when the agent decides to do something that should not be done?
That question became one of the design constraints behind Dark Spear, an AI-assisted platform for authorised security assessments.
Dark Spear was not designed as an autonomous exploitation engine.
The goal was different:
Build an automated pentesting workflow that can move through an engagement while keeping scope enforcement, dangerous tool approval and evidence integrity under human control.
This article explains the architecture behind that decision.
The problem with “autonomous pentesting”
Automation is not new in offensive security.
We already automate:
Port scanning.
Directory discovery.
Technology fingerprinting.
Credential testing.
Vulnerability detection.
OSINT collection.
Report generation.
The difference with AI agents is that they can dynamically decide what to do next.
That flexibility is useful.
A deterministic scanner can only execute what its author anticipated.
An agent can potentially react to unexpected output.
But flexibility introduces a new trust boundary.
If an AI agent has access to security tools, the system needs to answer several questions:
What targets is the agent allowed to interact with?
What tools can it execute?
Which actions require explicit human approval?
Can the client-side agent bypass restrictions?
How are findings verified?
What evidence proves a finding?
Can the final report be defended and reproduced?
Dark Spear treats those questions as architecture problems rather than prompt engineering problems.
Architecture overview
The platform has three major components.
- Browser-side assessment engine
The assessment engine contains two execution modes.
The first is deterministic.
The second is agentic.
The browser orchestrates the workflow and communicates with the backend only when an approved binary needs to be executed.
The main engine includes:
PTES phase orchestration.
Probe definitions.
Vulnerability knowledge bases.
Finding heuristics.
LLM agent orchestration.
Ollama Cloud integration.
Bridge client communication.
- Trusted backend bridge
The backend is the enforcement point.
This is deliberate.
The browser is not trusted to enforce security boundaries.
The backend applies:
Tool allowlisting.
Target scope locking.
PTES phase gates.
Dangerous action approval.
Finding persistence.
Evidence hashing.
Encrypted API key storage.
The client can request an action.
The server decides whether that action is allowed.
That separation is fundamental when an AI agent can generate commands dynamically.
- SecOps reporting console
The third component is the operational layer.
Security testing is only part of an engagement.
The results need to be reviewed, correlated and communicated.
The console provides views for:
Active engagements.
Tool approval.
Findings.
Critical vulnerabilities.
Attack graphs.
MITRE ATT&CK mapping.
OSINT.
Governance.
Risk maturity.
Remediation planning.
Reporting.
The goal was to avoid treating the scanning engine and the reporting system as separate projects.
They are parts of the same workflow.
Deterministic mode versus LLM agents
One of the design decisions was to avoid making the LLM mandatory.
The platform supports two modes.
Deterministic playbooks
The deterministic mode follows a curated catalogue of security probes.
It does not require an LLM.
It does not consume inference tokens.
And its execution path is reproducible.
The probes cover multiple categories:
Injection
SQL injection.
NoSQL injection.
Reflected XSS.
Open redirects.
Generic IDOR checks.
Authentication and sessions
Default credentials.
Cookie security attributes.
Missing security headers.
JWT testing
Weak HS256 secret cracking performed locally.
alg=none validation where applicable.
Active reconnaissance
Technology fingerprinting.
Content discovery.
robots.txt analysis.
CORS configuration.
HTTP TRACE exposure.
Code and configuration exposure
Accessible .git directories.
Environment files.
Backup files.
Source maps.
Public API documentation.
Metrics endpoints.
Secrets exposed in JavaScript bundles.
Cloud attack surface
Passive WAF and CDN fingerprinting.
Cloud infrastructure hints.
Public storage references.
SSRF checks against cloud metadata services within authorised scope.
OSINT
DNS records.
RDAP and WHOIS data.
Certificate transparency.
Historical URLs.
The important part is not only what the probes execute.
It is how findings are evaluated.
Why finding heuristics should be probe-local
A common source of false positives in automated security workflows is context contamination.
Imagine a scanner that accumulates all output generated during an assessment phase.
A finding heuristic later searches the entire accumulated output for a pattern.
A signal produced by probe A might accidentally trigger a finding that belongs to probe B.
Dark Spear avoids that by evaluating each probe against its own evidence.
The model is:
Probe → Evidence → Probe-specific heuristic → Proposed finding
Rather than:
Phase → Large output blob → Generic heuristic → Finding
This makes the relationship between a finding and its evidence easier to understand and debug.
It also improves reproducibility.
If a finding is incorrect, the auditor can inspect the exact probe that generated it.
Adding an LLM without making it the authority
The second execution mode uses a ReAct-style agent.
The agent can analyse the current state and decide which command or action should be attempted next.
This is useful when the deterministic catalogue does not cover a particular scenario.
However, the agent does not become the enforcement authority.
The execution flow remains conceptually similar to this:
The agent proposes an action.
The client sends an execution request.
The backend validates the target.
The backend validates the PTES phase.
The backend validates the tool.
Dangerous actions can require explicit operator approval.
Only then can the command execute.
This creates an important separation.
The LLM is responsible for reasoning.
The backend is responsible for enforcement.
The human operator remains responsible for approval.
Human-in-the-loop is not a marketing checkbox
“Human-in-the-loop” is becoming a popular phrase.
Sometimes it simply means that a person can watch an AI system running.
That is not enough.
In a security assessment, human control should exist at meaningful decision points.
Dark Spear introduces operator review at two levels.
Tool execution
Potentially dangerous actions can require explicit approval.
Findings
A proposed finding does not automatically become part of the final report.
The operator reviews it before accepting it.
This matters because AI-generated findings can sound convincing even when the underlying evidence is weak.
The system should not confuse a plausible explanation with a validated vulnerability.
Evidence integrity and chain of custody
A finding should not only contain a description.
It should contain the evidence that supports it.
When a finding is accepted, Dark Spear persists its evidence and generates an integrity hash.
This creates a more defensible workflow.
Instead of asking:
Why did the AI say this vulnerability exists?
The reviewer can ask:
What evidence produced this finding?
That distinction is particularly important in professional engagements.
The report should be derived from validated technical evidence.
Not from the memory of a conversation between a model and an operator.
Mapping technical findings to security frameworks
Technical findings need different forms of context depending on the audience.
A developer may need remediation steps.
A security manager may need risk prioritisation.
A compliance team may need regulatory context.
Dark Spear enriches accepted findings with mappings such as:
CVSS v3.1.
CWE.
OWASP.
MITRE ATT&CK.
ISO 27001.
ENS.
NIS2.
GDPR.
The mapping is finding-specific.
The goal is to avoid assigning frameworks purely based on severity.
A critical vulnerability is not automatically associated with every critical MITRE technique.
The relationship should come from the actual type of finding.
MITRE ATT&CK should describe what happened
MITRE mapping is another area where automation can become misleading.
A static matrix that always shows the same techniques looks impressive.
But it does not necessarily represent the actual assessment.
Dark Spear maps findings to ATT&CK techniques based on the characteristics of the finding.
The objective is to represent detected behaviour rather than display a decorative coverage matrix.
The project currently focuses on techniques relevant to non-destructive web security assessments.
Destructive post-exploitation and impact-oriented behaviour are deliberately excluded from the intended scope.
That is a product decision as much as a security decision.
A professional assessment platform should understand what it is not supposed to do.
The backend as the trust boundary
One of the strongest lessons from building this architecture is that AI agents should be treated as untrusted clients.
That statement may sound harsh.
But it simplifies the security model.
The agent can generate unexpected requests.
It can misunderstand context.
It can receive manipulated data from the target environment.
It can attempt actions outside the intended workflow.
Therefore:
Never rely exclusively on the agent to enforce the rules governing the agent.
The backend must independently enforce:
Scope.
Tools.
Execution phases.
Approval requirements.
Prompt instructions are useful.
Server-side enforcement is necessary.
What I would improve next
Dark Spear is an ongoing project.
The architecture is designed to evolve.
The areas I am most interested in exploring next include:
Better evidence correlation.
More structured attack path visualisation.
Improved agent decision auditing.
Stronger reproducibility controls.
More lab validation scenarios.
Better false-positive analysis.
Additional enterprise reporting workflows.
The interesting part of building an AI-assisted security platform is that the architecture keeps forcing new questions.
How much autonomy is useful?
Where should human approval happen?
What should the agent be allowed to infer?
What must be enforced independently?
Those questions are more important than simply connecting an LLM to a terminal.
Final thoughts
The future of automated pentesting will probably include AI agents.
But autonomous execution is not automatically better automation.
In professional security assessments, control and accountability matter.
A useful architecture should combine:
Deterministic automation where reproducibility matters.
AI reasoning where exploration adds value.
Server-side enforcement for scope and execution.
Human approval for meaningful decisions.
Evidence-backed findings.
Reporting that connects technical results to business and governance requirements.
That is the design direction behind Dark Spear.
Not an auto-pwn.
A controlled, evidence-driven platform for authorised security assessments.
The code is available under the MIT license:
Dark Spear — Yoandy Ramírez Delgado
The project is intended exclusively for authorised security testing, controlled laboratories and engagements with explicit permission.
Top comments (0)