Coding agents can already write the app. The next step is letting them deploy it. That is useful, and risky if you give an agent an SSH key to production.
Principles that keep it safe#
Least privilege. An agent that only needs to redeploy one staging service should not be able to delete a database. Scope access to a project, not the whole account.
A narrow interface. Instead of raw shell access, expose a small set of operations: list services, view logs, trigger a deploy, restart, read status. The Model Context Protocol (MCP) is a standard way to describe such tools to an agent.
Audit everything. Every action should be recorded with who, what and when, including actions made through an agent. If an agent does something odd, you want a trail.
Human approval for destructive actions. Deleting data or changing domains should require a person.
Separate environments. Give agents staging first. Promote to production through a normal review step.
What to look for in tooling#
- Tokens that can be scoped and revoked
- Role based permissions that apply to agents the same as people
- Logs of tool calls
- Rate limits and clear errors, so agents do not loop
A sensible rollout#
Start read only: agents can fetch logs and status to help debug. Then allow deploys on staging. After a few weeks of reading the audit trail, decide whether production deploys should be allowed behind an approval.
The details of how a hosted MCP server fits with project permissions are in the MCP documentation, and there is a narrative walkthrough in using AI agents to deploy apps with MCP.
Disclosure: I work on Peon, which ships a hosted MCP server under the same permissions as its dashboard.
Comments
No comments yet. Start the conversation.