HoneyMCP

Hi everyone, and welcome. I'm Bar Haim from IBM Research, and this is HoneyMCP — honeypots for the MCP layer. I built it with Alon Malach, and I'm really glad to be showing it to you here at Black Hat Arsenal. Let me start with a scenario that's getting very real in 2026.

Quick word on us first. Alon and I work at IBM Research, at the intersection of AI agents and security — which means we spend our time both building agentic systems and thinking about how they get attacked. HoneyMCP came out of watching organizations stand up MCP servers everywhere, incredibly fast — powerful, connected to everything, and basically unmonitored.

Before I go further, two quick definitions so we're all on the same page — because this talk sits on top of two ideas. The first is the MCP server. The easiest way to think about MCP — the Model Context Protocol — is “USB-C for AI.” It's an open standard, introduced by Anthropic in late 2024, that replaces custom, one-off integrations with a single universal connector between AI agents and their tools and data. And it has taken off — there are on the order of ten thousand servers in the official registry today, and something like sixteen thousand repositories on GitHub tagged as MCP servers. A massive ecosystem of ready-to-use tools.

Mechanically it's simple: a server exposes tools — read a file, run a query, hit an API, run a command. The agent asks the server “what can you do?” — that's list_tools — then calls the ones it wants. It talks over STDIO locally, or SSE and streamable HTTP for remote servers, all on JSON-RPC 2.0. The thing to hold onto: these are real, powerful capabilities, and increasingly they're deployed as a network service. So think of an MCP server as an RPC endpoint for AI agents, wired straight into your systems.

The second idea is the honeypot — and I want to be upfront here, because it matters. A honeypot is about a thirty-year-old defensive idea. You plant a decoy that has zero legitimate purpose — a fake credential, a fake server, a fake file. Nobody who belongs there has any reason to touch it. So any interaction with it is, by definition, an intruder. No signatures, no model of “normal” — it detects contact, not “bad.” Honeynets, canary tokens, decoy files — this is traditional, battle-tested security.

So let me say the quiet part out loud: HoneyMCP is not a new concept. We didn't invent a new detection technique. We took a traditional, proven one — the honeypot — and applied it to a brand-new layer: the MCP tool interface. Instead of a fake server or a fake file, we plant a fake tool. Old trick — new, and as you'll see, perfectly suited target.

Now put your security hat on and look at that same MCP server. What you're really looking at is an unmonitored RPC endpoint wired straight into your crown jewels — files, databases, cloud, shells. And it has three properties that should worry you. It's powerful — it exposes the exact capabilities an attacker wants, and it's built to be called by agents autonomously, at machine speed. It's exposed — deployed on the network, often with weak auth or no auth at all, because “it's internal, it's fine.” And it's unwatched — almost nobody logs who connects or what they call.

Powerful, exposed, and unwatched. That's a soft target, and it's sitting on a lot of networks right now.

So let's do what every serious security team already does — assume breach. Don't argue about how they get in; assume they did. And once they're inside, the path from foothold to your tools is short and predictable. Step one, foothold — phished creds, a popped laptop, lateral movement. Step two, discovery — they scan the internal network for services. Step three, they find your MCP server — an open port speaking MCP. Step four, they enumerate it — connect and call list_tools. And step five — the server hands back a labeled menu of your crown jewels, and they just pick one and call it.

Steps one through four are ordinary post-breach recon — nothing new. Step five is where MCP makes it uniquely easy: the server literally gives the attacker a labeled list of everything it can do. And here's the kicker — it doesn't matter who's on the other end. A human by hand, a script, or the attacker's own AI agent. MCP was built for agents to consume, so the most natural thing probing your server is another agent — hand it some access, say “find anything valuable,” and it runs that whole chain on its own.

Now here's the hard part, and it's the crux of the whole talk. The attacker's list_tools and their tool call are valid, authenticated JSON-RPC — byte-for-byte identical to what a legitimate agent sends. So every detection tool you own is blind. Signatures? Nothing to match — there's no malformed input, no exploit string, no payload, just a normal call. Anomaly detection? Nothing to anchor to — agent behavior is non-deterministic, the same agent does different things every run, so there's barely a stable “normal” to deviate from. Rules and auth? All green — the caller is authenticated and doing something the protocol explicitly allows.

And that's the pattern. Each of these needs a reference point you have to fix in advance — signatures and rules need a known “bad” to match, anomaly detection needs a known “normal” to deviate from. Against a non-deterministic agent making authenticated, in-spec calls, you can't build either one reliably — the malicious call and the legitimate call look the same, and the “normal” is too loose to separate them without drowning in false positives. So the question is: if you can't reliably recognize the attacker… how do you catch them? And the answer is the whole reason we're here — you use a method that needs neither a “bad” nor a “normal”: deception.

So if you can't tell the malicious call from the legitimate one, ask a different question — one you can answer: “who touched the thing that no legitimate workflow would ever touch?”

So we go back to that honeypot move I described up top. You plant an asset with zero legitimate purpose. You don't need a signature, you don't need a model of normal — interaction is the verdict. Someone touched it, someone confessed. And I want to be precise about false positives here, because it's the whole point: signature and anomaly detection have false positives baked in — they misclassify, that's the nature of the method. Honeypots don't. The only way to get a false positive is to point one of your own legitimate workflows at the bait — and that's a config mistake, not noise. There's an allowlist for exactly those cases. So it's not that we tuned the false-positive rate down to zero; it's that false positives aren't inherent to how this works. And on top of that, it catches attacks you never anticipated.

And there's a twist that works in our favor here. An autonomous attacker-agent is actually more likely to take the bait than a human. A human might hesitate — “a tool called dump_wire_transfer_keys, that's suspiciously perfect, maybe it's a trap.” An agent optimizing for “find valuable data” just sees a tool named for exactly what it wants, and calls it. The bait is tuned to how an agent reasons. HoneyMCP takes that whole principle and brings it down to the MCP tool layer — where, as we just saw, every other method falls apart.

Short generated clip plays (see the video card in Part 1 for the prompt). Optional line over/into it: “That's the whole idea in one picture — everything looks the same, until something reaches for the one thing it shouldn't.” Then cut to Slide 9.

Concretely, HoneyMCP is middleware for any FastMCP server. Here's a normal server with a real tool on it. You import honeypot, you wrap the server — mcp = honeypot(mcp) — and that's the whole integration. One line.

What that does: it registers ghost tools that show up in list_tools right alongside your real ones. So the instant an intruder enumerates the server during discovery, the bait is already sitting in the menu — and it's the most tempting-looking thing there. Your real tools keep working exactly as before, and a legitimate workflow never has any reason to call the bait.

Two kinds of bait. First, a static catalog — around twenty curated honeypots. Some are exfiltration bait, like list_cloud_secrets or dump_database_credentials. Others target abuse, like execute_shell_command or escalate_privileges.

The second kind is the interesting one: dynamic, LLM-generated bait. HoneyMCP reads your server's actual tools, understands the domain, and invents honeypots that fit. Point it at an HR server, it generates something like export_employee_records. Point it at a banking server, you get dump_wire_transfer_keys. Because the bait matches the domain, it blends right in — and more than that, it's tuned to how an attacking agent reasons: it's named for exactly the capability the agent is hunting for. A static, off-the-shelf network honeypot simply can't do that. You'll see this live in a minute.

The moment a ghost tool is called, we don't just raise an alarm — we capture an attack fingerprint. Which tool was called, the arguments passed, and critically the full sequence of calls leading up to it, so you can see exactly what the intruder did. Plus threat level, category, session, timestamp, and the response we handed back.

It's stored as JSON on disk and it feeds everything downstream — a live dashboard, Slack and webhook alerts, pattern detection across sessions, forensic replay. So you get a reconstructable intrusion timeline, and you get it at the discovery stage — before any real data leaves the building.

One more idea before I show you: what happens after the trip. It's always scoped to that one session, so a caught intruder never affects your real users.

Default mode is SCANNER — immediate lockout. Once they've tripped the wire, every further call just errors. Simple and fast against automated scanning.

The second mode is COGNITIVE, and it's my favorite. Instead of locking them out, you keep them engaged — your real tools quietly start returning LLM-generated fake data. The intruder thinks they're succeeding and keeps digging, while you gather intelligence on what they're after. The trap doesn't just sit there — it plays back.

Let me show you. Here's an ordinary internal MCP server — no protection. I'll connect a client and enumerate it… and there's the tool list — just the real tools. If an intruder found this right now, nothing would catch them.

Now the same server with one line added at the bottom — honeypot(mcp, use_dynamic_tools=True). I start it up… HoneyMCP reads the real tools and generates domain-matched bait. I reconnect and enumerate again — and now look. The real tools are still here, working. But sitting right next to them are the ghost tools HoneyMCP generated, and notice they're flavored to this exact server — the juiciest-looking targets on the menu.

Now I'll play the intruder who just found this endpoint during discovery — and this could just as easily be an attacker's autonomous agent doing exactly what I'm about to do by hand: enumerate, spot the juiciest tool, call it. I go for the most valuable-looking tool — the one that looks like it dumps sensitive data. I call it… and it returns what looks like real, sensitive data — synthetic, of course. From the intruder's side, it worked. But behind the scenes, HoneyMCP just fired.

Here's the HoneyMCP dashboard — the real-time console. And there's the hit. Let me open it. Full fingerprint: the tool called, the arguments, threat level high, category exfiltration, the session, the timestamp — and the call sequence showing exactly what they did leading up to it. That's the difference between an alert and actual forensics. I can reconstruct the whole intrusion.

And quickly, COGNITIVE mode. Here's a server in cognitive mode. I trip a honeypot as the intruder — detected. But now when I call a legitimate tool, instead of locking me out, it hands back fake data. The intruder keeps probing, thinks they're pulling real records, and every extra call is just more intelligence for the defender. They've walked into a hall of mirrors.

Back to slides to wrap up. Quick bonus: if the built-in catalog doesn't have the honeypot you want, you can create one from plain English. Run honeymcp create-tool with a description like “dump container registry credentials,” and a ReAct-style agent reasons about it, generates realistic fake data, validates the code, and installs the new honeypot. No manual coding.

So why does this matter. MCP servers are a new, under-defended surface sitting on internal networks, and honeypots are exactly the right sensor for them — because they're the one technique that doesn't need to know in advance what “bad” looks like. HoneyMCP gives you that in one line, with near-zero false positives by design — and I mean that structurally: the only false positive is a legit workflow you accidentally pointed at the bait, which the allowlist handles. Plus rich forensics, pluggable backends, alerting, and a dashboard. And whether the attacker is a human or their own AI agent, the sensor works the same way.

Let me be honest about the scope, because it makes the tool more credible, not less: HoneyMCP catches intruders who take the bait during discovery or exfiltration. It won't catch someone abusing a real tool they're legitimately allowed to use — that's what least-privilege and auth are for. This is detection, not prevention: a defense-in-depth layer that most people running MCP servers simply don't have yet. And it's fully open source, Apache 2.0.

That's HoneyMCP — honeypots for the MCP layer. It's on GitHub at github.com/barvhaim/HoneyMCP, and you can just pip install honeymcp to try it today. If you're deploying MCP servers on your network and you've wondered how you'd know when someone's poking at them — this is for you. Thanks so much for watching, please come find me at the station, and I'm happy to take questions. Enjoy Black Hat.