How to Hack Using AI Agents (and what happens when the model stops saying no)

A hands-on field guide to Cleus Smartest v3, the agent loop, and the tools that used to need a terminal and three tabs.

Most "AI for hacking" content is a screenshot of ChatGPT writing nmap flags you already knew. That is autocomplete with a security theme. It is not what changed.

What changed is that a model can now hold a job: look at a target, read what came back, pick the next move, run it, read that, and keep going until there is either a finding or a dead end worth writing down. The interesting part is not the typing. It is the loop, and the fact that the loop survives contact with weirdness instead of stopping at "this is usually done with a tool like…".

I spent a day running that loop on Cleus's new model, the one they call Cleus Smartest v3. Below are real outputs, including the parts where it found nothing and the parts where it found three criticals in 85 requests. I have also included the section most launch posts skip: the places it still falls over.

What v3 actually is, in plain terms

Cleus Smartest v3 is their uncensored reasoning model, and Cleus Fast v3 is the same weights with the thinking switch off, so you get the same instincts without the pause. Both are stamped Beta in the model picker, which is fair.

Three things about it matter for security work, and none of them are benchmark numbers:

• It has the fewest refusals of anything in the picker. An agent that stops mid-chain to say "typically, one would…" is worse than no agent, because you have to re-prompt it and re-explain the state.
• Thinking is a slider with five stops, default Medium. You can turn it to Max on a chain that keeps breaking and watch the trace as it works. You can also turn it to Off and get an answer in a second. Same weights either way.
• It works inside end-to-end encrypted chats, which is where client work belongs.

The context window is long enough to paste a HAR file, a stack trace and three thousand lines of nginx config in one go, which is roughly how much junk a real investigation throws at you.

The loop is five verbs

Cleus puts this behind Hacker Mode, a shield toggle under the chat box that only appears when Cleus Agent is selected. The backend checks your subscription before it will expose the tools at all, and before the first live target it makes you state that you own or are authorised to test it. That authorisation is stored for the chat, which is a small thing that saves a large argument later.

Once it is on, the model is not doing anything magic. It is running a loop.

Step two's output changes step three's input. That is the whole difference between this and a scanner: a scanner runs a list, an agent reads the result and chooses.

What the tools are, and why they route themselves

Nobody types a tool name. You write a sentence, the model reads intent, picks the instrument and chains it.

The registry has fourteen security tools. Passive and read-only: recon (DNS, certificate-transparency subdomains, WHOIS/RDAP, header fingerprint), security_scan (a Python posture scanner checking TLS, headers, cookies, CORS, mixed content, version leaks), tls_inspect, cve_lookup (NVD plus EPSS and CISA's exploited-in-the-wild list), email_security (SPF, DKIM, DMARC, MTA-STS, DNS only), hash_tool, jwt_tool, decode_tool, breach_check. Active but non-destructive: web_scan (headers, cookie flags, CORS misconfig, exposed paths like /.git/config and /.env) and active_scan, the only one that sends payloads. Output: parse_findings and export_report. There is also run_code for anything the fixed tools do not cover, and port_scan when you genuinely need TCP.

The questions to ask yourself are the same as with any pentest: what does each one cost the target, and what does it prove?

The loop, run for real

One: a site that grades itself badly

I pointed it at Cleus's own homepage, quick profile, one page, read-only.

Grade C. 25 out of 100. No CSP, no clickjacking protection, a locale cookie with no security attributes, and HSTS missing. TLS was fine: 1.3, trusted chain, 32 days to expiry, which is the sort of detail you only notice when someone bothers to check.

A C is not a fire. There is no RCE and no leaked key in that list. But the page ships without a Content Security Policy, so the first injected script gets a free run, and that is the difference between a stored XSS being annoying and being a credential harvester.

Two things are worth noticing. First, the scanning is not only for other people's sites. Second, it reported its own house's miss without softening it.

Two: recon that touches nothing

Next, a domain from a vendor invoice with no other context: "recon acunetix.com, subdomains, whois, what it runs."

The A record sits behind Cloudflare, the MX points at Outlook, and the SPF record ends in -all, so the mail domain is hard to spoof without also owning an allowed sender. Certificate transparency turned up eighteen hosts, and staging. and erp. are the ones a human would chase first, because staging boxes are where the stale copy of the app lives with the debug flag still on.

Nine seconds. Public resolvers only. Nothing on the target's servers logged a packet.

Three: the one that sends payloads

For an active test, use something built to be broken. testasp.vulnweb.com is an old Acunetix lab box.

Prompt: "test this URL for injection," plus ?id=2. Eighty-five requests later:

Three criticals. The command injection is proven the boring way: a unique marker string goes in as ;echo cleuscmd9a6decf9, the same string comes back in the response, so the input reached a shell. Once on /Login.asp, once on /Register.asp. The traversal returns windows/win.ini from eight ../ deep on a template parameter.

This is the honest middle of the spectrum. It is not a guess, and it is not a full exploit: no shell was opened and nothing was exfiltrated. What you have is a marker, a parameter, a file path and a fix, which is exactly what a ticket needs.

Four: a finding is a card, not a paragraph

Model prose drifts. It renames headers, rounds severities and invents a CVSS if you let it. So the report is not generated by the model: it is rendered from the scanner's JSON, and the model is instructed to summarize in two to four sentences without repeating the table.

Every finding carries an id, a severity, the evidence it saw, a CWE number and a remediation. If the scan fails, the card says so and the model is told not to fill the gap. You can then export the set to PDF, DOCX or CSV and hand it to someone who will actually change the code.

Six things you can try tonight

None of these need a lab, and only the third sends payloads.

For the ones not reproduced above: paste a version banner into cve_lookup and you get CVSS, EPSS and whether CISA lists it as exploited; drop a JWT from a browser tab into jwt_tool and it decodes the claims, flags alg:none and absurd lifetimes, then tries to crack a weak HS256 secret; paste four hundred lines of nuclei output into parse_findings and it dedupes and ranks before export_report builds the file.

Where Cleus Code comes in

Cleus Agent is the chat. Cleus Code is the same account with a terminal attached, running on your own machine, and that is where the loop stops being a demo.

Agent chat is deliberately fenced: fixed tools, no POSTs, no brute force, nothing that writes to disk. Cleus Code has none of those fences. It runs your nmap, your ffuf, your git, your nuclei, your docker and your own Python, reads the output in place, and can open the app under test in a browser to click the thing that makes the bug fire. When a scan finds a parameter but you need a session to reach the sink, Cleus Code is the part that can log in and hold the cookie. It can also edit the source, apply the fix, and re-run the test to prove the finding is closed, in one session, on the repo you already have checked out.

The division that has worked for me: Agent for the first pass and the write-up, Cleus Code for anything that needs a real environment. Agent tells you the login route has a shell in it. Cleus Code is what you open to find out whether that matters.

Why this stopped being a toy

Two years ago an agent finding a real bug was a paper. In 2026 it is a Tuesday.

In November 2024 Google's Big Sleep found a live SQLite stack buffer underflow that both OSS-Fuzz and SQLite's own test suite had missed. By mid-2025 XBOW's autonomous system was at number one on HackerOne's US leaderboard, ahead of thousands of humans. By October 2026 the same team had a Chrome full-chain exploit, three bugs deep, built in six days for about $40,000 of inference, and it paid a $250,000 bounty. An agency veteran told them his team used to budget six months for that class of chain. In early November, an agent found three unauthenticated command injections rated 9.8 in Bing Images and became the first AI on Microsoft's top-ten leaderboard.

That has a consequence people underrate: the baseline assumption for any exposed service is now that somebody, or somebody's agent, has already run the boring checks.

The honest section

An article claiming an agent replaces a pentester is selling something. Here is where the loop stops.

The tools never submit a POST form. No login, no cart, no checkout without run_code. No brute force, no fuzzing, no session, no crawl of ten thousand URLs. No real exploit payload: a marker proves reachability, not the endgame.

The model does not run on a schedule, does not know which of your systems carries money, and can still be wrong. Boolean-based SQLi comes back flagged as a low-confidence lead precisely because it might be a coincidence, and that flag exists so you go and look.

And the frame is not a licence. Authorisation is yours. Scoping, rules of engagement, retest windows and the judgement call about which finding actually matters to the business are all still a person.

The pattern is consistent across every case study above: agents are strongest on the boring 80% humans skip because it is boring, and weakest exactly where judgement lives. Hire them for coverage. Keep a human for the call.

A sane way to start

1. Turn on Hacker Mode, point it at something you own, quick profile. Read the card.
2. Fix the two cheapest things. Re-scan. Watch the grade move.
3. Run recon on your own domain and look at what certificate transparency is publishing about you. You will not like all of it.
4. Use active_scan on a staging search endpoint with a parameter. If it finds something, open Cleus Code and prove it end to end.
5. Put it on a calendar before each deploy, and keep the exported PDFs, because "we scanned in March" is a different sentence from "we scanned at 09:14 on the deploy that broke it".

FAQ

Do I need a paid plan? Hacker Mode is gated behind a subscription and the backend re-checks it per request. Cleus Code is on the same account.

Is this legal to point at anything? For a public read-only scan, mostly yes, but the tool will make requests, so be polite and honour rate limits. For active tests, get permission in writing. Hacker Mode's authorisation prompt is a memory aid, not a contract.

Can it get me a shell? Not by itself. It proves the input reaches the shell or the file system and hands you the parameter and the payload. The shell is run_code or Cleus Code plus your own tooling.

Will it find logic bugs, IDOR or auth flaws? Sometimes, when it can see the flow. Reliably, not yet.

What does it do with the data? Findings render as report cards in the chat, and encrypted chats stay encrypted. Export before you close the tab.

Sources

• Cleus Hacker Mode: scanner behaviour, profiles and authorisation model (HACKER_MODE.md, this repo)
• Cleus tool registry and per-tool scope (functions/src/cleusAgent.ts)
• Live outputs reproduced 2026-11-10 with functions-python/security_scanner.py and active_scanner.py
• Project Zero, "Fuzzers vs. AI", October 2026
• XBOW, "We Ran 1,060 Autonomous Attacks", March 2026
• XBOW, Chrome full-chain writeup, October 2026
• CSA Labs, autonomous red-team findings note, July 2026

Scan the targets yourself. Grades change.