Enforced by Infrastructure, issue 1.
I just gave the MCP governance keynote at MCP Toronto, and I have to tell you:
the main message was not about technology. It was about making friends with your
users, because they're going to have these agents in their hands. The agents are
going to help them find their way around all the little holes and little walls
you haven't put up around your internal infrastructure, because it isn't
production and we don't treat it like production.
The premise of this whole issue is that people are still at the center of this
technological revolution, and that not putting sensitive things on top of
sensitive things, like running agents inside the end-user space, is still the
thing.
What happened when the answer was no
A user wanted an agent to manage their email. Reading mail was approved. Sending
as them was not: the person on the other end expects a human. There was no MCP
server for Outlook, so the user asked the agent whether there was another way.
There was. Classic Outlook exposes a COM automation interface, scriptable from
PowerShell. The agent wrote the script and read and sent mail through it.
Outlook does guard that interface, but by default it warns only when antivirus
is inactive or out of date, so on a healthy, managed laptop the agent goes
straight through.
Then the user asked for the same thing in Teams. Told no again, they switched on
remote debugging in Edge, the approved browser, and let the agent drive the
browser through Teams and Outlook. The Edge policy that controls this,
RemoteDebuggingAllowed, allows debugging unless an administrator sets it.
You should be treating your users like customers and figuring out how to
delightfully satisfy them, because otherwise they're going to use these same
agents to push the boundaries. Are some of them going to do that anyway? Of
course.
Why blocking agents fails
You're not going to know. Classic Outlook is supported until at least 2029, and
open-source MCP servers that drive it over the same COM interface are on GitHub
today. The MCP specification's security policy says that administrators are
responsible for server selection. Of nearly 8,000 live remote MCP servers
measured this year, 40 percent exposed tools with no authentication at all.
I think those decisions are mainly defensible, but together they mean that the
yes or no is yours. In other words, the people publishing these MCP servers are
not going to stop you. And even more importantly, if you don't have a way of
satisfying your users, they're going to use these agents to figure out a way to
satisfy themselves.
So does that mean we should take the agents away? No. I'm suggesting an
alternative.
Stop putting sensitive things on top of sensitive things
Both workarounds above worked because the agent ran on the same laptop, in the
same security context, with the same identity as Outlook and Edge.
So why are we running these incredible agents of chaos, also known as coding
agents, locally on endpoint devices that already carry an authentication
context, where the price of a mistake by the user or by us is tremendous? They
are, in a sense, inside the house making the phone call.
They have access to user mistakes, in an environment where users feel
comfortable and leave tokens and PATs and keys lying around. Even if they don't,
the agents are inside our firewall, in a non-isolated environment where you
somehow have to tell the user's behavior apart from the agent's, while the user
sits there asking it to do things constantly.
Why? Because we told them to. We told them to experiment.
I'm not talking about the model. The model can live somewhere else. The agent
harness is sitting inside the system. Why aren't we running it on a remote
system? In my own world, I don't run agents on my laptop. They run on a remote
system, and if I give that system access to anything, it's super explicit,
because it's a server with no OneDrive, no Outlook, no Firefox, no Chrome, and no
PATs lying around. Don't get me wrong, I've made mistakes and left keys out
there. But the agent runs under its own user, separate from mine, with limited
egress.
Coding agents in particular are some of the most unpredictable pieces of
software we've ever seen, and yet we're putting them on one of the most
unprotected, unreliable, convenience-focused platforms there is: the end-user
device. I'm not saying internal support is bad, and I'm not saying the tools
aren't mature. But are any of us really ready for the full capabilities of AI?
I've seen commands I haven't seen since the '90s: complex chroot and Bash escape
shells I haven't seen since I was a Solaris user.
So maybe we should all take a step back and think about where we're
prioritizing convenience over security. I am the biggest fan in the world of
giving users what they want. But right now, with how new agents are, how fast
they're moving and how immature our tooling around them still is, it just
doesn't make sense.
Here's what I suggest
- Say yes as fast as you can. Arrive at a sanctioned path as soon as possible. If you don't have a yes, have a "not yet": here's the roadmap, we're working on it, can you help us solve this problem? And I just have to ask your users: please don't try to force the agent to do something you know is out of bounds.
- Decide on risk, not on function. Read, draft and send are three different yeses. Split your tools so each one sits at a single risk level. I believe Anthropic does this, keeping MCP servers that read separate from ones that write. I can't cite exactly where I heard that, but I think it's still true.
- Enforce outside the prompt. Put the decision where the agent cannot talk its way past it: the gateway, workload identity, admission control. That holds until we get singular identities for agents and sub-agents, with their own scoping and control, on the end-user device. I'm thinking of something like AppArmor or SELinux for end-user devices.
- Run the agent harness off the endpoint. Give it a remote machine, grant it very limited egress, and grant MCP servers and data to it explicitly.
On the laptops that remain, close the doors to these workarounds: set
RemoteDebuggingAllowed, and tighten the Outlook programmatic-access guard
rather than leaving it on the antivirus default.
I know we're going to discover these things as we go, but that's not going to
help. We are not ready. And the one simple move of taking the agent off the
endpoint gives you so much breathing room.
The message
If you ask me what the technical message was behind how you govern MCP for a
workforce the size of a city, it's this: make friends with your users. Oh, and
if you want a technical answer, move those chaotic little Tasmanian devil coding
agents off to their own isolated desert, so they can't wreck your luscious city
of end-user computing.
Slides and links from the Toronto keynote
I'm Michael Forrester. Feel free to completely lambaste this article and take it
apart. I'd love to hear from you.
Top comments (0)