v2.6.1 is out · One proxy mode, mocks you can switch on for a single run, and rules that answer your own probes
VirtuProbe Studio
Get the app

v2.6.1 · macOS · Linux · Windows

Test automation for systems that speak more than HTTP.

A signup goes out over HTTP, the confirmation arrives over IMAP, and the account has to land in MongoDB. You build that as one chain across twelve protocols, group chains into a suite with setup and teardown, and the run comes back as one verdict with a JUnit report and the raw bytes still there to read. An agent can build and run the same things you can, over MCP, without ever being handed a secret.

Download v2.6.1 → Browse the library Read the docs

Started by one engineer (20+ years from core-banking to big data) who kept running out of road with the testing tools on hand and built this one, now built with a small team. The story →

HTTP · SMTP · IMAP · LDAP · DNS · SMB · Kerberos · SpamAssassin · MySQL · MongoDB · PostgreSQL · Freestyle No cloud · runs where your targets are
VirtuProbe Studio v2.6.1 More videos on YouTube
Switching? Bring your whole collection across and carry on where you left off.
import OpenAPI · Postman · Bruno · HAR · .http · Insomnia · cURL

Anatomy of a chain

register → mail → verify → directory, in one file.

Steps pass data to each other through {{variables}}. Iterate over a list, branch on a response, fan steps out in parallel, or call another chain as a sub-routine, mixing protocols as you go. Replay it on your desktop, in CI, or on the execution server inside your network.

HTTP POST /v1/users · register extract $.id → vault.user
→
IMAP INBOX · FROM noreply@ extract token from body
→
HTTP PUT /v1/verify?t={{token}} assert 200 · verified
final step: LDAP bind to dc.target · assert cn=user in OU=Verified · exported as signup-flow.chain.json
VirtuProbe Studio/Chain editor
4 steps · passing
The chain editor: a multi-step HTTP → IMAP → LDAP flow with per-step extractors and assertions in one runnable file
Every step, extractor and assertion in one file you can replay in CI
Browse ready-made chains → How chaining works

Suites and results

A suite runs your chains and comes back with one verdict.

A chain covers one flow. A suite is an ordered set of chains with setup and teardown around them, and the run returns a single pass or fail for the whole set. Runs are kept, so you can open an old one, compare it against the last, and hand the report to whatever already reads JUnit XML.

01 · structure

Setup, the tests, then teardown.

A suite is an ordered set of chains you already have. The chains named as setup run first, and what they produce is handed to every test chain. The test chains are isolated from each other, so each one starts from the same state after setup and a failure in one does not carry into the next.

Teardown runs whether the tests passed or not, and a failing teardown does not turn the suite red, because a cleanup problem is not a test result. By default the whole set runs and the results aggregate. Stopping at the first failure is a switch.

A setup or teardown fixture is an ordinary chain.
02 · evidence

Every run is kept.

A chain run and a suite run are both recorded, with the result of every step, and the last twenty of each are held. You can reopen any of them, or download a whole run as JSON with nothing re-executed to produce it.

The same run exports as JUnit XML, for a chain or for a suite, which is the format most report readers already understand.

The record is written from the run itself, as it happened.
03 · regression

The dashboard answers whether it still works.

Pass rate over a window of runs, what regressed, how many runs in a row it has been failing, and when it last passed. The recent chain and suite runs sit underneath it.

Two runs of the same chain can be compared step by step, matched by step rather than by position, so you see which step changed and what changed inside it.

The dashboard names what regressed and how long it has been failing.

Agents

Agents work in the same workspace you do.

VirtuProbe runs an MCP server, so an agent can build and run tests in your workspace instead of improvising its own. What it makes is an ordinary chain in an ordinary bundle. You can open it, change it, rerun it, and it is still there tomorrow.

01 · connect

An agent connects over MCP.

The MCP server is an endpoint on the API server, not a separate process. An agent connects and gets 26 tools: list and inspect bundles, probes, chains, suites and environments, then create a probe, save a chain, run a chain or a suite, run a fuzz sweep, create an environment, run a script, import a collection.

Those tools call the same services the interface calls, so there is one implementation of each capability and one permission model over it.

An agent works under the licence you already have.
02 · consent

You decide what it may touch.

A new agent can read the workspace, but it cannot change or run anything until you approve it, and approving is a choice of which projects it may reach.

Every write and every run resolves its target back to the projects that own it, and is refused outside the grant. You can revoke an agent while it is working.

An agent reads on connect, and writes or runs only inside the projects you grant it.
03 · watch

Its runs appear while they happen.

Connected agents are listed with the runs they start, step by step as they execute. MCP over HTTP holds no connection open, so connected means an agent sent a request recently rather than that a socket is live.

Attempts that were refused appear too, with the reason they were refused, so a missing grant or an unlicensed protocol is never a silent failure.

An agent's run shows the same detail as one you started yourself.
04 · step in

Open what it is working on.

A failed step is a link. Clicking it opens that chain at that step in the editor, with the same tools you would have if you had written it yourself.

The agent keeps working while you do, because what you opened is the artefact itself rather than a copy of it.

An agent's chain opens in the same editor, with the same tools.
05 · skills

Hand over one capability at a time.

A skill publishes a chain or a script under a fixed contract: typed inputs, declared outputs, one pinned environment. An input marked secret carries the name of a credential binding, never a value.

The environment cannot be passed in, because choosing it is choosing what a stored credential gets pointed at. Point at a chain you already have and the contract is derived for you to review.

A secret input carries the name of a credential binding rather than its value.
06 · events

Every run, on a stream.

Runs are published as Server-Sent Events, whether you started them or an agent did. Filter to agent-driven runs, to a single chain, or to failures only.

The stream is on every tier, because watching your own instance carries nothing the run history does not already hold.

The run stream is Server-Sent Events, readable by whatever you already watch.

Screenshots

A quick tour of the app

HTTP probe editor with body, params, headers, cookies tabs and live response
Probe editor

You can see the method, the URL, the headers, the body and the response at the same time. Variables resolve when you send, so a secret never has to sit in the file, and what comes back is the status, the latency and the raw bytes.

Chain editor showing a multi-step flow passing data between protocols
Chain editor

Drop probes into a sequence and pass data between steps with {{variables}}. Branch on a response, loop over a list, fan out in parallel. HTTP → IMAP → LDAP in a single artefact you can replay in CI.

Credential store dialog with the auth scheme picker open
Credential store

Every scheme sits behind one picker, and the probe stores only which credential to use. The panel shows you which one resolved and where it came from before you send.

HTTP probe Body tab in GraphQL mode with Query and Variables editors
GraphQL

The query and the variables get an editor each, and they serialize into the request body and come back unchanged. After that you can chain it, script it or fuzz it like any other HTTP call.

MITM proxy view showing intercepted requests with raw HTTP request and response
MITM proxy

Drop in the CA cert, point your client at :1080, watch every flow land in the table, filtered by host, status class or method. Promote any line to a saved probe and it's part of your chain.

Proxy interception rules editor with a MOCK rule returning a synthetic response
Service virtualization

Rules are evaluated top to bottom and the first match wins, so the order is the logic. A rule that matches answers from here and the request never leaves your machine.

CodeMirror script editor with JavaScript and Groovy support in the Scripts view
Script editor

A script is JavaScript or Groovy, chosen per script, and a new one starts in JavaScript. The editor highlights, completes and checks as you type, and the script drives probes through vp.send(…), then asserts on what comes back.

Agent Activity beside the terminal the agent is working in: a connected coding agent scoped to one project, the runs and edits it made, and one run failing on a single assertion
Agent Activity

An agent connected over MCP shows up here with the runs it starts, step by step as they happen. You approve which projects it can reach before it can change or run anything, and you can block it while it is working.

Three jobs

Every protocol you test, in one place

Iterate over a list, branch on a JavaScript or Groovy condition, fan out in parallel, or call a sub-chain. Mix protocols freely: fire an HTTP call, read the resulting email over IMAP, look the user up in LDAP, all in one runnable artefact.

Integration testing

End-to-end flows you can run in CI.

A signup flow touches HTTP, SMTP, IMAP and LDAP. You build it once as a chain, and it runs the same way on your machine and in CI.

  • Cross-protocol assertionsAssert that the API call produced a verification email carrying the right token, inside a time limit you set.
  • Iterators & fixturesDrive a chain from a CSV, a vault, or another probe's response.
  • MCP clientThe HTTP probe speaks Model Context Protocol, so it can call an MCP server, thread the session through a chain, and assert on the tools that server exposes.
  • Reproducible artefactsA chain exports as a single file you can commit next to the code it tests.
Mail & identity infra

Mail, directory and identity protocols in one place.

Check a mail server's edge cases without a junk inbox and a pile of command line tools. Scoring, binding, retrieving and resolving are all probes, so they chain with everything else.

  • SMTP & IMAP probesSend a malformed envelope, read what actually arrived, and compare it against what you expected.
  • LDAP queries & bindsQuery a domain controller and assert on directory state part way through a chain.
  • DNS resolutionQuery any resolver for A, AAAA, MX or TXT records, assert on the RCODE, and pass an address to the next step.
  • SpamAssassin scoringScore a message from inside the chain, so a deliverability regression fails the run.
Security research

The requests a spec-abiding client cannot make.

The protocol implementations are written from scratch against the RFCs, so a request that breaks the spec goes out exactly as you wrote it.

  • Hand-rolled stacksHTTP, SMTP, IMAP, LDAP, DNS, SpamAssassin, SMB and Kerberos are ours, so nothing normalises a request before it is sent.
  • Freestyle probesWhen the thing you are testing has no module, you write the exchange yourself: raw bytes over TCP or UDP, as text, hex or base64, with your own rule for where each reply ends.
  • DCSync secret dumpAn SMB probe replicates an account from a domain controller and decrypts its password to the NT hash, as a step you can chain and assert on.
  • Built-in MITMThe proxy captures every protocol it decodes, and turns the traffic into an editable probe you can replay, mutate or fuzz.
  • Chain libraryCurated probe packs for the checks you would otherwise write again on every engagement.

Capabilities

Every feature is built on probes

A probe is a request. A chain is probes in sequence. A script drives probes programmatically. A fuzzer fires a probe in a loop. Intercept captures traffic as probes. The model is the same everywhere, so anything you learn in one place applies everywhere else.

01

Probes

One probe = one request, on one protocol. Twelve of them, and the eight we wrote by hand let you send what the spec forbids. The twelfth is Freestyle, where you write the exchange yourself.

HTTP · SMTP · IMAP · LDAP · DNS · SMB · Kerberos · SpamAssassin · Freestyle
02

Chains

A chain is a flow of probes that pipe data between steps. Branch on a response, run steps in parallel, call sub-chains, loop over a list, and mix protocols inside one flow.

IF {{status}}=='200' → then / else · PARALLEL · CHAIN_REF
03

MITM proxy

Intercept system-wide or scoped to a hostname, across every protocol. The proxy decodes HTTP, email, DNS, the SQL and Mongo wire protocols, SMB and Kerberos, and lands every flow in a table you can filter. Any line promotes to an editable probe, ready to chain, replay or fuzz.

every protocol · filter · capture → probe
04

Service virtualization

Flip the proxy around. Capture a real exchange and turn it into a mock with one click, or write the match yourself, then return a synthetic response so you can stand in for a service that isn't built yet, or force the edge case a real server won't give you.

capture → mock · match rules · stand-in services
05

JavaScript and Groovy scripting

Two engines across pre and post scripts, assertions, mutators and chain logic, with a real code editor: syntax highlighting, autocomplete and linting. JavaScript on GraalJS or Groovy on the JVM, your pick.

vp.send("Login", "SMTP auth", vars) · r.extract("SMTP_SUCCESS")
06

Library

Curated probe packs and reference chains: OAuth flows, SMTP DSN edge cases, LDAP audits, spam-score regressions. Bring your own, and share them with your team.

1,100+ probes & chains · 14 collections · actively maintained
07

Directory-backed workspaces FREE

Point VirtuProbe at a folder and your probes, chains and environments become plain files. Share the workspace through your own git, Dropbox or network share; secrets stay in the local encrypted store. Version-control your tests like code.

folder · GIT-backed · diff & review in your own repo
08

Fuzzing

Mark any probe field with §payload§, drop in a wordlist, and fire. Results land in a table with status, duration and body preview, so anomalies are obvious at a glance.

§payload§ · 200 runs · 3 anomalies
09

AI assistant FREE · BYOK

Bring your own model, any OpenAI-compatible endpoint or a local one. It reads your responses, explains what broke, and builds chains and scripts on request. Suggests the chain; you run it against the real thing and prove it. Every write and run waits for your approval.

BYOK · approve / run · your keys, your infra
10

Unified credential store

Auth is one picker. OAuth2 in every flow, plus Basic, Bearer, API key and Digest, are free. Windows & enterprise schemes (NTLM, Pass-the-Hash, SPNEGO/Kerberos, AWS SigV4, scripted) unlock with a paid tier. Secrets live apart from the probe and never touch history.

OAuth2 · SigV4 · NTLM / SPNEGO · per-project, per-run
11

Import & export anything

Bring existing work in from OpenAPI, Postman, Bruno, HAR, .http or Insomnia, or paste a cURL/wget command onto a probe. Export back out as cURL, wget, Python or PowerShell. Switch tools without leaving your collection behind.

OpenAPI · Postman · Bruno · HAR · Insomnia
12

GraphQL

A first-class Query + Variables editor on the HTTP probe, so your query and variables serialize into the request body and round-trip cleanly. Chain it, script it, fuzz it like any other request.

query · variables · runs as HTTP
13

Action Mode

State the outcome you want and let VirtuProbe drive the protocol. Send an email, find a message, check a login as a plain form, and VirtuProbe drives the whole EHLO / SELECT / BIND conversation for you. Drop to Advanced for exact command control the moment you need it.

send email · find message · check login
14

MCP testing

Point the HTTP probe at a Model Context Protocol server, over Streamable HTTP or legacy SSE. Chain the handshake, stream events live, and read every response for tool-poisoning. Fuzz the JSON-RPC like any other request.

initialize · tools/call · tool-poisoning scan
15

Databases

Run SQL against MySQL / MariaDB and PostgreSQL, and queries against MongoDB, all as probes. Pull out a column or a document field, chain it into the next step, and assert on the result. Fill the form, or paste a full mongo shell query verbatim.

MySQL · MariaDB · PostgreSQL · MongoDB

Free and paid

We charge for the heavy machinery.

Three protocols, request chaining and agent access over MCP are free. The paid tiers add the other nine protocols, the proxy, scripting, test suites and the fuzzer.

Free, forever NO ACCOUNT

  • ✓Protocols: HTTP, DNS & SMTP (send, chain & assert on the response)
  • ✓Agent access over MCP: point your coding agent at the workbench and let it author probes, chains and suites, run them, and read back the evidence
  • ✓AI assistant: bring your own key, we never charge for tokens
  • ✓No cloud, no account, no run limits: runs where your targets are
  • ✓Directory-backed GIT workspaces: version your tests in your own repo
  • ✓Import from everywhere: OpenAPI, Postman, Bruno, HAR, Insomnia, cURL
  • ✓OAuth2, every flow: plus Basic, Bearer, API key & Digest
  • ✓GraphQL requests, first-class
  • ✓Request chaining: the output of one step feeds the next
  • ✓Run history, diff & JSON evidence export

Worth paying for

Two tiers, sold separately. Pick the one that matches the work you do.

Engineering · for shipping integrations

  • →More protocols: IMAP, LDAP, MySQL/MariaDB, MongoDB & PostgreSQL (query & assert on the response)
  • →JavaScript and Groovy scripting: programmatic chains, loops & custom logic
  • →MITM proxy & service-virtualization mocks
  • →Enterprise & Windows auth: NTLM, PtH, SPNEGO/Kerberos, AWS SigV4
  • →Test suites: ordered chains with setup and teardown, one verdict, JUnit output for CI
  • →MCP interception: read the tool definitions and calls going past an agent's MCP server, and alter one on the way through to see whether your agent resists
  • →Skills: publish a chain or script under a fixed contract an agent can call

Security · for breaking them

Everything in Engineering, plus:

  • →Fuzzing & wordlist iterators: malformed packets, byte for byte
  • →Security protocols: SMB & Kerberos, for Active Directory work
  • →Freestyle probes: write the raw TCP or UDP exchange yourself when what you are testing has no module
  • →Out-of-band callback detection: catch the HTTP, DNS or SMTP callback a payload triggers, and assert on who called and when
  • →Pentest libraries: Active Directory, API, per-protocol packs

Students & academics: the full Security tier is free with verification. Academic License →

The library · preview it right now

A thousand ready-made tests to start from

The bundled library ships recon sweeps, fuzzing payloads, kerberoasting, JWT brute-force, AD enumeration and integration smoke tests, plus curated multi-step chains. Find one, import it into a bundle, run it. The whole catalogue is searchable below.

1,000+ ready-made tests 14 collections 130+ multi-step chains recon · fuzzing · AD · API · integrations
Search the library → What unlocks the packs

Testing in the age of AI

Why testing the real thing matters more in the AI era

An AI can ship an integration in an afternoon, which leaves finding out whether it works as the part that still takes time: under load, against malformed input, on the protocol that does not quite follow the spec.

A model writes the happy path well, and sending a CRLF in a header field to see what your reverse proxy does is still something you have to go and do, which is what this is for.

A code review tells you
what the code was meant to do. Running it tells you what it does, which matters more once a model wrote it.
01 · the shift

Writing the code stopped being the slow part.

Generated code ships in minutes and its bugs ship with it, at the same pace, without anybody on the team having read them closely enough to notice.

A test that exercises the running system is what tells you what shipped, and it is the part you still have to write.

Running the system is what tells you what shipped.
02 · the blind spot

A model writes the request the server expects.

Models are trained on code that works, so they generate clients that respect the spec and send the requests a server expects.

Malformed envelopes and undocumented corners of a protocol are not in that training set, and they are where production tends to break.

Adversarial input is still something a person has to think of.
03 · the workbench

We wrote the protocol stacks ourselves.

Our HTTP, SMTP, IMAP, LDAP, DNS, SMB, Kerberos and SpamAssassin are written from scratch against the RFCs, so you can send what the spec forbids, fuzz with §payload§, and see the real traffic.

A model can write the chain that claims your signup flow works, and running it against the real system is how you find out whether it does.

A model can suggest the chain, and the run against the real system settles it.

Three ways to run it

On your laptop, or on a server inside the network you are testing.

VirtuProbe Studio is a desktop application, and by default everything it needs runs on your laptop. When the systems you have to reach sit somewhere your laptop does not, the execution server goes into that network instead and the application connects to it, so probes fire from inside rather than over a VPN.

Standalone

Desktop app

One install with nothing to stand up alongside it, so you open it, probe what you need and close it again.

[ your machine ] VirtuProbe Studio ↓ targets
  • macOS, Linux, Windows
  • Workspaces stored locally on disk
  • Nothing to deploy or maintain
Split execution

Execution server inside the target network

Put the execution server where your targets live. You keep working in the same application, and the probes fire from inside that network.

[ your machine ] [ target network ] VirtuProbe → execution server ↓ targets
  • The execution server ships as a container image
  • Reach internal services with no VPN required
  • Token authentication turns on as soon as it binds beyond loopback
  • One port between the application and execution
Team

One workspace, the whole team

Point the app at a folder instead of its own database. Probes, chains and suites become plain files you can put in git and review like code.

git repository ↓ workspace folder ← everyone's app
  • Branch, diff and review a test like source
  • Pull a teammate's change and the app reloads
  • Environment values encrypt before they are written

Why you can install it

How we handle your credentials and data

VirtuProbe handles your credentials and fires at your infrastructure. That only works on trust, so here is how we treat it.

The makers

A small team, an independent business.

Built by a small team in Prague, an independent product funded by the people who use it. The people who make it answer the mail. Meet the team →

The build

Disciplined, reproducible releases.

Every installer comes out of an automated CI/CD pipeline, with no hand-built binaries. Even the backend it talks to runs as containerized services defined entirely in code (Terraform + Ansible), so nothing is configured by hand. SHA-256 checksums ship with every download, the changelog is public, and macOS builds are signed and notarized (Windows signing is next).

Your data

Nothing leaves your machine.

No cloud, no telemetry, no account. Workspaces live on your disk. Credentials sit in a local encrypted store, apart from your probes and never in run history. The app only phones home to validate a license and check for updates.

Disclosure

If you find something, tell us.

Security reports go straight to a human who wants to hear them, at [email protected]. We'd rather hear it from you than read about it elsewhere.

v2.6.1 · current build

Download VirtuProbe Studio.

You install it once. There is no cloud and no telemetry, a licence turns on the rest of the features, and execution stays on your machine or inside the network where your targets are.

v2.6.1 · macOS builds are signed and notarized; Windows builds are not yet code-signed, so Windows shows a security warning on first launch. How to proceed → · Windows code-signing is next on our roadmap · see what's coming →

SHA256: mac-arm64 · mac-x64 · AppImage · win-x64

The VirtuProbe Bridge extension sends a request captured in Burp Suite into VirtuProbe as a probe. How it works →

Join our Discord