Is it just me or are developers not doing enough risk assessment with using MCP?
I keep seeing people plug in community MCP servers to their Unity editors like it’s no different from installing a new package. But I actually sat down and read through the source code of CoplayDev/unity-mcp on GitHub and the security posture is not good.
Disclaimer up front: I used AI to help with this analysis, so there could be things I got wrong or overstated. If you see something off, call it out. But even if some of these concerns are overblown, I think it’s a conversation worth having because I’m not seeing anyone else have it.
What I found in the code
- The “execute_code” tool runs arbitrary C# inside your editor with full .NET access. It has a “safety_checks” parameter that can be set to false. The tool’s own error messages literally tell the LLM how to disable it: “Disable safety checks with safety_checks=false if this is intentional.” That’s not a safety net, that’s a speed bump with an ignore button.
- The HTTP server on localhost:8080 has zero authentication. No API key, no origin validation. Any process on your machine can POST commands to /api/command and Unity will execute them.
- “manage_packages” accepts arbitrary git URLs. A prompt injection could tell the LLM to install a malicious UPM package from any repo. That package compiles and runs inside your editor with your full user permissions.
- The safety blocklist is 12 exact string matches. Things like File.Delete and Process.Start. You can bypass them with basic reflection, dynamic invocation, or just turning safety checks off. The codebase itself admits: “NOT a security sandbox.”
- No WebSocket origin validation. The /hub/plugin endpoint accepts connections from anything in local mode.
- “batch_execute” allows up to 100 commands in a single call. One prompt injection can chain a complex multi-step attack.
- Telemetry phones home to api-prod.coplay.dev by default. You have to manually set DISABLE_TELEMETRY=true to stop it.
“But localhost is fine, right?”
I know what you’re thinking. We all run dev servers on localhost. Webpack, React dev servers, database GUIs, local APIs. That’s normal. But those servers serve files or handle CRUD. The worst someone can do is request your webpage.
This MCP server on localhost can compile and execute arbitrary C# with full .NET runtime access. System IO, System. et, System.Diagnostics.Process. No auth required. That’s a fundamentally different risk than localhost:3000 serving your React app.
Why this is worse than it sounds
The LLM reads data from your Unity project: asset names, console logs, scene files, package metadata. If any of that data contains text that looks like instructions, the LLM might follow them. And this LLM has tools to create scripts, delete assets, run builds, and execute arbitrary code in your editor.
But here’s what really concerns me. You might not even need to be using the MCP tool directly to be vulnerable. If you’re running any AI agent on the same machine (email assistant, chat agent, browser AI, whatever) and that agent has the ability to make HTTP requests, it could be fed a prompt injection through completely normal-looking content. An email. A GitHub issue. A Slack message. The hidden payload tells the AI to hit localhost:8080/api/command, which has no auth, and Unity executes whatever it’s told.
A developer doesn’t click anything suspicious. They don’t open a malicious attachment. The email just has to be read by an AI agent on the same machine. I’ll admit this scenario depends on the specific AI agent being able to make local HTTP requests, so it may not apply to every setup. But the surface area is growing fast as more agents get network access.
We’ve seen this pattern before
This isn’t a new type of risk. We just saw Notepad++ get compromised by state-sponsored attackers through their update infrastructure (search “Notepad++ hijacked incident” for details). Attackers hijacked the update mechanism and delivered malicious executables to targeted users for months. Kaspersky found they were rotating C2 servers and infection chains monthly to avoid detection. The Notepad++ updater didn’t properly verify downloads, so users got compromised just by updating their software.
Unity itself had CVE-2025-59489, a high-severity flaw (CVSS 8.4) in the Unity Runtime where attackers could force Unity apps to load and execute arbitrary code through untrusted file loading. Valve had to push a Steam client update to block it, Microsoft added Defender rules, and Obsidian had to pull games from stores.
Now imagine that same category of risk, but instead of needing to compromise an update server or exploit a file loading bug, the attack vector is just text that an AI reads. That’s what an unauthenticated MCP endpoint with arbitrary code execution gives you.
Unity is building their own, and it looks like they get it
Unity’s official AI Assistant package (com.unity.ai.assistant, currently at 2.5.0-pre.2, check the Unity package docs) seems to be addressing exactly these problems:
- Permissions system that requires explicit approval for file create/modify/delete
- Relay architecture instead of an open HTTP endpoint
- Batch auto-approve is opt-in, not the default
- Ask mode for read-only interactions that don’t execute actions
- Skill validation with editor version gating
That’s the minimum viable security posture for this kind of tooling. The community tools have none of it.
So what should we do?
I’m not saying MCP is useless. The productivity gains are real. But the security story with the community tools right now is basically “trust the vibes.” If you’re at a studio with proprietary source code, internal network access, or any kind of shared dev environment, plugging in an unauthenticated MCP server that can execute arbitrary C# in your editor is a real risk.
My take: wait for Unity’s official tooling to hit stable. Or at minimum, strip the write access tools if you’re going to experiment with the community options.
I could be wrong about some of this. Like I said, I had AI help with the code review and I’m not a security researcher. But it seems foolhardy to just download this into your personal machines, let alone your work ones.
Is anyone else actually looking at this stuff before plugging it in?