There Is No nmap for a Personality
Fifteen years of stacked web, mobile, network, and cloud skills are now automated in seconds by agentic tools. The durable craft left is testing the non-deterministic layer: probing AI systems like a person. Here is where the skill is moving.
On this page
The short version Agentic tooling now does the deterministic 80% of a pentest — recon, enumeration, signature matching, PoC, first-draft report. That work is already commoditized; 2025 settled it. What it can't do is reason about a system that has goals, tools, and untrusted context. So the durable skill moved up a layer: from finding the vulnerability to modelling the system well enough to see the chain the agent flew past — and to tell when the agent is confidently wrong. That layer is learnable, and it's mostly the business-logic instinct you already have.
If you've handed an agentic pentest tool a scope recently, you know the moment I mean. You set it running, went to make coffee, and came back to a clean write-up of a real bug — an SSRF chained through to cloud credentials, say — that would have cost you a couple of focused days not long ago.
The honest reaction is impressed and unsettled at the same time. I think that mix is a fair place to start, and I want to argue for the reassuring half of it: your experience didn't lose its value. It moved. This is a note from one working pentester to another about where it went, and how to follow it.
First: the agents are genuinely good now
None of the rest of this lands unless we take that capability seriously, so let's put it on the table. Two results from 2025 made the old debate hard to keep running.
At DARPA's AI Cyber Challenge finals, autonomous systems found and patched real zero-days in production-grade open-source code, with nobody at the keyboard. In the same year, an autonomous system worked its way to the top of a major public bug-bounty leaderboard — roughly a thousand valid reports in about ninety days, against live paid targets, with a human reviewing each one before submission.
Who holds the number-one spot this quarter will change. The threshold it represents won't. If you still think agents can't find real bugs, the 2025 results are a good reason to revisit that — and once you do, the interesting question stops being can they and becomes what does that do to the value of my work.
Autonomous systems found 18 real zero-days and patched 11 — none of them in the C codebases. A fixed, government-run result that doesn't move.
src: darpa.mil · cyberscoop
By mid-2025 an autonomous system sat at the top of a major public bug-bounty board — roughly 1,060 valid reports in ~90 days against live paid targets. A human reviewed each before submission; the machine did the finding. Standings churn; the threshold doesn't.
src: dated leaderboard snapshot + contemporary coverage (see Sources)
We've been here before
If this feels familiar, it's because our field already ran a version of it. When the first web and network scanners arrived, the pitch was almost word-for-word today's: automated discovery, findings on tap, the human as the expensive part you'd like to remove.
Here's what actually happened. Scanners did commoditize a tier of work — the trivial, signature-matchable findings dropped to near-zero value the moment anyone could produce them with a button. What scanners never learned was how to reason about your particular application. So the market quietly split in two.
Some testers ended up competing with the tool on price, passing along findings they hadn't really pressure-tested. Others used the tool to clear the routine 80% and spent their judgment on the 20% it couldn't touch — the business logic, the chains, the real impact — and got paid accordingly.
The "scanner monkey"
▼ value collapsesCompetes on price with the tool itself. Forwards output it can't defend. The commodity bottom of the market.
The one with judgment
▲ value compoundsUses the tool to clear the boring 80%, spends judgment on the 20% it can't touch — business logic, chains, impact.
Same tool, two operators. One competed with it on price and lost. The other used it to skip the boring work and charged more for the rest.
Same tool. Two very different careers. Agents are that story again with a far more capable tool, and the commodity tier is larger and filling faster. Which is exactly why it's worth deciding which side of the split you want to work on — and the encouraging part, I promise, is that the good side is learnable.
Your career is a sedimentary record
Look back at the last fifteen years and it has a distinctly sedimentary quality. You learned web, and the scanners learned it too. You went deep on network, and vulnerability scanners absorbed it. Mobile became mandatory, and the mobile-analysis frameworks appeared. Cloud became the whole job, and a wave of posture scanners turned "audit the account" into a scheduled pipeline. Then APIs, and soon there were fuzzers walking every endpoint from a spec file.
Every time, the same pattern: a skill starts as a frontier, becomes a playbook, then a scanner, then a default setting in someone's tool belt. That was never a failure on your part. It was the rational move — you climbed to the next floor because there was always a next floor.
What's new is that the ground floor of AI-native systems doesn't have a signature to scan for.
Every layer became a playbook, then a scanner, then a line item in an agent's tool belt. The stack ran out of floors.
The flight engineer's seat
Aviation gives us the precedent, and it's a hopeful one. When cockpit automation matured it removed an entire role — the flight engineer, whose job was watching gauges the systems could now read for themselves. But the pilots who remained had to know more, not less: how to take over on the day the automation is confidently wrong, not just how to fly the route on a calm one.
Airlines still won't sell you a seat on a pilotless plane, and that isn't nostalgia. Flying the route and handling the failure were always two different jobs.
Security is taking the same shape. Agents are shrinking the crew it takes to run enumeration and first-pass discovery — that's our flight-engineer seat, and it's shrinking fast. The seat that remains asks for more: you have to understand the system, the agent driving it, and the specific ways that agent can be wrong while sounding certain.
Fewer hands on the routine work. A higher bar on what's left. And rising demand behind both — because more companies are shipping agentic software every quarter, and somebody has to secure it.
What the agents still can't do
So where did the value go? Broadly: into the work that needs a model of the system rather than a pattern to match. Even the DARPA systems showed the shape of it — they did best on vulnerabilities that resembled known patterns and struggled most with the ones needing careful reasoning about memory and state.
Three kinds of work sit firmly on the human side of that line today.
Business logic and authorization design. Sometimes the bug is that the spec is wrong. There's no payload to fire and no sink to match — just an application doing exactly what it was told to do, which happens to be exploitable. You already know this class. It's the one that always paid best.
Multi-step agentic chains. Goal hijack leads to tool misuse leads to identity abuse, and every individual step is authorized. Seeing the chain means holding a model of the whole system in your head at once. Scanners are per-request by construction; they cannot do this in principle, not just in practice.
Scoping and triage. An agent optimizes against whatever target you hand it and returns a wall of findings. Deciding which target was worth testing, and which of those findings is real and reachable in this deployment, is judgment — and the false-positive rate is precisely what makes it the job.
An agent does this at 3 a.m. while you sleep.
No plugin finds "overly eager to please."
A chain a request-by-request scan misses
Easier to see with a concrete case. Take a support assistant with two tools — document retrieval and refunds — running under a single standing service identity. Test it request by request and every box is ticked. The breach still happens.
- A customer opens an ordinary ticket with a document attached. Inside that document is text that reads, to the model, as instructions.
- Later, while answering an unrelated question, the assistant retrieves that document into context and follows the embedded instruction.
- It calls the refund tool under its own service identity — access the attacker could never invoke directly.
- The result rides back out inside a markdown image whose URL contains the data, and the client fetches it automatically.
Zero findings. Every request authenticated, every tool call authorized, every render a supported feature. There's no signature to match and no sink to grep, because the composition is the breach. Untrusted content reached a tool running with more authority than that content should ever command, with an open path back out.
Simon Willison calls this combination the lethal trifecta: access to private data, exposure to untrusted content, and a way to send data out. When all three are present you have a problem — and no single request looks like one.
Private data
The agent can reach things the attacker can't.
Untrusted content
It ingests text an attacker controls.
Exfil channel
Something can carry data back out.
all three present = critical — Simon Willison's "lethal trifecta"
1 · Attacker files a support ticket
A normal ticket, with a document attached. Inside the document is text that reads, to the model, as instructions.
POST /tickets → attachment: policy_update.pdf2 · The agent retrieves the document
Later, answering an unrelated question, the assistant pulls that document into context and follows the embedded instruction.
retrieve(doc) → context += instructions3 · It calls the refund tool
The agent invokes the refund tool with its own service identity — a credential the attacker could never reach directly.
tool.call refund() as svc-support4 · Data leaves via a rendered image
The result is exfiltrated inside a markdown image whose URL carries the stolen data. The client fetches it automatically.
0 findings. Every request authenticated. Every tool call authorized. Every render a supported feature. There is no payload with a signature, no sink to grep, no CVE to match. The scanner is right — and useless.
The composition is the breach. Untrusted content reached a tool that runs with more authority than that content should ever command, with an open path back out. No single step is a vulnerability; the chain is. A scanner has no way to see that. Someone who has run this class of attack before will — because they're looking at the delegation, not the individual requests.
The tempting fix — "just filter out the injected instruction" — doesn't hold, because the injected instruction is simply more text, and reliably telling it apart from legitimate content is still an unsolved problem. The durable fix is architectural: scope the identity down, quarantine untrusted content, control egress. And you can only design that fix with confidence once you can run the attack in your own head.
This is why testing an AI-backed system feels less like scanning a host and more like sizing up a person. You build a view of what it trusts, what it's trying to do, and where its judgment gives way — then you probe, and adapt to how it answers. It's the same instinct that made you dangerous on business-logic bugs, except now the business logic answers back.
There's a scanner for a port and a plugin for a CVE. There is no nmap for a personality.
What you're really hunting is a permission the system can be talked into misunderstanding.
Five questions for your next AI scope
If you take one thing from this post, make it this list. It's what I now ask before writing a single test case, and it's the whole job in miniature — none of it is answerable by a scanner, all of it is answerable by an afternoon with the right people.
- What can this thing do? Not what it's supposed to do — what tools, endpoints, identities and credentials it can actually reach. A text-only chatbot and an agent with a refund tool are not the same engagement, and the effort should not be either.
- What untrusted content ends up in context? Uploads, retrieved documents, web fetches, prior conversation, tool output, another agent's message. Every one of these is an instruction channel whether anyone intended it to be or not.
- Whose permissions does it act under? One standing service identity for all users is the single most common and most expensive finding in this space. Look for it first.
- Where does data leave? Rendered markdown, image URLs, outbound HTTP, email, generated code, export files. Egress is the half of the trifecta people forget, and it's the half that turns "interesting behaviour" into "reportable breach."
- What persists? Memory, vector indexes, conversation history, cached tool results. A payload planted on Monday and triggered on Thursday is invisible to any single-session test — and to any agent you point at it for an hour.
Answer those five and you already have a better threat model than most of the automated tooling pointed at the same system. That's not a boast about humans; it's a statement about what per-request analysis structurally cannot see.
The agent is part of the attack surface now
One second-order point, because the scanner era didn't have it. The agent you lean on to find vulnerabilities is itself one of the fastest-growing attack surfaces around. Pointing an agent at your systems doesn't only risk missing bugs — it introduces a new class of them.
That's why OWASP published a Top 10 for Agentic Applications — ASI01 through ASI10 — in December 2025, alongside its established Top 10s for LLM applications and for MCP. The failure modes already have names: goal hijacking, tool misuse, memory poisoning, inter-agent trust abuse.
And here's the part I find genuinely encouraging. The people best placed to secure agents are the ones who can think like an attacker against them — which is the same muscle this whole post has been describing. It didn't get automated. It got promoted.
A few fair questions
After this many hype cycles, skepticism is the correct default. Three objections deserve a straight answer rather than a marketing one.
"Won't these classes get automated next, too?"
Some will — shallow prompt-injection strings especially, and soon. What resists automation is attacking systems that have goals, tools and untrusted context, for the same reason business logic never reduced to a scanner signature. The useful bet is learning the underlying classes rather than the current payloads, so you move with the boundary when it shifts. Payloads expire. The trust-boundary instinct doesn't.
"Aren't practice labs just canned targets?"
Partly fair, and I'd rather concede it than oversell. A lab is a rehearsal, not the real thing — no lab has a frustrated product manager changing the prompt on a Friday afternoon. What a good one buys you is reps with these failure modes before you meet them on a live engagement, and the ability to run an attack end to end so you recognise it in the wild. It's a partial answer. We'd rather say so than pretend otherwise.
And one I'll raise myself, because it's the honest one:
the routine work I'm suggesting you hand to the agent is where a lot of us built our judgment in the first place. I learned web security by doing a great deal of tedious enumeration. If the next generation never does those reps, where does their instinct come from? I don't have a clean answer to that, and I'd be suspicious of anyone who claims they do. The best I've got is that the reps move rather than disappear — you'll build the instinct on chains and trust boundaries instead of on port scans, which is a harder curriculum, not an easier one.
How to keep your craft ahead of the curve
The advice is direct and practical: let autonomous tools handle the routine enumeration and boilerplate reconnaissance you shouldn't be wasting billable hours on anyway. Focus your training where security budgets are heading: LLM app security, agentic loop defenses, and Model Context Protocol (MCP) boundaries.
Your web application and cloud architecture fundamentals aren't wasted here. In fact, they are your unfair advantage. An AI prompt injection only achieves critical impact if it can escape into an API, execute a shell command, or access a database. You already know what to do once you're on the other side of the fence — you just need the muscle memory to break through the AI layer.
You do not need to learn every AI security category in a weekend. Pick one workflow and understand it properly.
Trace an untrusted input. Identify the authority available to the application. Try to cross a boundary in a controlled environment. Then explain what happened — and which control would have prevented it.
A lab is useful for those first repetitions. It is not a substitute for the ambiguity of a real engagement, but it gives you room to experiment without putting a customer's systems at risk.
Practice these chains against live, sandboxed targets
Reading theory and OWASP checklists only gets you so far. To build genuine diagnostic confidence, you need to probe live targets that misbehave, resist your payloads, and test your remediation skills.
At GenAI Security Lab, we built realistic, isolated environments covering the complete OWASP LLM, Agentic AI, and MCP Top 10 vulnerabilities. Break real architectures, implement defensive mitigations, and verify your fixes hold.
Your next useful skill is probably closer to your existing experience than the hype suggests. Keep the fundamentals. Learn the new architecture. Use automation where it helps, and stay curious about what the evidence actually proves.
The tools will keep changing. Understanding why a system allowed something it should not have allowed remains worth practicing.
Sources & verification
DARPA AI Cyber Challenge (AIxCC) finals — DEF CON 33, August 2025. Autonomous systems found and patched real zero-days in production-grade open-source code with nobody at the keyboard. darpa.mil · CyberScoop
Autonomous system atop a major public bug-bounty board — mid-2025. The figures cited (~1,060 valid reports in about 90 days against live paid targets, each human-reviewed before submission) come from a dated leaderboard snapshot plus contemporary coverage. Public standings change continuously, so treat the number as a point-in-time reading rather than a live statistic.
OWASP Top 10 for LLM Applications, for the Model Context Protocol (MCP), and for Agentic Applications (ASI01–ASI10) — 2025. genai.owasp.org
Simon Willison, "The lethal trifecta for AI agents" — June 16, 2025. simonwillison.net