Introducing the Fimil AI Pentest Agent: no finding without a working exploit

Every dynamic security tool I have ever run has the same failure mode: it hands me a list of things that might be wrong. A scanner sends a probe, sees a response it does not like, and writes a finding. Whether that finding is actually exploitable is left as an exercise for me. So I spend my afternoon re-sending requests by hand, trying to turn “the parameter reflected a quote character” into a sentence I can defend in a Jira ticket. Half the time I can’t, and the finding gets closed as “informational.”

That is the problem I built the Fimil AI pentest agent to kill. It is now in early access, and the design rule behind it is short: no finding without a working exploit. If the agent cannot reproduce the vulnerability on demand, you never see it.

The credibility problem with “maybe”

A dashboard full of maybes is worse than no dashboard at all. It trains your engineers to ignore it.

Walk through what a single unconfirmed DAST finding actually costs. A security engineer reads it. They try to reproduce it. They can’t, because the tool fired on a heuristic — a status code, a timing delta, a reflected string — that does not hold up when you actually drive the request. Now there is an argument: the engineer says “false positive,” the tool says “potential SQL injection,” and nobody can settle it without doing the work the tool was supposed to do. Multiply that by a few hundred findings and you have a triage backlog that exists purely to disprove a machine.

The fix is not a better heuristic. The fix is to make the tool do the reproduction itself, before it opens its mouth. Detection is cheap. Confirmation is the entire job.

What the agent does

The agent runs in three phases against a target you have explicitly authorized.

Discovery. It maps the application’s real attack surface three ways at once. A breadth-first crawl walks the rendered link graph. If you hand it an OpenAPI or GraphQL schema, it ingests the operations directly instead of guessing at routes. And for anything JavaScript-rendered, it drives a real headless browser — Chromium under Playwright — so single-page apps, XHR-loaded endpoints, and client-side routes show up as testable surface instead of an empty HTML shell. A static crawler simply cannot see those; a browser can.

Attack. Against the surface it found, the agent works through 15 vulnerability classes:

• SQL injection
• Cross-site scripting (XSS)
• Server-side request forgery (SSRF)
• Insecure direct object references (IDOR)
• Broken authorization
• Mass assignment
• Prompt injection
• Server-side template injection (SSTI)
• LDAP injection
• XPath injection
• XML external entities (XXE)
• Command injection
• Path traversal
• JWT attacks
• Insecure deserialization

Each class is driven by an LLM that decides what to try next based on what the application actually returned, not a fixed payload list fired blindly at every parameter. The agent forms a hypothesis, sends a candidate request, reads the real response, and adjusts.

Authenticated testing. Most of the interesting bugs live behind a login, so the agent logs in. It handles standard credential flows and TOTP-based MFA — it will complete the multi-factor step with a seed you provision, capture the authenticated session, and carry it into every subsequent request. That means IDOR and broken-authorization testing runs the way a real attacker would run it: as a logged-in user poking at another user’s data.

Validation: the replay step

Here is the part that makes the rest of it trustworthy.

When the attack phase produces a candidate — “this looks like an IDOR” — that candidate is not a finding. It is a hypothesis with a request attached. Before anything reaches your dashboard, a separate validator replays the exact request that triggered it and checks that the exploit condition holds again, deterministically. For something like IDOR, that means re-running the cross-account access with a fresh session pair and confirming user A really did read user B’s data, not once but reproducibly.

If the replay does not confirm, the candidate is discarded. It is not downgraded to “low confidence.” It is not shown as “maybe.” It is dropped, and you never know it existed. The only things that survive to your dashboard are the ones the validator could reproduce on demand.

Every confirmed finding then exports two things you can act on immediately:

• A proof-of-concept that documents the exploit
• A copy-paste curl reproduction so anyone on your team can re-run it in their own terminal in five seconds

No screenshots of a tool’s UI. No “trust me.” A command you run yourself.

What a run actually looks like

Here is a representative run against a test target — fictional details, real shape of the pipeline:

[discover]  crawl + openapi ingest complete
            surface: 84 endpoints, 12 authenticated
[attack ]   GET /api/v1/invoices/{id}  -> candidate: IDOR
            sequential ids, no ownership check on response
[attack ]   building cross-account session pair
            session A: alice@example  (org 1004)
            session B: bob@example    (org 2210)
[replay ]   A reads /api/v1/invoices/8831 (owned by B) ... 200, body matches B
[replay ]   B reads /api/v1/invoices/8830 (owned by A) ... 200, body matches A
[replay ]   2/2 confirmed  -> CONFIRMED  cwe-639
[report ]   poc + curl repro exported
[remediate] advisory fix PR opened: fimil-bot/pentest-idor-8831
            docs/security/pentest-findings/idor-8831.md
            + curl repro, affected ids, ownership-check guidance

The two [replay] lines are the whole point. The candidate was found once during the attack phase; it was confirmed twice, independently, before it earned the CONFIRMED label. Only then does the report get written and the advisory pull request get opened against your repository with the reproduction and remediation guidance attached. A candidate that replayed 0/2 would have stopped at the [attack] line and never been mentioned.

Why we bill per confirmed finding

The pricing follows directly from the design rule. You pay per confirmed finding — not per scan, not per endpoint, not per seat.

I did this on purpose, because it puts my incentives where they belong. If Fimil got paid for raw findings, I would be rewarded for noise: every “maybe” would be revenue, and the validator would be a cost center working against my own P&L. Billing on confirmation inverts that. A false positive is worthless to me, exactly as it is worthless to you. The replay step is not an expense I tolerate — it is the thing I am selling.

Two consequences fall out of that:

• Automatic credit on reversal. If a finding is ever marked a false positive after the fact, the charge for it is reversed automatically. You do not file a ticket. You do not argue. The meter runs backward.
• The kill switch is always free. Aborting a run, at any time, for any reason, costs nothing. Stopping testing is never something you have to pay to do.

Honest limits

This is an autonomous exploit-confirmation engine, and I want to be precise about what that is and is not.

It is not a replacement for a human red team on novel business logic. The agent is excellent at the well-defined classes above — the kinds of bugs that have a crisp, replayable exploit condition. It will not reason its way through a five-step abuse of your refund workflow that only makes sense if you understand how your finance team reconciles credits. That is human work, and it stays human work. Think of the agent as the thing that clears the table of confirmable vulnerabilities so your people spend their time on the creative attacks a machine cannot invent.

On containment: every request the agent sends is fenced by a scope guard. It enforces a hostname allowlist so testing stays on the targets you authorized, gates destructive HTTP verbs, applies rate limits so you do not get a self-inflicted outage, pins DNS to defeat rebinding tricks, and honors the kill switch immediately. Off-allowlist subresources — a stray CSS or XHR fetch from a page the browser rendered — are aborted with the same audit trail as a blocked top-level request. Containment is the part I lose sleep over, so it gets its own deep-dive post; this paragraph is the summary, not the spec.

Getting access

The agent is in early access now. It joins the same platform that already orchestrates 15 open-source scanners across eight categories — SAST, SCA, secrets, IaC, containers, SBOM, DAST, and CSPM — so confirmed pentest findings land in the same prioritized queue, behind the same platform, as everything else Fimil finds.

If you want to point it at something you own, read the pentest page for the current scope and authorization model, browse the feature list to see how it fits the rest of the stack, or check pricing for how per-confirmed-finding billing works in practice. Then sign up and tell me what you want to test.

No finding without a working exploit. That is the whole promise, and the entire product is built to keep it.