How to Build an AI Agent for Pentesting Without Turning It Into a Black Box
Most security specialists begin using language models as advanced reference tools. A person describes the task, receives a hypothesis, command or code snippet, verifies the answer and independently decides the next action. In this mode the boundary of responsibility remains clear: the model proposes while the specialist evaluates and executes. Even if the response proves incorrect, it is usually possible to reconstruct the workflow and identify the exact step where the error appeared.
With an AI agent the scheme changes. The agent receives a goal, plans several steps, invokes tools, analyzes their output, stores results in memory and continues work with the new context. This approach automates not only individual commands but entire sequences of actions. However, together with speed comes risk: the specialist sees only the final answer and may not understand which hypotheses were tested, which commands were executed and why the agent selected that particular path. At this point the useful assistant turns into a black box.
Agent is not a long prompt
An ordinary LLM answers a request. An agent must independently repeat the working cycle: understand the current state of the task, choose the next step, call the appropriate tool, interpret the result and adjust the plan. It is precisely the ability to act across multiple stages that distinguishes an agent from a chat in which every continuation is initiated by a human.
Define boundaries first, then connect tools
The formulation “find vulnerabilities” is too broad. It does not clarify which targets may be examined, which methods are permitted, when to stop and what constitutes confirmed evidence. A human can restore missing context from a contract, program rules or personal experience. An agent sees only the data and instructions provided to it.
Before launch it is necessary to describe the operational contour:
- goal and expected result;
- permitted nodes, applications and types of checks;
- actions that must not be performed;
- available tools and limits of their use;
- criteria for confirming a discovered issue;
- conditions for stopping;
- cases when human consultation is required;
- format of the log and final report.
Restrictions should be technical rather than purely textual. A prohibition in the system instruction is useful but does not by itself block command execution. The most reliable approach combines instructions with mechanical controls that limit commands, parameters, directories, addresses and available tools at the execution environment level.
Build a minimal working cycle
The first prototype should not attempt to do everything. The more tools and roles appear simultaneously, the harder it becomes to determine the cause of failure. For the start it is enough to implement a short, easily observable and repeatable process that includes obtaining a concrete technical task, formulating one testable hypothesis, selecting an allowed tool, proposing launch parameters, obtaining confirmation for critical actions, executing the check, saving source data and result, explaining what changed in the understanding of the task and proposing the next step.
Do not force the model to reinvent the process
If the agent must be told the working procedure from scratch every time, results will vary more widely and configuration will take longer. Repeatable instructions are best packaged as separate skills that describe the purpose of a tool, allowable parameters, verification sequence, signs of successful outcome and typical errors.
Record the path, not only the final answer
The final report does not reveal the quality of the process. An agent may reach the correct result after systematic hypothesis testing or may obtain it accidentally after dozens of irrelevant actions. From the outside both variants look identical. To distinguish methodology from coincidence it is necessary to preserve the trajectory of work, including the original goal and constraints, the agent’s hypotheses, chosen tools, parameters sent, raw command output, result interpretation, reasons for plan changes, confirmation requests, manual interventions by the specialist and final evidence.
Limit actions technically
The most dangerous configuration is an agent with broad rights and a vague goal. If it has access to a shell, file system, network tools and credentials, a textual prohibition is insufficient. A safe contour should include a separate agent account, minimal file and service rights, an allowlist of tools and operations, parameter validation before execution, prohibition of destructive commands, an isolated execution environment, request-rate limits, confirmation of critical operations and complete logging of calls.
Test refusal as thoroughly as success
A demonstration in which the agent finds a flag confirms only one scenario. Before independent operation the agent must be tested in conditions where the correct result is to stop. A minimal set of negative tests should include attempts to leave the permitted scope, requests for a forbidden tool, access to an unavailable file or secret, malicious instructions in external content, attempts to bypass operation confirmation, repetition of one unsuccessful action in a loop, contradictions between the original goal and new data, and generation of a report without sufficient evidence.
Leave high-error-cost decisions to the specialist
Human-in-the-loop does not mean the human manually controls every command. The specialist’s role is to set boundaries and make decisions where automatic choice is insufficiently reliable. The specialist must intervene if the agent loses the goal, begins to repeat itself, cannot explain the next step, proposes expanding the scope or draws a conclusion that cannot be confirmed by saved data.
AI Pentesting Challenge: from agent assembly to results analysis
CyberED and Standoff Hackbase are conducting a practical AI pentesting challenge. Participation requires basic understanding of penetration testing, web vulnerabilities and command-line work. On 10 September at 19:30 MSK an opening webinar will be held. An expert will assemble a minimal agent live and bring it to launch on the training range. From 10 to 17 September participants will asynchronously configure and improve their agents, search for and exploit vulnerabilities in dynamic tasks on the shared Standoff Hackbase range and monitor the public ranking. On 17 September the expert will demonstrate their own run with an agent, analyze working strategies, dead-end approaches and typical agent-management errors, then summarize the challenge results.
Related articles
TenetBench Benchmark Tests LLMs for Compliance with Professional Ethical Codes
Researchers from the Institute of Information Security Issues at ISP RAS and the Institute of Cybersecurity and Information Protection at RANEPA have developed TenetBench, a benchmark designed to evaluate how well large language models adhere to specific norms in professional codes of ethics. The benchmark generates realistic work-related prompts that may conflict with rules from documents such as the Code of Professional Ethics for Advocates or journalistic standards on undisclosed advertising. Each test case pairs a conflicting request with a neutral counterpart to measure whether models refuse, warn, or still provide prohibited content. Evaluation separates task completion, norm violation detection, and presence of explicit refusals using an LLM-as-a-Judge approach validated against human annotators. The full dataset contains 3,433 prompt pairs derived from 15 professional codes, with a public subset of 2,235 pairs from 10 documents. Human validation confirmed 99.5% of generated examples as fully plausible work scenarios.
Solar to Showcase Solar AI Firewall for Business Protection Against AI Risks at SOC Forum 2026
GK Solar will present its new Solar AI Firewall solution at SOC Forum 2026 to help organizations control interactions with AI services and prevent confidential data leaks through employee prompts. The product addresses growing risks from staff sending corporate data to neural networks and AI agents gaining access to internal systems. The forum takes place on 27-28 October in Moscow's Lomonosov cluster, with the official launch of Solar AI Firewall scheduled during the event. Solar will also highlight practical risks of AI adoption, including data transmission to external services, use of public models by employees, and new attack surfaces in corporate infrastructure. The solution will be demonstrated as part of an integrated ecosystem for access, network, and data protection. In addition, the company plans to introduce JSOC ONE, a new line of Solar JSOC services tailored for mid-sized businesses that require 24/7 monitoring without building their own SOC.
Researcher Runs 100 Abliterated AI Agents Against His Own Accounts, Achieves Five Successful Breaches
A security researcher deployed roughly 100 autonomous AI agents based on abliterated open-source models to attempt unauthorized access to his online accounts over a five-hour period. The agents successfully compromised three accounts by exploiting vulnerabilities in legacy personal projects and two additional accounts through password reuse and credential stuffing. They also conducted 16 social engineering attempts, harvested and cross-verified personal data from public sources, and generated phishing pages targeting the researcher's Substack and Hacker News presence. Despite these successes, the agents failed to discover any zero-day vulnerabilities in third-party software or gain access to Tier-0 accounts such as Gmail, 1Password, or banking services. The experiment relied on abliterated versions of GLM-5.3 and DeepSeek V4 Flash models running on cloud GPUs, orchestrated via Codex CLI inside Docker containers with access to Railway infrastructure. Total compute cost reached approximately $210, equating to roughly $40 per successful account compromise. The researcher concluded that inexpensive swarms of such agents could soon enable low-skill attackers to systematically map and exploit an individual's entire online footprint.
How Censorship in Closed AI Models Reshapes Science: Hugging Face Releases Open Carbon-X DNA Model
Hugging Face CEO Clement Delangue announced the release of Carbon-X, an open 14.8 billion parameter language model designed for reading, analyzing, and generating DNA sequences. The announcement highlighted how shallow guardrails in closed commercial models blocked even proofreading a tweet discussing the topic. Commenters and researchers pointed out that these input/output filters lack context awareness, blocking legitimate scientific queries while motivated adversaries bypass them through rephrasing. Carbon-X was built on Qwen3-14B with a hybrid BPE and 6-mer tokenizer, domain mid-training on 302 billion tokens, and safety achieved through data curation rather than runtime censorship. The model achieves performance comparable to closed frontier systems at roughly 1/1800th the inference cost for large-scale genomic tasks. The case underscores growing asymmetry between closed corporate AI labs building wet labs and independent researchers restricted by superficial safety layers.