Letting AI agents deploy via MCP with typed tools and scoped tokens instead of root

A post on dev.to tackles a gap that has opened up as coding agents matured: they write code well long before they run it safely. When you ask Cursor or Claude to deploy something and check the logs, the easy route is an SSH key or cloud admin token dropped into a config file. The author argues this is exactly how you end up with an agent privileged enough to destroy production data over a misread stack trace, and proposes a different pattern: expose deployment operations through the Model Context Protocol (MCP) and apply the same role-based access control that already governs the human team.

Typed tools instead of an open shell

MCP is a standard way for an AI client to discover and call tools on a server. Instead of improvising shell commands, the agent sees a typed catalog — deploy, restart, list services, read logs, set environment variables — where each tool has a schema and the server decides what each call is allowed to do.

According to the post, this shift matters for three reasons. The capability surface is explicit, so you can read the tool list and know what the agent can do. Authorization lives on the server, which checks a token on every call rather than trusting the client. And tool calls go through the same API as the dashboard, so they land in the same audit logs.

The threat model in practice

The author recommends writing down what you are protecting against before wiring anything up. For most small teams the list looks like this: the agent misunderstands an instruction and touches the wrong service; a credential leaks into a chat transcript or a commit; a prompt injection hidden in a README, issue or log line convinces the agent to do something nobody asked for; or a token issued for testing is never revoked. None of these problems are solved by a smarter model — they are solved by scoping.

A scoping checklist

The post offers rules that hold regardless of platform. Issue per-person, per-workspace tokens and never share one across a team or reuse an admin token for a single-project agent. Let the agent inherit roles rather than inventing them: it should have exactly the permissions of the human who issued the token, or fewer, so a developer restricted to staging produces an agent that hits the same wall. Leave out interactive shells entirely, since shell access can bypass every other control. Treat tokens like passwords, keeping them in the MCP client config or a secret manager and rotating by revoking. And prefer reversible actions — if an agent can deploy, it should also be able to undo its own deploy with one call.

A working example

The author tested the pattern against Peon, an open-source, self-hostable deployment platform whose MCP endpoint is built into the app rather than bolted on as a side script. Setup in Cursor or Claude Desktop is a short config: a streamable HTTP server authenticated with a bearer token. Tokens are created in the dashboard under Keys and Tokens, are scoped to a single workspace, and inherit the creator's role — an owner or admin token can manage servers, while a project member token only reaches that member's projects.

Two design choices are flagged as worth copying even if you build your own server. First, shell exec tools are simply not registered on MCP: the agent can deploy, restart, roll back, read logs and manage environment variables, but it cannot open a shell on a server or inside a container. Second, the same RBAC governs the API, the MCP server and the in-app assistant — the UI is not the security boundary, the API is.

What a realistic session looks like

The post walks through a representative loop: asked which service failed its last deploy, the agent lists services, pulls the failed build's logs, spots a missing DATABASE_URL, explains the fix and asks before applying it. After confirmation it sets the variable, triggers a redeploy and watches the status, rolling back and reporting if health checks fail. Nothing in that loop required root — every step was a typed call the platform could log or deny.

Client-side habits and limits

Server-side scoping is the foundation, but the post adds client-side guardrails: require confirmation for any tool that deploys, deletes or changes environment variables; keep read-only viewer tokens for exploratory sessions; tell the agent explicitly that tool output is data, not instructions, since logs and issue text can carry injected commands; and review the audit trail weekly to catch forgotten tokens.

Agents are also a poor fit for some work regardless of scoping: first-time infrastructure setup, database migrations that risk data loss, billing, DNS for a primary domain, and deleting backups. Those should stay human, or at least human-approved step by step.

Why it matters

As coding agents move from writing software to operating it, the default integration — pasted SSH keys and admin tokens — gives them vastly more privilege than any task requires. MCP combined with existing RBAC offers a least-privilege contract between an AI client and infrastructure: an explicit tool catalog, per-call authorization and a shared audit trail. For teams running their own servers, the post argues this is one of the rare cases where self-hosting makes AI tooling safer rather than riskier, because you control both what the agent can call and who is allowed to call it.