When the AI gets hands on your IT stack: MCP, agents, and the permission model nobody wrote

The first time I saw an agent send a real command to a real laptop, my hand stayed on the mouse the entire time. Not for any reason I could articulate. There was nothing to click.

The instruction was one sentence: send a remote MDM command to this user's machine. Just a username. No device ID, no serial, no console open in a second tab.

The model worked out which tool to call, resolved the username to a device record, pulled the serial, fired the command, and then did something nobody asked for. It compared the command-sent timestamp against the device's last check-in timestamp to decide whether the command had actually landed, and reported back that it had.

Verification. Unprompted. That was the moment AI agent IT automation stopped being a thought experiment for me and became a thing I need a written policy for.

What it actually did, in order of how much it moved me

One team wired an agent into their device management platform through that platform's MCP server, added a homebrew connector for Apple Business Manager, and worked through a run of ordinary admin tasks. Start at the boring end, because the boring end is where most of the value is.

Counting and filtering devices in plain language: how many Macs versus Windows machines do I have enrolled, without opening the reporting section and building anything. Every device management platform has this data and every one of them makes you assemble a report to see a slice of it that the product designer did not anticipate.

Then it got more interesting. Asked which devices could run a new OS release, the model pulled the hardware models from the platform through its MCP server, went out to the open web for the OS system requirements (which were in neither the tool response nor its training data), and correctly concluded that 16 of 17 devices were eligible and one was not.

Then a full interactive reporting dashboard, charts and all, from one prompt. It joined device details, known vulnerabilities, and installed applications. There is no single native report view that shows those three things together, which is precisely why somebody would have spent a Thursday exporting CSVs.

The example I keep repeating to people chained three unrelated systems: find every device with a CVSS score above 9, identify who owns those devices, then check the calendar for any meeting with those people in the next two weeks. No integration code, no middleware, just natural language across a few connectors.

Let me not oversell the mechanism, because it is less magical than it looks. The model is reading a list of tool names and short descriptions and reasoning about them the way a person reasons from plain English. It infers that "get device apps" means installed application binaries. It also works out that "list devices" has to run before "get device details," because the second one requires a device ID as a required parameter.

That is genuinely useful. It is also the entire weakness.

Your safety layer is a paragraph of prose

When an AI client asks an MCP server what it can do, what comes back is a list of tools with short text descriptions. Strings. That is it.

The model's understanding of what a tool does, whether that tool is destructive, and what it needs to run correctly is entirely dependent on how well some human wrote a sentence. A tool described badly is invisible or misused. A tool described well gets called correctly. Nobody has published a methodology for how verbose or how structured those descriptions should be, and the people building them will tell you so if you ask.

One team was candid about their own inconsistency. They had a destructive integration-deletion tool with prominent warning language wrapped around its description, and the model treated that action as high-stakes and proceeded carefully. A comparably destructive tool, erasing a device, had no such warning styling. The model was still cautious about it, but only because the word "erase" was sitting in the description doing the work by itself.

Read that again. Warning language in a text description measurably changed how the model behaved around destructive actions.

That is the safety mechanism, today, running in production somewhere near you. Prose, written by whoever wrote the tool and reviewed by nobody in particular.

I am not raising this to alarm anyone. I am raising it because I spent months assuming MCP had a permission model somewhere in the protocol and that I simply had not read that part of the spec yet. It does not, and being wrong about that changed what I pay attention to. The capability questions in AI IT operations mostly answer themselves now. The question that stays hard is who gets to say no, and how. Tool descriptions are advisory. Token scopes are real.

Fifteen minutes and about twenty dollars

Here is the number that reframed the effort question for me.

Somebody hand-built a small proof of concept MCP server covering two endpoints of a vendor API. Then they pointed an agentic coding tool at it and asked it to build out the rest of the API surface. The whole thing came back in about fifteen minutes, for roughly $20 in tokens on a frontier model, with tool descriptions adapted from the vendor's own published API docs.

It also made design decisions on its own. It grouped related API calls into fewer, better-organized tools, based on how a person would actually phrase a request rather than how the API happened to be shaped. That is the kind of judgment I would expect from a mid-level engineer who had used the product.

So the build cost is near zero and falling. Which means the queue of things standing between your team and an agent with hands on your stack is not engineering time anymore. It is governance, and governance has always been the slower queue.

Cost and latency are still real at runtime, by the way. That OS compatibility question took noticeably longer and cost actual money, purely because the model had to leave the tool response and search the web for system requirements. Reasoning across systems is not free the way a scripted API call is free.

The objection I keep coming back to

The strongest counter-argument I have heard came from a practitioner who was not being contrarian for sport.

A hand-written script gives you 100% reliability with explicit error handling and exception handling that a human thought about in advance. Replace it with natural language over MCP and you trade that certainty for flexibility. You get a system that can handle a request nobody anticipated, and you give up knowing exactly what it will do.

His deciding question was better than any framework I have seen since: consider the consequence of a wrong answer.

If the exact same task repeats identically every single time, write the script. Determinism remains the correct engineering answer for invariant work, whatever else changes, and I get twitchy watching people rip out functioning automation because the new thing has a nicer interface. Scheduled compliance reports, nightly syncs, enrollment workflows that never vary: script them.

Agentic flexibility earns its money when the task or its inputs vary unpredictably. Think of the one-off question you would otherwise spend an hour assembling out of three CSV exports, or the correlation nobody ever built a report for, or an investigation where you cannot know the second question until you see the answer to the first.

Most of what a help desk does in a day is in that second category, which is why this matters more for support than for infrastructure.

Starting for real, in order

If you want to do this without a story that ends in a restore from backup, the order is not negotiable.

1. Find out whether your vendors even have an MCP server. A surprising number of people tasked with rolling out enterprise AI have not gotten this far, partly because MCP was released as a draft in late 2024 and is barely eighteen months old. Ask your account rep. Half of them will need to go ask someone.

2. Understand which architecture you actually need. A local standard-IO MCP server runs on your own machine and works with desktop agentic tools like a CLI coding assistant. It costs nothing to host. It is also completely unusable from a cloud-hosted AI product, because the request originates in the vendor's infrastructure and never reaches your machine. If your team lives in a browser-based AI tool, you need an HTTP-hosted server. This trips up more people than anything else in the stack.

3. Create a dedicated API token for MCP, scoped read-only. Not your admin token. A new one, with MCP explicitly enabled, and a permission matrix you have actually looked at: can this token list blueprints, or also create and modify them; can it view users, or manage them. Read-only is the safe on-ramp and it is where you should stay for at least a few weeks.

4. Do reporting and correlation first. Read-only cross-system questions are the low-risk category and they are also the ones with the fastest visible payoff. The vulnerability-to-owner-to-calendar chain is a read-only workflow. Nothing in it can ruin your afternoon.

5. Fix your tool descriptions before you grant write access. If you are building your own server, this is your security review. Every destructive tool gets explicit warning language, consistently, and someone other than the author reads them.

6. Put the guardrail in the prompt too. Before any offboarding or wipe workflow, instruct the agent directly: interview me and confirm with me before you take any destructive action. Belt and braces. The model's own judgment is one input, not a control.

7. Only then consider an aggregator. There is an emerging category of MCP server of MCP servers, where an organization registers its connectors once, centrally, instead of configuring dozens of them on every engineer's desktop client. That is obviously where this ends up. It is also a crowded space full of startups that will not all survive, so I would not build a dependency on one this quarter.

Eighteen months old and already in your building

Something I did not expect to find sympathetic: the vendors have their own reason to want this.

If customers keep asking a device management platform for one more custom report view, that platform slowly becomes a BI tool inside of a tool, in a completely different business than the one it started in. Every roadmap hour goes to reporting features instead of the thing you bought. Handing customers a good MCP server and letting them ask their own questions is genuinely better for both sides, which is a rarer alignment than it sounds.

The awareness gap is the thing that will bite. Some of the people responsible for enterprise AI in their organizations first heard of MCP a few weeks before they needed an opinion on it. Others already knew and were stuck at the earlier question of whether their vendors offered anything at all.

Meanwhile the technology went from advising to acting in about a year, and it did it without a permission model, on a protocol still labeled early by the people who wrote it.

I have been in this industry long enough to know how the next part goes. Somebody's agent will do something spectacular and irreversible, there will be a postmortem with the word "unexpected" in it, and then the whole field will get the permission model it should have had first. That is how we got change control, and code review, and the ticket queue you are currently complaining about.

I would rather we skipped a step this time. We have scoped tokens and confirmation prompts sitting right there, and they cost an afternoon.

---

Foqal connects IT support conversations in Slack and Teams to the systems where the work actually happens, with a record of who asked for what.