Letting an AI Assistant Deploy for You, Safely
InfraPilot Team
June 27, 2026
The promise and the fear
AI assistants are increasingly good at operational work: deploy the checkout branch to a preview, report how many replicas the API is running, roll back the last deploy. The promise is obvious. The fear is just as obvious: you do not want a model, or a prompt injection hiding in a webpage it read, to have a straight line to production.
InfraPilot's answer is to make the assistant a first-class client through an MCP server, and then to scope what that client is allowed to touch. The capability and the guardrail ship together.
What MCP is, briefly
MCP (Model Context Protocol) is a standard way for an AI assistant to call external tools. Instead of pasting shell commands into a chat and copying output back, the assistant talks to a server that exposes a defined set of actions. InfraPilot runs one of these servers, so any MCP-capable assistant can drive deploys, scaling, fleet status, and preview environments through a typed interface rather than by guessing at CLI flags.
The safety model: preview-only keys
The important design decision is scope. You can hand an assistant a preview-only API key. With that key it can create and destroy preview environments all day, and it cannot modify production. The blast radius of anything going wrong (a bad instruction, a confused model, an injected prompt) is a throwaway preview that expires on its own.
This maps cleanly to how you would trust a junior engineer in their first week: let them spin up disposable environments freely, and keep the production controls behind a separate, human-held key.
A realistic workflow
A session might go like this. You ask the assistant to preview a branch. It calls the MCP server, which builds the branch to a preview subdomain and returns the URL. You review it, ask for a change, and the assistant redeploys the preview. Nothing in that loop can reach production, because the key it holds does not carry that permission.
Assistant -> create preview for branch "redesign-nav"
MCP server -> building... https://redesign-nav.preview.example.com
Assistant -> here is your preview URL
When you are happy, a human promotes the change through the normal deploy path with a normal key.
Guardrails worth keeping
Even with scoped keys, a few habits are wise:
- Give the assistant its own key, not a shared one, so you can revoke it without disrupting anyone else.
- Keep production deploys on keys that only humans hold, at least until you have watched the assistant work for a while.
- Rely on the audit log. Every action through the MCP server is recorded the same way a CLI or dashboard action is, so you can see exactly what the assistant did and when.
AI-native operations do not have to mean handing over the keys to everything. Scope the key to disposable work, keep the audit trail, and the assistant becomes a genuinely useful pair of hands.
Related posts
Blocking Vulnerable Images Before They Ship
Nightly vulnerability scans catch bad images after they are already running. Deploy gates move the check to build time, so a critical CVE blocks the deploy instead of becoming next month's incident.
Secrets in Self-Hosted Docker: Stop Committing .env Files
The .env file works until it leaks, drifts, or gets committed by accident. Here is what moving to an encrypted secrets store with versioning and container binding actually changes, and how to migrate without code changes.
Preview Environments for Every Branch, on Your Own Box
Reviewing a diff only gets you so far. Preview environments give every branch a live URL on your own servers, with wildcard SSL and automatic teardown, so reviewers click instead of imagine.