CLAI — Autonomous Pentesting with LLM Agents

The premise

Automated pentesting has existed for two decades. Tools like Nessus, OpenVAS, and Metasploit Pro scan networks, identify vulnerabilities, and sometimes exploit them — all based on signatures, rules, and predefined playbooks. They are fast, reliable, and deterministic. They are also rigid: a scanner does not adapt its strategy when it encounters an unusual service, does not reason about the output of a command, and does not chain unrelated findings into an exploit path.

The emergence of LLM-based agents changes that equation. An LLM agent reads the output of nmap, decides what to run next based on what it sees, evaluates the results, and adapts. It does not follow a playbook — it plans. When a port turns out to be filtered, it tries a different approach. When a service returns an unexpected banner, it searches for that specific version. When a command fails, it reads the error and adjusts.

CLAI is an open-source implementation of this idea. It is a terminal-native CLI agent that runs real tools — nmap, gobuster, ffuf, sqlmap, hydra — and uses an LLM backend to decide which tool to run and how to interpret the output. It is not a scanner with an LLM bolted on. It is an agent that happens to do pentesting.

This project is the result of using CLAI to autonomously root two HackTheBox machines — Lame (Easy, Linux) and Cap (Easy, Linux) — using NVIDIA’s Nemotron 3 Ultra 550B model via the NIM API. Both machines were rooted, but not without intervention. The writeup covers what worked, what did not, and why the gap between “good enough to impress” and “good enough to rely on” is still significant.

What CLAI is

CLAI is a Node.js CLI application that runs in the terminal. It is not a GUI, not a web app, and not a framework that requires integration into an existing toolchain. It is a single command that opens an interactive session, and everything happens inside that session.

The architecture has three layers:

The execution layer (Node.js). CLAI runs as a Node.js process. It executes shell commands, captures stdout and stderr, manages persistent PTY sessions (for tools like Metasploit or interactive Python shells), and maintains the conversation state. It is the runtime that everything else plugs into.

The agent layer (CLAI). The agent is the logic that decides what to run. It has access to a set of tools — shell execution, file read/write, HTTP fetch, DNS lookup, whois — and it uses the LLM to decide which tool to invoke with what arguments. The agent maintains a task plan, tracks progress, and verifies its own work before claiming success.

The intelligence layer (NVIDIA NIM). The LLM is the reasoning engine. CLAI is provider-agnostic — it supports Google Gemini, OpenRouter, Ollama, and NVIDIA NIM. In this engagement, the backend was NVIDIA’s Nemotron 3 Ultra 550B A55B, served through the NIM API.

The division of labor is clean: Node.js executes, CLAI orchestrates, the LLM decides.

The model — Nemotron 3 Ultra 550B

The choice of model matters more than any other configuration in the pipeline. The NVIDIA Nemotron 3 Ultra 550B A55B is a Mixture-of-Experts (MoE) model with 550 billion total parameters and 55 billion active parameters per token. It uses a hybrid Mamba-Transformer architecture, which allows it to maintain coherent reasoning across extremely long contexts — up to 1 million tokens.

For an agentic pentesting session, the context length is the constraint that matters most. A full engagement — reconnaissance, enumeration, exploitation, post-exploitation — generates thousands of lines of output. A model with a short context window loses the thread after the first few tool calls. A model with a 1M-token window can maintain the full session in context, which means it can reason about the whole engagement, not just the last command.

NVIDIA’s benchmarks claim 85-92% completion rates on tasks requiring 200+ sequential tool calls, compared to below 40% for standard open models. In practice, this means the agent can maintain a coherent plan across an entire pentest session without losing track of what it has already tried.

The model is available through the NVIDIA NIM API. The free tier provides enough capacity for a session of a few hours, which is what this evaluation used.

Scope enforcement

The first thing CLAI requires is a scope definition. Before any command runs, the agent needs to know what targets are authorized, what targets are excluded, and what phases are permitted.

clai authorize-pentest AGREE
clai scope new --targets 10.10.10.3,10.10.14.5 \
  --phases recon,enumeration,exploitation \
  --max-rate 5 --max-concurrency 2

The scope is not cosmetic. It is enforced on every action. When the agent tries to run a command against an IP address, CLAI checks that address against the authorized list. When a command returns a redirect to an out-of-scope host, CLAI blocks it. When the agent’s rate of requests exceeds the configured ceiling, CLAI throttles it.

The scope definition is critical for two reasons. First, it is a legal and ethical boundary — the agent should not touch anything outside the defined scope, even if it discovers a path to it. Second, it is a safety mechanism — an agent that scans an entire /8 network because it misread an IP address is a problem that a scope definition prevents.

The lesson learned during this engagement: the scope must include not just the target IP, but also the attacker’s own IP. Without the attacker’s IP in the scope, CLAI blocks reverse shells and callback connections — because the agent is trying to connect back to an address that is not in the authorized list. The scope is not just “what am I allowed to attack,” it is “what am I allowed to interact with.” This is not documented prominently, and it is the kind of thing that blocks a session silently until you understand why.

Safety gates

CLAI implements a three-level safety gate that classifies every action:

Safe. Read-only operations — file reads, directory listings, DNS lookups, whois queries, HTTP GET requests, and reconnaissance scans. These run automatically without confirmation.

Confirm. Mutating operations — file writes, package installations, aggressive shell commands, exploitation attempts. These require explicit user confirmation before execution.

Block. Destructive patterns — rm -rf /, fork bombs, classic data exfiltration signatures, SSRF-prone fetches. These are refused outright, regardless of context.

The gate is the difference between an autonomous agent and a runaway process. Without it, an LLM that hallucinates a destructive command would execute it. With it, the destructive command is caught at the gate before it reaches the shell.

In practice, the confirm level is where most of the interaction happens. The agent proposes an exploit, the user reviews the command, and the user approves or rejects. For a fully autonomous run, the user can lower the gate threshold — but the default configuration requires human review of anything that mutates state.

The engagement — Lame

Lame is a classic HackTheBox Easy machine. It runs an old version of Samba with a known remote code execution vulnerability (CVE-2007-2447, the “username map script” issue), and the path to root involves exploiting the Samba version and then using the obtained access to escalate.

Reconnaissance. CLAI started with an nmap scan — a full TCP port sweep followed by service detection. The model correctly identified the open ports, the service versions, and the operating system. It recognized that the Samba version was old and flagged it as potentially vulnerable.

Enumeration. The agent ran enum4linux and smbclient to enumerate shares, users, and the Samba configuration. It identified the Samba version as 3.0.20, which is vulnerable to the username map script RCE.

Exploitation attempt. This is where the first stall happened. The agent tried to exploit the Samba vulnerability, but the initial attempt failed — the reverse shell did not connect back. The agent read the error, tried a different payload, and failed again.

The hint. After approximately 40 minutes of enumeration and failed exploitation attempts, the agent was stuck. It had correctly identified the vulnerability but could not get the exploit to work. The user provided a hint — not the exploit itself, but a nudge toward the correct Metasploit module and the correct payload type.

Success. With the hint, the agent ran the exploit successfully, obtained a root shell, and captured the flag. Total time: approximately 50 minutes, including the stalled period.

What worked: The enumeration was thorough and accurate. The agent identified the vulnerability without help, and it correctly interpreted the enum4linux output to find the Samba version.

What did not work: The agent struggled with the exploit payload. It tried the right vulnerability but the wrong payload configuration — the reverse shell did not connect, and the agent did not diagnose why. This is a recurring pattern with LLM agents: they understand the vulnerability conceptually but fail at the specific operational details of exploitation.

The engagement — Cap

Cap is another Easy Linux machine. It involves a web application with an IDOR vulnerability that leaks a packet capture file, which contains FTP credentials, which lead to SSH access, which exposes a Python capability that allows privilege escalation.

Reconnaissance. The agent ran nmap, identified the web server, and started directory enumeration with gobuster. It found the web application and began exploring.

Enumeration of the web app. The agent identified a parameter that was vulnerable to IDOR. It found that changing the parameter value from one number to another exposed a packet capture file — a .pcap file that could be downloaded and analyzed.

The IDOR discovery. This is where the second stall happened. The agent explored the web application, enumerated the parameters, and tried several values, but did not identify the parameter that was vulnerable to IDOR. It had the tools and the technique — it simply did not spot the vulnerability.

The hint. The user provided a hint — a pointer to the specific parameter. Once the agent knew where to look, it confirmed the IDOR, found the pcap file, downloaded it, and extracted the FTP credentials from the packet capture correctly. The credential extraction was done without further help.

Foothold. With the FTP credentials, the agent logged in, found the SSH credentials in the FTP home directory, and obtained an SSH session.

Privilege escalation. The agent enumerated the system, identified that Python had the cap_setuid capability, and exploited it to get a root shell. This step was done without hints — the agent correctly identified the capability and constructed the correct Python one-liner to exploit it.

What worked: The IDOR discovery, the pcap download, the privilege escalation.

What did not work: The IDOR discovery required a hint. The agent explored the web application but did not identify the parameter that was vulnerable to IDOR. Once the user pointed at the parameter, the agent found the pcap, downloaded it, and extracted the FTP credentials from it without further help — that part it did correctly on its own.

What the agent does well

Enumeration. The agent is genuinely good at enumeration. It runs the right tools, reads the output correctly, and identifies the relevant findings. In both engagements, the enumeration was accurate and thorough. The agent did not miss open ports, did not misidentify services, and did not fail to flag known vulnerabilities. This is the phase where it delivers the most value — the enumeration is complete enough to serve as a starting point for a human pentester, or as a standalone vulnerability assessment.

Planning. The agent maintains a coherent plan across the session. It does not repeat work, does not lose track of what it has already tried, and does not forget the objective. The durable plan feature — the task checklist that survives context compaction — is what makes this possible.

Adaptation. When a command fails, the agent reads the error and adjusts. It does not blindly retry the same command. It tries a different tool, a different approach, or a different payload.

Post-exploitation. Once the agent has a shell, it enumerates the system for privilege escalation paths. It checks for SUID binaries, capabilities, cron jobs, and writable files. It correctly identified the Python capability on Cap without help.

What the agent does not do well

Exploitation details. The agent understands vulnerabilities conceptually but struggles with the specific operational details. On Lame, it knew Samba was vulnerable but could not configure the Metasploit module correctly. The gap between “this vulnerability exists” and “this is the exact command to exploit it” is where the agent fails. This is the boundary between enumeration and exploitation — and it is the boundary between what the current generation of agents can do reliably and what still requires a human operator.

Vulnerability identification. On Cap, the agent had the correct tooling and the correct methodology, but did not spot the IDOR vulnerability in the web application. It explored the parameters, tried different values, and moved on — without recognizing the pattern. A human pentester with experience recognizes the shape of an IDOR from the application’s behavior. The agent does not have that pattern recognition, at least not at this model tier.

Payload delivery. The reverse shell problem is a recurring theme. The agent constructs a reverse shell command, but the shell does not connect back. The reasons can be varied — the wrong IP address, the wrong port, the firewall, the scope restriction — and the agent does not diagnose which one applies.

Silent failures. When a command fails, the agent reads the error and adjusts. When a command succeeds but does not produce the expected output, the agent does not always recognize that something is wrong. A silent failure is worse than a loud one, because it leads the agent down a path that looks correct but is not.

The scope gotcha

The scope definition is the most important configuration, and it has a non-obvious requirement: the attacker’s IP must be in the scope.

When the agent constructs a reverse shell, the payload includes the attacker’s IP address as the callback destination. CLAI checks that address against the scope. If the attacker’s IP is not in the authorized list, the reverse shell is blocked — not because the agent did something wrong, but because the scope definition does not cover the full interaction.

The fix is simple: add the attacker’s IP to the scope.

clai scope add 10.10.14.5  # attacker IP

But the fact that this is required is not obvious from the documentation. It is the kind of thing that blocks a session silently, and the agent does not explain why the reverse shell is not connecting — it just reports that the connection failed.

Free tier vs paid tier

This evaluation used the NVIDIA NIM free tier with Nemotron 3 Ultra 550B. The free tier provides access to the model, but with rate limits and capacity constraints.

What the free tier provides: The model is capable. It is not a small model pretending to be large — it is a 550B MoE with genuine reasoning capability. The free tier gives access to the full model, not a distilled version.

What the free tier limits: Rate limits. The free tier throttles requests, which slows the agent down. For a session that requires dozens of tool calls, the throttling adds latency. The agent does not fail because of the rate limit — CLAI handles the retries — but the session takes longer than it would with a paid tier.

What a paid tier would change: Faster response times, no throttling, and potentially access to models with different capabilities. The reasoning quality is already good on the free tier; the paid tier primarily buys speed and reliability.

The gap between free and paid is not about capability. It is about throughput. The model on the free tier is the same model that would run on the paid tier — the difference is how fast and how often you can use it.

The bigger picture — where this is going

The current state of LLM-based autonomous pentesting is best described as “promising but incomplete.” The agent can enumerate, plan, and adapt. It cannot reliably exploit without human hints. It can identify vulnerabilities but cannot always operationalize them.

That gap is closing. The models are improving at a rate that makes predictions about “where this will be in two years” unreliable. The 550B model used in this evaluation is already capable enough to root Easy machines with hints. A model trained specifically for security tasks — with reinforcement learning on pentesting trajectories — would be substantially better.

The more interesting question is not whether LLM agents will be able to pentest autonomously. It is what role they will play in the pentesting workflow. The current generation is a strong enumeration and vulnerability discovery tool — it can run a credible vulnerability assessment on its own, which is useful for organizations that do not have the budget for a full pentest. It is not a replacement for a human operator on a full engagement, because exploitation requires reading unusual outputs, chaining findings creatively, and making judgment calls that the agent does not reliably make. Those are the skills that remain valuable, and they are the skills that the current generation of agents does not have.

Detection and defense

From a defender’s perspective, an LLM-driven pentest looks similar to a human-driven one — the same tools, the same network traffic, the same exploitation attempts. The difference is in the patterns:

Rapid enumeration. The agent enumerates faster than a human. It runs the tools back-to-back without breaks, without reviewing output manually, without switching between terminals. The tempo of the scan is higher.

Consistent pacing. The agent does not get tired, does not skip steps, and does not take shortcuts. It follows the same process every time. The consistency is detectable — a human pentester has variable pacing; an agent does not.

Tool signatures. The agent uses specific tools in specific ways. The nmap flags it chooses, the gobuster wordlist it uses, the ffuf parameters it sets — these are patterns. If an organization baselines what a human pentester’s traffic looks like, an agent’s traffic will be different in subtle ways.

The defense is the same as it has always been: monitor the network, baseline the normal, alert on the abnormal. The agent does not change the fundamentals of detection. It changes the speed and consistency of the activity being detected.

Takeaway

CLAI is a working implementation of an idea that is still in its early days. It autonomously enumerated two HackTheBox machines, identified the vulnerabilities, and — with minimal hints — rooted both. It is not a replacement for a human pentester. It is a tool that a human pentester can use to accelerate the enumeration phase of an engagement, and — for organizations that need a vulnerability assessment rather than a full penetration test — it is already useful on its own.

The limitations are real and worth understanding. The agent struggles with exploit details, lacks specific tool knowledge, and does not always diagnose why a payload failed. These are the gaps that the next generation of models — trained specifically on security tasks, with reinforcement learning on pentesting trajectories — will close.

The scope requirement is a practical lesson: the attacker’s own IP must be in the authorized list for reverse shells to work. This is a small detail with a large impact, and it is the kind of thing that only becomes obvious after it blocks a session.

The free tier is capable enough for evaluation. The paid tier buys speed, not capability. The model is the same model either way.

The question is not whether LLM agents will be able to pentest autonomously. They already can, partially. The question is how quickly the “partially” becomes “fully,” and what that means for the profession. The answer is not obvious, and anyone who claims to know is guessing. What is obvious is that the trajectory points in one direction, and the tools are getting better every month.