Dora NodaThe fastest way to let an AI agent deploy your app is also the most dangerous: paste a production API key into its config and tell it to go. It works on the first try. It also gives a probabilistic system ambient authority over everything that key can touch — every environment, every database, every destructive endpoint — with no record of which action was yours and which was the model's improvisation.
Qovery's June 2026 writeup on MCP servers for infrastructure (Romaric Philogene, June 24) frames the alternative explicitly: instead of handing the agent raw credentials, expose narrow tools — deploy this app, provision that database, read these logs — through one governed interface, with policy enforced server-side on every call. The agent gets capability without authority. That is the right default. It is also not the whole answer, because a governed tool catalog has real costs — in tokens, in accuracy, in maintenance — and there are one-off jobs where raw API access plus a good prompt is the honest winner.
This post settles the decision: what governed tools buy, what they cost, and exactly where raw API still wins. The verdict fits in one table, right here.
The decision in one table
| Dimension | Governed MCP tools | Raw API keys + prompt | Hand-written CLI scripts |
|---|---|---|---|
| Blast radius | Narrow: each tool does one verb, policy enforced server-side | Full key scope: everything the credential allows | Whatever you scripted — and whatever the agent improvises around it |
| Auditability | Per-action attribution: who prompted, what ran, what changed | API logs show the key, not the intent or the human behind it | Depends on your discipline; usually nothing |
| Agent accuracy | Decays as the catalog grows (see the numbers below) | High for one-offs: full API surface, no catalog to navigate | Brittle: breaks on every CLI output change |
| Token cost | Every tool definition rides along in context on every call | Near zero overhead: just the prompt | Near zero, until you paste docs into the prompt |
| Maintenance | A catalog to version, document, and permission — forever | None, until the API changes under you | Per-tool wrappers that rot the fastest |
| Best for | Repeated production verbs: deploy, provision, read logs, scale | Novel one-offs outside any catalog; debugging; tiny teams | Single-tool automation you already run in CI |
Qovery's own post draws a simpler version of this table (raw credentials, CLI scripts, direct REST, MCP server) and lands where this table lands: the MCP server wins for multi-agent production use because it is self-describing, standardized, and governed at the boundary. The rest of this post earns each cell — including the two columns where raw API wins.
What Qovery's writeup actually claims
The setup is worth steelmanning, because the numbers explain why this debate matters now. Coding agents have crossed from assistants to authors: Qovery cites 40% of Cursor's internal PRs coming from cloud agents and over 1 million builds a day running through Codex. Writing code is no longer the bottleneck. Shipping it is — because shipping means touching 5 to 8 separate systems (CI/CD, Kubernetes, Terraform, secrets, monitoring, DNS, registries), each with a human-shaped interface no agent was designed to consume.
Their answer is an infrastructure MCP server: deploy an app from a prompt, provision PostgreSQL/Redis/MongoDB detected from connection strings, spin up full preview environments, manage scoped secrets, and read back deployment status, logs, and cost so the agent can validate its own work. Any MCP-compatible agent — Claude Code, Cursor, Codex, Gemini CLI, OpenCode — connects through one protocol instead of learning N dashboards. And the hard part, in their framing, is not access but governance: RBAC scoping who (and which agent) can do what where, budget and policy controls the agent cannot exceed, and a full audit trail attributing every action.
The concrete product behind the essay matches the framing. Qovery's MCP server at mcp.qovery.com/mcp ships read-only by default: it can query and list resources but cannot deploy, update, or delete anything unless you explicitly opt into write mode with read_write=true — plus a separate write-access setting in the console. Writes authenticate with API Policy Tokens carrying OPA/Rego policy evaluated on every API request, deny-by-default, and agent actions are attributed through those tokens in the organization audit log (their governance comparison). We've covered the other faces of this stack before — what the control-plane fee costs, which parts are open protocol versus rented moat, the five-rung permission ladder, and the identity problem underneath deploy-from-chat — so this post stays on the one question those left open: governed tools or raw keys, and when each wins.
What governed tools buy, concretely
Three mechanisms, each with a concrete failure it prevents.
1. Scope-narrowed verbs instead of ambient authority. A deploy-service tool can touch one service in one environment. A cloud API key can touch everything the role allows — usually far more than the task needs, because keys are minted for humans with broad jobs.
The difference matters most when the agent misbehaves, and agents misbehave through their inputs: Manifold Security found a confused-deputy flaw in Microsoft's official Azure DevOps MCP server where a PR description — rendered invisible in the web UI via Markdown/HTML comments — was returned verbatim by a tool and processed as instructions by the agent (writeup). A hijacked agent holding a narrow read-logs tool reads logs it shouldn't. The same agent holding an admin key is a different incident entirely.
2. Policy enforced server-side, not trusted to the prompt. "Only deploy to staging, never production, and never spend more than $50" is a sentence in a prompt until something enforces it — and prompts are the attack surface. The MaxKB flaw (CVE-2026-77521, CVSS 10.0) showed prompt injection escalating to arbitrary shell commands through attached tools precisely because nothing between the agent's decision and execution re-checked authority. Qovery's Rego-tokens-evaluated-per-request design is the shape of the fix: the policy travels with the credential and is evaluated by the server on every call, so a confused or injected agent gets a denial instead of a deploy. Prompt-level guardrails ("please don't touch prod") are a backstop; server-side policy is the control.
3. Attribution per action, not per key. API logs behind a shared key answer "the deploy key did this." A governed tool call answers "this human prompted this agent to call this tool with these arguments at this time." That is the record an incident review actually needs, and it is also what makes multi-agent operation possible at all: with N agents sharing one key, you cannot tell them apart after the fact. The audit log is not paperwork; it is the thing that lets you widen agent autonomy without widening your ignorance.
So far, governed tools sweep the table. Now the honest costs.
What governed tools cost, honestly
A tool catalog is infrastructure, and infrastructure bills you three ways.
Tokens. Every tool definition rides in the agent's context on every call, whether the agent uses it or not. The GitHub MCP server alone costs roughly 55,000 tokens for 93 tool definitions, and benchmarks on remote MCP servers show 4–32× the token consumption of equivalent CLI calls (Wasowski, June 2026). For a deploy-from-chat hot path hit dozens of times a day, that is metered rent on verbs the agent touches rarely. Local stdio servers cost less — but a hosted infra MCP server is remote by definition.
Accuracy. More tools means worse tool selection, measured, not theorized. Claude Haiku 4.5 picks the right tool 91% of the time at 10 tools and drops to 87% at 15; Claude Sonnet 4 holds 90%+ to 20 tools and falls below by 30 (CodeBun, July 2026). GitHub's own Copilot work found cutting 40 tools to 13 bought 2–5 points of accuracy (meta-survey). A catalog that grows "one more verb" per quarter quietly degrades the agent it serves — the MCP trap piece from May 2026 names tool-selection errors and maintenance burden as the two failure modes nobody budgets for.
Maintenance and residual risk. Every tool needs versioning, descriptions the model actually follows, permission wiring, and updates when the underlying API moves. And MCP is not itself a security boundary: tool descriptions are model-read text, which makes them injection surface (the poisoned-description attack chains Microsoft's IR team walked through in June 2026 run through exactly this channel), and core MCP infrastructure has had its own RCE (CVE-2025-6514, CVSS 9.6). The July 2026 MCP spec's Enterprise-Managed Authorization going stable helps — but "behind an MCP server" never meant "safe by construction."
Add it up and the catalog has a breakeven point: it pays when verbs repeat often enough that governance value exceeds token rent plus maintenance. Which is exactly why the next section exists.
Where raw API plus prompt still wins
Three concrete cases, each with the condition that flips it back.
1. The novel op outside any catalog. Your agent needs to toggle a provider-specific feature flag, query an obscure billing endpoint, or chain three APIs no tool author anticipated. Building a governed tool means writing the tool, its schema, its description, its permission wiring, and its tests — for a verb that runs once.
Handing the agent scoped credentials plus the API docs in the prompt finishes the job in minutes. Flips when: the op runs a second time on a schedule. The second run is the catalog candidate; the first was reconnaissance.
2. Debugging with the full surface. An agent diagnosing a failed deploy needs to wander: describe this, list that, check an annotation nobody put in the read-model. A narrow read-logs tool returns what its author imagined; raw read access returns what is actually there.
Constraining a debugging agent to a fixed verb list trades away the exact capability you summoned it for. Flips when: debugging ends. Scope the credential read-only, expire it with the session, and never let the debug key become the deploy key.
3. The tiny team where catalog maintenance exceeds risk. Two engineers, one staging cluster, deploys a few times a week: the expected loss from a broad key is bounded by how little there is to break, while the catalog costs the same to build regardless of team size. A scoped key, a short expiry, and a human reading the agent's plan before it executes is proportionate governance. Flips when: a second agent, a production environment, or a teammate who wasn't in the room appears. Any of the three makes "we watched it happen" stop being an audit strategy.
Notice the pattern: raw API wins on frequency zero and team size one. Everything that repeats or scales wants the catalog. That is a decision rule, not a vibe — and it is the rule a deploy-from-chat roadmap should be built on.
The decision rule for deploy-from-chat
If you are building agent-operated infrastructure — Qovery's roadmap, bex's included — the split writes itself:
- The hot path gets narrow governed tools with server-side policy. Deploy, provision-database, create-environment, read-logs, read-cost: the verbs agents call daily, each scoped to one action, each denied by default. Read-only by default with an explicit write switch, policy evaluated per request, every call attributed. This is the standing surface, and it earns its token rent through repetition.
- The long tail gets a scoped, expiring escape hatch. Read-heavy credentials with a short TTL for debugging and novel ops, issued per session, never shared between agents, never reused as standing deploy authority. The escape hatch is governed too — by scope and expiry rather than by verb — which is what keeps it an escape hatch instead of a backdoor.
- Promotion is the workflow. Every escape-hatch op that repeats becomes a tool proposal. The catalog grows from observed demand, not imagined completeness — which also keeps tool counts inside the accuracy budget instead of sprawling past it.
That is what the governed-tool-surface split changes for a self-hosted roadmap specifically: the policy boundary can live in your own control plane on machines you own, with the audit log in your own storage, instead of rented per seat from a vendor plane. The protocol is standard either way; the difference is who holds the enforcement point and the receipts.
The agent holding your API key was never the plan. It was the prototype. Graduate the verbs that repeat, scope the ones that don't, and make every escape-hatch run audition for the catalog.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agent-operated deploys as a first-class surface. Star the repo on GitHub or deploy your first app today.
