Opinion: Make Friends With Your Users, and Get the Agents Off Their Laptops
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.
Nobody upstream will make the call
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 users and administrators are responsible for server selection. The official registry tells consumers to assume minimal to no moderation. Of nearly 8,000 live remote MCP servers measured this year, 40 percent expose tools with no authentication at all.
I think each of those decisions is defensible. Together they mean the yes or no is yours.
Stop putting sensitive things on top of sensitive things
Both workarounds above worked because the agent ran on the same laptop as Outlook and Edge.
Why are we running these incredible agents of chaos, also known as coding agents, locally on endpoint devices behind our security? They have access to user mistakes, in an environment where users feel comfortable and leave tokens and PATs 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.
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? 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, none of the other considerations.
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. Maybe we should all take a step back and think about where we're prioritizing convenience over security. I'm a big fan of giving users what they want, but this just doesn't make any sense.
What to do
- Say yes fast. The sanctioned path has to arrive before the workaround does. If the approved route to a capability takes a quarter, the agent finds the unapproved one in an afternoon.
- Decide on risk, not on function. Read, draft and send are three different yeses. Split tools so each one sits at a single risk level.
- Enforce below the prompt. Put the decision where the agent cannot talk its way past it: the gateway, workload identity, admission control.
- Run the agent harness off the endpoint. Give it a remote machine and grant that machine each access explicitly.
On the laptops that remain, close the doors these workarounds used: set RemoteDebuggingAllowed, and tighten the Outlook programmatic-access guard rather than leaving it on the antivirus default.
The message
If you ask me what the technical message behind that big governing-MCP, governing-agents keynote was, it's this: make friends with your users. Oh, and 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.