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
AI Agents Becoming Core InfoSec Skill Like Microsoft Office Proficiency
Working with AI in information security is shifting from a specialized skill to a baseline expectation similar to using Microsoft Office tools. The key difference lies in the cost of errors: poor Word usage wastes time, while mishandling AI agents burns subscription limits and corporate funds. The article details practical workshops from the Engineering October series covering AI agents from beginner tools to securing the agents themselves. Core concepts include distinguishing models from agents, managing context windows to prevent forgotten instructions, and using skills, MCP connectors, and sub-agents for efficiency. Real-world examples show agents handling CVE analysis, alert triage, and threat report reviews while highlighting risks like hallucinations and data exposure. Guidance covers safe deployment in isolated environments and the irreplaceable role of human expertise in strategy and verification.
Research Exposes Limitations in AI Skill Scanners for Agent Vulnerability Detection
An independent researcher evaluated three local vulnerability scanners for AI agent skill packages without using LLMs or external APIs. The test used 12 synthetic packages containing both benign and malicious instructions, including attempts to bypass consent via sub-agents and hidden instructions in nested files. Cisco Skill Scanner, NVIDIA SkillSpector, and AgentVerus were run in isolated containers. All three tools missed a critical delegation bypass in package 10, while correctly flagging an educational attack citation in package 5 as High severity. NVIDIA SkillSpector performed best on nested file detection, and the findings directly shaped the integration of a lightweight static analyzer plus optional NVIDIA scans into the CEO AI project. The study also highlighted the need to preserve detailed findings rather than relying solely on final safety scores.
Apple Tightens App Store Rules Against Non-Consensual Intimate AI Deepfakes
Apple has updated its App Store guidelines to explicitly prohibit applications that generate intimate deepfake images of real individuals without consent. Developers must now implement measures to prevent creation and distribution of such content and promptly remove any instances that appear. The company also banned the practice of submitting apps with hidden functionality that is activated after passing review, a tactic previously used by undressing services. Violations can result in both app removal and expulsion from the Apple Developer Program. The move follows similar actions against xAI's Grok chatbot, which added safeguards after Apple threatened removal over the same issue. The policy targets non-consensual intimate imagery rather than all deepfake technology.
CyberXero Deploys 51 AI Agents to Scan 4708 Targets and Implant 32 WebShells in 61 Seconds
Russian-speaking initial access broker CyberXero integrated Anthropic's Claude Code and the open-source PentAGI autonomous penetration agent into its attack pipeline, creating a cluster of 51 specialized AI agents. The group ran two parallel operations: one automated campaign targeting vulnerable WordPress and e-commerce sites worldwide using known exploits including CVE-2026-63030, CVE-2026-60137 and CVE-2026-4815, and a second, more targeted campaign against Ukrainian energy and critical infrastructure. In one recorded execution the AI cluster scanned 4708 public-facing hosts, compromised 429 WordPress administrative panels and dropped 32 WebShells within a 61-second window. Attackers bypassed model safety guardrails by resetting sessions and reframing requests as authorized penetration tests of their own infrastructure. The operation relied on an eight-node architecture that included a Linux workstation, configuration server, payload staging server and public Redis instances, two of which belonged to Chinese organizations. SOCRadar warns that session-level controls alone are insufficient and recommends enforcing system-level boundaries, minimal privileges and strict egress filtering for any AI agents.