HoneyMCP: An MCP Server Honeypot for AI Infrastructure Research
MCP servers are quietly becoming part of modern enterprise infrastructure.
AI agents need tools. Tools need access to internal systems. Before long, organizations end up with services capable of reading tickets, querying databases, interacting with Kubernetes clusters, accessing file systems, or operating production workflows on behalf of AI systems.
That creates a new class of target most organizations have barely started thinking about yet.
Today, Asteros is releasing HoneyMCP, a purpose-built MCP Server Honeypot designed to help security teams and researchers study attacker behavior against Model Context Protocol infrastructure.
What HoneyMCP Is
HoneyMCP is a fake internal MCP server designed to look completely real. Deploy it and it presents itself as a legitimate enterprise tooling endpoint, complete with an employee directory, document search, a secrets vault, a ticket tracker, a file server, and a shell. All of it is fake. All of it is logged.
Every connection, every tool call, every argument an attacker passes gets recorded with session fingerprinting and optional real-time webhook alerts. You get a clear picture of who found your MCP infrastructure, how they found it, and what they tried to do once they were in.
Why We Built HoneyMCP
Security teams already understand the risks around exposed admin panels, cloud storage, CI/CD systems, and internal dashboards. MCP infrastructure changes the shape of the problem.
A modern MCP server may have:
- Access to internal APIs
- Service credentials
- File system visibility
- Employee or customer data
- Infrastructure automation tooling
- Database connectivity
- Trusted relationships with AI agents
An attacker who discovers one is not just finding another web application. They’re potentially finding a programmable interface into internal operations. That deserves more attention than it’s currently getting.
The problem is visibility. Most organizations do not know:
- Whether attackers are already scanning for MCP infrastructure
- What attacker tooling looks like in practice
- How quickly leaked MCP credentials get abused
- What attackers attempt once admitted
- What realistic MCP reconnaissance behavior even looks like
HoneyMCP was built to generate real-world telemetry around those questions.
How it Works
The tool ships with four pre-built personas:
- k8s-infra: looks like a Platform Engineering or SRE tooling server, complete with kubectl, helm, terraform, and ArgoCD context
- support-copilot: mimics a customer support billing environment with Stripe CLI, Zendesk, and a billing database
- security-soc: presents as a security operations center with Okta, CrowdStrike, SIEM data, and incident reports
- data-platform: impersonates a data engineering environment with dbt, Snowflake, and Airflow
The four built-in profiles are just a starting point.
The org name, internal domain, server port, and employee roster all live in a YAML config file you can edit directly or update through the setup wizard. Two deployments running the same k8s-infra profile look like completely different companies because the identity layer is separate from the persona layer.
If none of the built-in profiles fit what you’re trying to simulate, you can build your own from scratch. Set profile: "" in your config, define your own identity and tools blocks, and you have a fully custom persona with no inherited defaults. Individual tools are plain async Python functions, so extending the tool surface is straightforward: add a module, implement the function, register it, add it to your profile’s tool list.
The goal is that no two HoneyMCP deployments need to look alike. Attackers who encounter multiple instances shouldn’t be able to fingerprint them as honeypots based on shared characteristics. The more your deployment resembles your actual environment, the more useful the data it generates.
The Most Interesting Mode
leaked_key is where it gets useful for real research. You configure a specific Bearer token, then deploy that token somewhere it might plausibly leak: a public GitHub repo, a pastebin, a .env file in a test environment. Any client that shows up with the right token gets admitted. Everything they do gets logged.
This lets you measure how quickly leaked credentials get picked up, what scanning infrastructure finds them, and what attackers actually try once they have a working key.
Secondary admission strategies let you admit every Nth unique client fingerprint, or automatically admit any client whose request contains known exploit patterns: Log4Shell, Shellshock, prompt injection, command injection, path traversal, SSRF.
Canary tokens
Each profile includes canary files and shell commands that fire a webhook alert on access. You can plug in real monitored tokens from canarytokens.org or your preferred provider before deploying. This gives you out-of-band alerting that doesn’t depend on the honeypot process being healthy to notify you.
Who this is for
If you’re a security team with AI agents already running in your environment, you should know what happens when attackers find the infrastructure those agents depend on. HoneyMCP gives you a safe, instrumented way to find out.
If you’re doing security research on MCP attack surfaces more broadly, it’s a configurable platform for studying attacker behavior without needing to expose anything real.
Released by Asteros
At Asteros, we spend our time simulating adversary behavior against real applications and infrastructure during penetration tests.
Part of making a pentest useful is understanding how attackers actually behave in practice, not just checking for known vulnerability signatures or running automated scans against a target.
We study attacker workflows, reconnaissance patterns, exploit chains, and post-compromise behavior because realistic adversary simulation produces better security findings, better remediation guidance, and ultimately more useful engagements for engineering teams.
HoneyMCP came out of that same mindset.
MCP ecosystems are still early, but the trajectory is obvious. AI tooling servers are moving toward deeper integration with production systems, internal workflows, and operational data.
Security visibility needs to catch up before the attack surface matures faster than the defensive understanding around it.
HoneyMCP is our contribution toward closing that gap.
Questions, issues, or contributions are welcome. If you deploy it and capture something interesting, we’d love to hear about it.
