Giving an AI assistant safe access to your cloud: how to control the blast radius

Every engineer asks it the first time, and they're right to: you want me to let a language model touch my production infrastructure?

That's the correct question. It's also the one most "AI ops" pitches dodge. The honest answer isn't "trust the model" — models are useful and they are also, sometimes, confidently wrong. The answer is that you don't have to trust the model. You control the blast radius. You decide, in advance and at the boundary, what the assistant is even capable of doing, so that a wrong answer costs you a confused sentence instead of a deleted volume.

That's the lens worth bringing to any AI-plus-infrastructure setup. Here's how it applies to the American Cloud MCP server, layer by layer.

The key is the boundary

Start at the bottom, because the bottom is where guarantees live. An AI assistant talking to your cloud does it through an American Cloud API key. If that key is read-only, mutation is impossible — not discouraged, not filtered, impossible — at the account level. The assistant can list, inspect, and price every resource you own and still cannot create, modify, or delete a single thing.

This matters because of what it is not. It's not a prompt that says "please don't change anything." It's not a system instruction the model might reinterpret, a guardrail it might talk its way around, or a setting buried in a config the model can read. It's a capability boundary enforced by the API itself. A key that can't write can't be argued with. No amount of clever phrasing — yours, the model's, or a malicious string that slipped into a log it's reading — gets past a credential that has no write permission to begin with.

When you reason about AI access, anchor on this first. The strongest control isn't the smartest filter; it's the permission the credential was never granted.

The server defaults closed

The next layer sits one step up, and it's the same philosophy expressed in software. The American Cloud MCP server is read-only by default. Out of the box, only read tools — list, get, cost estimates — are registered. The write tools don't exist in the session at all until you add the --allow-writes flag to the configuration.

So there are two deliberate, separate steps between "exploring" and "changing": you have to provision a read-write key and you have to opt in with the flag. Either one omitted, and the assistant stays in look-but-don't-touch mode. Defaults are the decisions people actually live with, and this one defaults to safe. You don't opt out of danger; you opt in to capability, on purpose, when you're ready.

Destructive operations are labeled

Inside the write tools, not every action carries the same weight. Updating a firewall rule is recoverable. Deleting a volume, releasing an IP, reinstalling, reverting — those are the operations you can't take back. The server marks each of those as destructive, and MCP clients that support confirmations use that marker to put a human in the loop precisely where it matters and nowhere it doesn't.

That's the point of the label: it concentrates your attention. You're not asked to confirm every read or every harmless change — confirmation fatigue is its own failure mode. The prompt arrives on the irreversible step, the one worth a half-second pause.

It runs on your machine

The last layer is about where everything happens. The server runs locally, over stdio, on your own machine. Your API keys go straight from your environment to the American Cloud API. There is no hosted middlebox in between — no third-party service that sees your credentials, brokers your requests, or sits in the path between your assistant and your cloud.

And because it's open source under Apache-2.0, with every release published to npm with provenance attestation — cryptographic proof the package was built from the public repository — you don't have to take that on faith. You can read exactly what it does and verify the build chain that produced what you installed. Inspect it, audit it, fork it: github.com/American-Cloud/americancloud-mcp.

A practical on-ramp

Layers are the why. Here's the how, and it mirrors what we recommend in the docs.

Week one: a read-only key and a stack of audits. Wire up a read-only key and put the assistant to work on questions that can't break anything. What's running, and what does each piece cost per month? Which firewall rules are open to the whole internet that shouldn't be? Are there volumes attached to nothing, or reserved IPs assigned to nothing? This is genuinely useful work — the kind of audit that's always postponed because it means an afternoon in the console — and it earns trust against zero risk. You learn how the assistant reasons about your infrastructure before it can touch any of it.

When you enable writes, stay narrow. Use the smallest key that does the job in front of you, not a master key for everything. Keep secrets out of the chat. And because cost-estimate tools are read tools, ask for the price before anything gets created — "show me the estimate first" is a habit worth keeping. If you want the assistant to also write and deploy the application it provisions, our deploy-with-an-AI guide walks through doing that end to end.

The honest paragraph

Models can be wrong. They misread state, they overreach an instruction, they hallucinate a resource that isn't there. The design here doesn't pretend otherwise — it assumes it. That assumption is exactly why the defaults are read-only, why writes are an explicit opt-in, and why the irreversible operations ask before they run. Every one of those layers exists because the model might be wrong, and the whole point is that being wrong stays cheap.

You're not betting on the model being right. You're bounding what wrong can cost. That's a much better bet, and it's one you can actually reason about.

Your keys, your machine, your call

This is the same stance as the rest of the platform. We don't ask you to trust a multinational's policies with your data, and we don't ask you to trust a model's judgment with your infrastructure. In both cases the control sits with you — your keys, your machine, your call — and the system is built so that the safe choice is the default one.

Start read-only, audit everything, and turn on more capability when you decide the assistant has earned it. The MCP server overview has the setup, the safety details, and your first prompt.