MCP servers for infrastructure tools are going to keep showing up - deploy platforms, database admin tools, cloud consoles, all of them. Building one is genuinely not that hard technically; it's a weekend of wrapping existing operations as typed tools. The part worth actually thinking about is what an agent should and shouldn't be allowed to do once you've wired it up, because "it works" and "it's a good idea" are answered by completely different questions.
I built DeployOS's MCP server, so this is grounded in specific decisions I had to make, not abstract principle.
Read access and write access are not one decision
The obvious-in-hindsight mistake is a single on/off switch for "AI access." That forces you into one of two bad defaults: too permissive (an agent that can read logs can also tear down a database), or too restrictive (you have to disable inspection just to avoid enabling destruction). They're different risk categories and deserve different toggles. DeployOS ships fifteen read-only tools always available the moment MCP is on, and every write-capable tool - deploy, restart, scale, teardown, database writes - is its own separate, off-by-default switch.
Values should never be readable, only names
An agent that can check whether DATABASE_URL is configured doesn't need to see what it's set to. This sounds obvious written down and is very easy to get wrong in practice, because the natural implementation of "let the agent read app config" returns the whole config object, secrets included, unless someone deliberately strips them. Every response an infrastructure MCP server returns should be audited for this specifically - not assumed safe because "it's just internal tooling."
Some actions should never happen without a human seeing them first
Not everything needs a confirmation dialog - that would make the tool useless, since half the point of agent access is not having to approve every restart yourself. But a small set of genuinely irreversible or high-blast-radius actions - tearing down a resource, scaling something to zero, running an arbitrary write against a database - are different in kind from "restart this container," and deserve a different bar: a plain-English description of exactly what's about to happen, shown to a human, with a real timeout if nobody answers. Not a checkbox buried in a settings page that gets flipped once and forgotten - a prompt, at the moment it matters.
Everything that changes state needs a log that isn't the chat transcript
The chat log between you and your AI assistant is not an audit trail. It's not queryable the way you'd need it to be, it's not guaranteed to be retained, and it's not structured. If an agent can deploy, restart, or modify infrastructure, there needs to be a separate, local, structured record - what tool, what it targeted, whether it succeeded, when - that exists independent of whatever conversation triggered it. The first time you need to answer "wait, what did the AI actually do to production last Tuesday," a chat scrollback is not going to cut it.
There needs to be a kill switch that's actually one switch
If something's gone wrong - the agent misunderstood an instruction, got prompted into something you didn't intend, or you just want a clean stop - you should not have to remember which of a dozen individual toggles to flip. One control, denies every write-capable action instantly, read access keeps working so you can still investigate what happened. This is boring to build and easy to skip, which is exactly why it's worth calling out.
What I'm deliberately not claiming
I don't run a scoped, sandboxed identity for the agent on the server side - DeployOS's architecture is local-first specifically so there's no server-side agent process at all, which sidesteps that problem rather than solving a harder version of it. There's no policy language, no infrastructure-derived automatic risk scoring, no session replay. Those are real ideas and I think they get built eventually, by someone, once this space matures - but claiming to have them before they exist is worse than not having them, because it's the kind of claim that fails exactly when you're relying on it.
The list above isn't exhaustive and it isn't a spec. It's the set of decisions I had to actually make, in order, building one specific MCP server for one specific class of infrastructure tool - shared because the underlying questions apply well beyond DeployOS, and mostly aren't being asked out loud yet.