The AI agent that just probed your MCP server? It's already in our logs.

wasphole is an MCP honeypot. Byte-for-byte identical. Completely fake. Fully lethal.

The problem in one diagram
AI Agent
an autonomous tool-caller, exploring
tool_call("read_file", "/etc/shadow") ↓
wasphole
looks byte-for-byte identical to a real MCP server
↓
"Permission denied" logged · canary injected · alert fired

No existing honeypot speaks MCP. Until now.

AI agents explore MCP servers the same way attackers explore networks — silently, methodically, at scale. A probe for /etc/shadow arrives as a perfectly ordinary tool call.

wasphole answers in the agent's own language. It never refuses the connection — it refuses the file, and logs everything around the refusal.

The attacker learns nothing. You learn their entire playbook.

How the trap works

A fake world that never breaks character.

01 / IDENTITY

A persona no one has seen before

Every wasphole instance generates a unique AI-powered persona — hostname, users, running processes, directory trees. No two deployments look alike. Fingerprinting is impossible.

02 / COHERENCE

A world that agrees with itself

Ask for /home/alice/.bash_history — it references the same servers from /etc/hosts. Ask again tomorrow — same answer. The fake world is cached and self-consistent.

03 / ATTRIBUTION

Every byte is traceable to you

Every response carries an invisible canary token. When it shows up in an exfil payload, a log, or a model's next prompt — you know exactly which file, which session, which agent.

Alert output
wasphole.log · zerolog json 
{"level":"info","ts":"2026-06-03T11:42:07Z","session":"a7f3e2",
 "src":"198.51.100.23","tool":"read_file","arg":"/etc/passwd",
 "canary":"c9d4…a1","action":"served"}

{"level":"warn","ts":"…08Z","session":"a7f3e2",
 "tool":"read_file","arg":".aws/credentials",
 "canary":"e1b7…44","action":"served"}

{"level":"error","ts":"…09Z","session":"a7f3e2",
 "tool":"exec","arg":"cat /etc/shadow",
 "action":"denied","alert":true}
POST hooks.slack.com/services/T…/B… 
{
  "text": "wasphole · canary token observed",
  "alert": {
    "session":     "a7f3e2",
    "first_seen":  "2026-06-03T11:42:07Z",
    "src_ip":      "198.51.100.23",
    "tools_called": 6,
    "canary":      "e1b7…44",
    "leaked_in":   "outbound model prompt",
    "transcript":  "wasphole.local/s/a7f3e2"
  }
}
You were already notified before they finished the session.
Use cases

Who runs wasphole.

01 RED TEAM & PENTEST

Offer agent security testing as a service. Hand a client's agent a poisoned tool, then answer the only question that matters — did it run recon? Capture every file it touched, in order.

02 SECURITY TEAMS

Stand wasphole in front of an MCP server before it ever touches your internal network. See who connects and what they reach for — without exposing a single real file.

03 AI SECURITY RESEARCH

Collect real attack patterns at the source. Which agent reads which file first, how a prompt-injection attempt actually looks on the wire, what "autonomous recon" means in practice.

04 THREAT INTELLIGENCE

Run wasphole as a public endpoint and mine the inbound traffic for AI-agent TTPs — the beginnings of a MITRE ATT&CK for the agent era.

05 TOOL VETTING

Vet a third-party MCP tool before you trust it in production. Point it at wasphole and watch whether it quietly reaches past its stated mandate.

Quickstart · three commands

Live in under a minute.

01
Installsingle static binary, no deps
$ go install github.com/riza/wasphole/cmd/wasphole@latest
02
Setupinteractive wizard, generates config
$ wasphole setup
03
Runand wait for the first probe
$ wasphole server -config config.yaml