The AI tool your team wired up is answering to the whole internet

Someone on your team, keen and capable, wanted the new AI assistant to actually do things — read from your database, file a ticket, look something up in your systems. So they stood up a small connector for it: an MCP server (Model Context Protocol, the emerging standard that lets an AI assistant reach out to your tools and data). They got it working, the assistant started doing useful things, and everyone was pleased. It was a good afternoon’s work.

What that afternoon didn’t include was a login on the connector. The server went online reachable from the open internet, with no authentication in front of it — because getting it working and getting it closed are two different jobs, and the first one is the one that feels finished. Now anything that can reach that address can ask your AI connector to do the same things your assistant can: query the database, read the files, use the tools you wired up. And there’s a second, quieter twist — a tool description the server hands out can carry hidden instructions the AI reads and obeys, so a poisoned tool can steer your assistant without anyone seeing the wording that did it.

That’s the quiet failure: not a break-in, but a helpful new door into your systems, stood up in an afternoon and left unlocked because closing it was a separate task nobody was assigned.

Why it stays invisible

This one hides especially well, because everything about it looks like success.

The assistant works. It reads the data, files the ticket, does the demo. Nothing errors, nothing is slow, and the person who set it up has every reason to think the job is done — the visible half of it is. The missing half, a login in front of the connector, produces no symptom at all when it’s absent. An open door and a locked door look identical until someone tries the handle.

It’s invisible organisationally, too. These connectors get stood up by an enthusiastic individual, often outside whatever review a “real” internet-facing service would get, precisely because it feels like a small internal helper rather than a public endpoint. So there’s frequently no record that the door exists — it isn’t on an asset list, nobody owns it, and the people who’d normally ask “is that authenticated?” never saw it go up. The tool-description twist compounds this: because the AI follows instructions embedded in the tools it’s offered, a connector that pulls tools from an untrusted source can be fed hidden commands, and the malicious text lives in a place a human reviewer rarely reads.

None of this is hypothetical. When researchers at Trend Micro scanned the open internet in mid-2025, they found 492 MCP servers answering strangers with no authentication at all — and by the firm’s follow-up in April 2026 that number had nearly tripled, to 1,467. Those are just the doors already standing open: separate research from OX Security, published the same April, estimated around 200,000 MCP installations vulnerable through a flaw in how the protocol runs commands.

The result is an internet-facing path into your tools that nobody is watching, because watching it was never anyone’s job — the same shape as an exposed admin panel, only newer, and wearing the friendly face of an AI helper.

Find it yourself

You can check your own exposure in about ten minutes. The work is mostly finding the connector and seeing whether it answers strangers.

1. Find out whether you have one at all. Ask the people most likely to have built it: “Has anyone connected an AI assistant to our internal tools or data — an MCP server, a custom connector, an agent integration?” If the answer is yes, get the address (host and port) it runs on. Most of the risk lives in connectors leadership didn’t know existed, so this question is half the audit.
2. See whether it’s reachable from outside. From a device not on your office or VPN network — your phone on mobile data is perfect — open the connector’s address in a browser, or have whoever runs it check whether the port is open to the public internet. If it answers from the outside world at all, it’s internet-facing, and the only thing standing between a stranger and your tools is whatever login comes next.
3. See whether it asks who you are. If it is reachable, the crucial question is whether it demands authentication before doing anything — a token, a key, a sign-in. A connector that responds to commands from an unauthenticated caller is the failure in the flesh. (Do this against your own server only.)
4. Check where its tools come from. Ask whoever built it: are the tools this server exposes ones we wrote or vet, or does it pull tool definitions from third-party or public sources? Untrusted tool sources are the route by which hidden instructions reach your assistant.
5. No one’s sure who set it up? Treat that as the finding. If nobody can say whether an AI connector exists, who owns it, or whether it’s authenticated, that uncertainty is the exposure — put a name against finding out before you move on.

The common outcome isn’t a dramatic breach but a slightly awkward “let me check with the person who built that” — which is exactly the conversation this is meant to prompt.

The fix

Closing this is straightforward once you know the connector is there; the harder part is making sure the next one doesn’t repeat the pattern.

Put it behind a login, or off the public internet entirely. An AI connector reaching your internal tools should not be open to the world. Either require authentication on it — a token or key that callers must present — or, better for an internal helper, keep it off the public internet altogether so it’s only reachable from your own network or VPN. If you’re not sure it needs to be public, it almost certainly doesn’t.

Only give it tools from sources you trust. Because the assistant obeys instructions carried in tool descriptions, restrict the server to tools you wrote or have reviewed, and be wary of connectors that load tool definitions from third parties. Treat a tool description as code the AI will follow, not as harmless metadata.

Give it the least access it needs. Whatever the connector can reach, an attacker who reaches the connector can reach too. Scope its access to the specific data and actions it genuinely requires, so an exposure is contained rather than total.

Put AI connectors on the list of things you review. The root cause is that these go up outside normal review. Add “AI assistants and their connectors” to whatever inventory and periodic check you already run for internet-facing services, so the next enthusiastic afternoon’s work gets the same “is that authenticated?” as any other new door.

None of this needs a security team. It needs someone to ask whether an AI connector exists, check from the outside whether it answers strangers, and — where it does — put a lock on it before anyone else tries the handle.