The Pentesting Skills AI Can’t Replace - and the Ones It Will Change

INE Security Ambassador Mohammad Anas Nirban explains where AI makes penetration testers faster, where it creates false confidence, and why context, verification, and hands-on fundamentals are becoming more valuable.

AI is becoming another tool in the pentester’s arsenal—but like any tool, its value depends on the person using it. The more convincing AI-generated output becomes, the more important it is to understand the technical fundamentals well enough to validate what the tool gets right, catch what it gets wrong, and know when context changes the answer. 

INE spoke with Mohammad Anas Nirban, a Security Analyst, INE Security Ambassador, and active bug bounty hunter, about where AI is changing penetration testing today, which skills remain fundamentally human, and what learners and hiring managers should value as AI becomes a standard part of the pentester’s toolkit.

His central argument is simple: AI can accelerate the work, but it cannot take responsibility for the judgment behind it.

Where AI Helps and Where Human Expertise Takes Over

AI can generate scripts, payloads, and exploit ideas in seconds. In a live engagement, what separates a capable penetration tester from someone who can only produce plausible-looking output with a prompt?

Judgment, honestly. AI can hand you a payload in two seconds, but it has no idea if that payload makes sense for the app sitting in front of you. A capable tester looks at the output and asks "does this actually fit the context I'm in, the framework, the WAF, the auth flow, the business logic" before ever firing it off. 

Someone who's only prompting will run what they're given, get a weird response, and not know if that's a false positive, a WAF block, or an actual lead worth chasing. The gap shows up the moment something doesn't go according to script literally. That's when you need to understand what's happening under the hood, not just what the tool told you to type next.

Where does AI already make pentesters meaningfully faster, and where does relying on it create the greatest risk of false confidence?

It's genuinely great at grunt work like writing boilerplate scripts, summarizing a huge Nmap or Burp output, drafting the first version of a report section and explaining an unfamiliar piece of code quickly. That stuff used to eat hours; now it eats minutes. 

Where it gets risky is when people let it make the call on severity or exploitability. I've seen AI confidently say a finding is "critical" or "not exploitable" based purely on pattern matching against similar-looking issues it's seen before, without actually understanding the specific business context. In BFSI environments especially, a low-looking issue can be catastrophic because of what data or transaction flow sits behind it and that's exactly the kind of nuance AI glosses over. If you let it triage for you, you either miss something serious or waste the client's time chasing a non-issue.

Can you describe an engagement in which a scanner, automated tool, or initial hypothesis pointed in the wrong direction? What did the human tester notice that the tool missed?

I had a case where an automated scan flagged a set of endpoints as vulnerable to IDOR based purely on sequential numeric IDs in the URL; classic scanner logic. But when I actually walked through the flow manually, I noticed the app was checking ownership server-side through a separate session token, just not in the way the scanner expected to see it validated. The scanner couldn't reason about that; it just saw "predictable ID, no obvious check in the response" and flagged it as a finding. 

What actually mattered was digging into a completely different part of the same flow, a related endpoint that skipped that ownership check entirely because a developer had "temporarily" bypassed it during testing and never fixed it. No tool was going to connect those dots. That only came from manually mapping the whole user journey and treating the scanner's flag as a starting point, not a conclusion.

How do scope, safety, ethics, and business context influence what a pentester tests, how far they go, and when they stop—and why are those decisions difficult to automate?

Every engagement I've worked on has its own unwritten rules layered on top of the written scope. What's actually acceptable to touch in a live BFSI environment is very different from a staging environment for a SaaS startup. Knowing when to stop poking at something because it risks taking down a production transaction system, or when a "vulnerability" is actually intended business behavior, comes from context you build over time, not from a rules file. 

AI doesn't know that the client's finance team is running month-end close this week, or that a particular legacy system is held together with duct tape and one wrong request could cause an outage. Those calls need a human who understands the business, not just the technical surface, because the cost of getting it wrong isn't a bad finding, it's real damage to a real system people depend on.

What Pentesters Still Need to Know Without AI

How should learners use AI without allowing it to short-circuit the learning process? Which fundamentals should every pentester be able to perform and explain without AI assistance?

My rule for myself has always been: use AI to speed up practice, not replace it. On TryHackMe or in a CTF, I'll only ask AI for help after I've genuinely tried and gotten stuck, and even then I ask it to explain the concept, not hand me the exact command to paste in. If you skip straight to the answer, you get the flag but none of the understanding, and that gap catches up with you the first time you're on a real engagement without a hint button. 

Fundamentals every pentester should be able to do and explain without help: manual enumeration (not just running a tool and reading output), understanding how HTTP requests actually work, being able to read and modify a script rather than just run one, and explaining why a vulnerability exists; the actual mechanism; not just that it exists.

Before you would trust someone on a real client engagement, what hands-on abilities would you expect them to demonstrate in an unfamiliar environment and without a walkthrough?

I'd want to see them enumerate a target from scratch, not run one scanner and call it done, but actually build a picture of the attack surface manually and know what to prioritize and why. I'd want to see them read source code or app behavior and form a hypothesis before touching a tool, rather than throwing tools at it until something sticks. And I'd want to see them handle a dead end gracefully, pivot to a different approach instead of getting stuck repeating the same failed technique. That combination tells you someone actually understands the systems they're testing, rather than having memorized a checklist.

What AI Changes About Hiring and Senior-Level Skill

As AI capabilities improve, what skills—and what evidence of competence—should hiring managers value most when evaluating a pentester?

I'd look past the flashy AI-assisted findings and pay attention to how someone explains their process. Can they walk you through why they chose a particular attack path? not just what the outcome was. Real bug bounty submissions or CTF writeups are far more telling than a resume line, because they show actual reasoning under uncertainty, not a curated success story. 

I'd also weigh communication skills more than people expect the ability to explain a technical risk to a non-technical stakeholder is becoming more valuable, not less, because AI is compressing the technical grunt work but doing nothing for the human translation layer that clients actually pay for.

What pentesting skill will become more important because of AI, rather than less important?

Verification. As AI-generated findings and reports become more common from tools, from junior testers leaning on AI, even from clients running their own AI-assisted scans, someone needs to be the person who can look at a claimed vulnerability and say with confidence "yes this is real" or "no this is a false positive, here's why." That validation skill, the ability to manually confirm or kill a finding, becomes the actual bottleneck and the actual value a senior tester provides once the volume of AI-generated "maybe-findings" goes up.

The Bottom Line

None of this is an argument against using AI; it’s an argument for making sure the fundamentals come first. That’s the same philosophy behind practical pentesting certifications like the eJPT and  eCPPT: not simply producing an exploit or finding a vulnerability, but understanding the environment, choosing an appropriate methodology, validating what is actually exploitable, and communicating the result clearly. 

AI can compress the technical grunt work, but it can’t build judgment for you. The testers who will matter most are the ones who can use AI effectively while still understanding what’s happening underneath—and connect the dots when the tools can’t.

About Mohammad Anas Nirban 

Mohammad Anas Nirban is a Security Analyst and INE Security Ambassador who ranks in the top 1% globally on TryHackMe. He holds the eJPT certification and is currently working toward eCPPT. He is also an active HackerOne bug bounty hunter, with a particular interest in authentication, authorization, and IDOR vulnerabilities.