
Octopus Deploy Remote MCP: Agents Can Now Ship Releases
Enterprise Developer PlatformsAn AI agent can now create a release in Octopus Deploy, promote it through the lifecycle, and run a runbook, all through one endpoint built into the server. Octopus announced a remote MCP server on October 13 that replaces the per-machine local server, and it brings write access along with read. For platform teams, the convenience is real, but the controls that would limit what an agent can deploy are still on the roadmap.
What Happened
Octopus says the remote server means “there’s nothing to install or maintain”: agents point at the instance’s /mcp endpoint over HTTPS. Before this, each user ran a local MCP server on each machine and kept it updated. The remote server is live on Octopus Cloud now and comes to self-hosted Octopus Server in the 2026.3 release. Nineteen users had voted for it on the public roadmap.
The first tool set covers selected core features:
- Orientation: find spaces, projects, tenants, and tenant tags.
- Deployment questions: whether a pull request has deployed, when a release reached a tenant or environment, and lifecycle rules.
- Deploy and operate: create and deploy releases, promote them, run runbooks, and generate and attach release notes.
- Investigation and audit: search task logs, processes, and variables; list failed or queued tasks; query audit events and report on deployment health.
The setup documentation shows the structure underneath. A few dedicated tools such as find_projects sit alongside generic contract tools: search_contracts and describe_contract find and inspect an API contract, execute_query handles reads, and execute_command handles changes. Authentication today is an API key in the X-Octopus-ApiKey header. The docs give a Claude Code example, and “OAuth authentication flow is planned for a future release.” The local server stays available but won’t get new features.
Why It Matters
The permission model is simple: the server sits inside the REST API’s security boundary, and “user permissions still apply the same way.” An agent can do whatever its key’s owner can do. The docs don’t describe a read-only mode or a way to disable only execute_command. Admins can turn remote or local MCP off entirely under Configuration, Settings, MCP Controls, and the docs warn that a rogue agent could spoof the user agent string used to block local MCP.
Octopus is upfront that governance is unfinished. Its roadmap list includes scoped API keys, OAuth, policies that know whether an agent started a deployment, and audit log filtering for agent events. Stack Archive covered a similar move when CircleCI shipped a remote MCP server.
What This Means for Platform Teams
Until scoped keys ship, the key you hand an agent sets its blast radius. Octopus recommends an Agent API key with custom scopes or a dedicated Agent Service Account, which also makes agent actions identifiable in the audit log. Because user permissions carry over, a service account limited to read-only roles should be able to use the investigation and audit tools without being able to promote anything.
The So What
Platform teams on Octopus Cloud should enable remote MCP through a dedicated agent service account, start it with read-only permissions, and grant deploy rights per environment only after reviewing what agents ask for in the audit log. Teams that need agents out of production entirely should keep MCP disabled in MCP Controls until scoped keys and agent-aware policies arrive.
Source: Octopus Deploy Blog
Content created with AI assistance and reviewed for accuracy.
Join the conversation
Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.
Join Stack Insiders →