In November we shipped an MCP server at mcp.cpln.io. Connect any MCP-aware AI agent — Claude, Cursor, Codex, Gemini — and it can operate the full Control Plane platform from natural-language prompts.
We’ve followed that up with releasing an AI Plugin that includes the MCP server along with skills, agents, slash commands, and guardrails.
This post will answer what these two changes let an agent do, what does that unlock for an enterprise, and what keeps an AI agent acting on production infrastructure from doing something it shouldn’t.
AI agents and Control Plane, by level
Control Plane exposes infrastructure at multiple levels of abstraction. The MCP server reflects all of them — the agent can work at whichever level the prompt expresses, not just a small set of high-level “deploy a thing” actions.
Discovery and observation
“What workloads are running? Which Global Virtual Clouds (GVCs) do we have? What’s our spend by location for the last 30 days? Who has admin access to the production GVC? When did this workload last change, and by whom?” The MCP server exposes the full read surface — the audit trail, billing data, identity model, and resource catalog — all queryable in natural language.
Composition
“Create a GVC called ‘staging’ with locations in aws-us-east-1, gcp-europe-west1, and our on-prem datacenter. Set up a Universal Cloud Identity that can read from BigQuery in GCP and write to SQS in AWS.” The agent isn’t picking from a fixed menu of templates — it’s composing the environment from primitives: locations, identities, policies, and the connections between them. Universal Cloud Identity is Control Plane’s patented identity layer that lets a workload in one cloud reach a service in another without embedded credentials, and the agent can configure those bindings directly.
Workload deployment
“Deploy this container with 512MB memory, 500m CPU, a public endpoint, in all three locations. Add autoscaling on CPU and request rate, scale-to-zero on idle.” A single prompt covers image selection, resource sizing, autoscaling configuration, networking, and service-mesh placement.
Cloud services
“Provision a Postgres from the template catalog in the same GVC. Connect this workload to it.” Native open-source services deploy onto the customer’s own infrastructure and get wired into the workload without the agent ever touching credentials.
Day-2 operations
“Mirror 100% of production traffic to the staging workload so we can shadow-test v2. If error rate stays below 0.1% for an hour, tighten Capacity AI’s update cadence on production.” Domain mirroring, autoscaler tuning, rollouts, identity rotation, secret management — the agent operates the same surfaces a senior engineer would. Capacity AI is the platform’s continuous right-sizing system, and the agent can read or modify its behavior per workload.
Cross-cloud operations
“This workload in aws-us-east-1 needs to read from a BigQuery dataset in GCP. Configure the identity binding.” Universal Cloud Identity handles the cross-cloud auth; the agent expresses the intent, not the credential plumbing.
Output and reproducibility
“Export the manifests for everything you just built.” The agent emits the configuration so the change can be reviewed, committed to version control, and re-applied later — by a human, by CI, or by a different agent.
Why this compresses an enterprise’s AI-readiness cycle
For the last year, boards have been asking “why aren’t we using AI?” For most enterprises, the honest answer is: because their infrastructure isn’t AI-ready. The estate is fragmented across acquisitions, multiple cloud accounts, on-prem datacenters, and legacy systems. The surface is too sprawled and too inconsistent for an agent to operate against safely or coherently.
The traditional path to AI-ready has been a multi-quarter platform-engineering program: consolidate identity, build a unified audit trail, standardize deployment, define policy at scale, give the agent a coherent surface to act on. It takes longer than the board’s patience.
Control Plane shortcuts that program because of what the platform is. Any AWS account, any GCP region, any existing managed Kubernetes cluster (EKS on AWS, GKE on GCP, AKS on Azure), any SSH-accessible Linux box becomes a region of one AI-native virtual cloud. The sprawl gets a single identity layer, a single audit trail, a single deployment surface.
The MCP server is the AI-facing half of that. Once the estate is virtualized, the agent has a coherent surface to act against. The Control Plane agent plugin adds important guardrails to those actions. The cycle from “we should be using AI” to “our agents are safely operating production infrastructure” compresses from quarters to weeks.
How agent operations stay deterministic and guardrailed
AI agents in infrastructure are a category of risk worth taking seriously. Generated code that’s almost-but-not-quite correct. Agents that hallucinate cloud resources or service names. Irreversible operations the agent didn’t fully understand. The Control Plane agent infrastructure is designed to contain that risk by construction, not by hoping the model behaves.
Operations are deterministic, not generative
Every MCP action is a defined API call against the platform with a known input shape and a known outcome. The agent isn’t writing infrastructure code that might be wrong — it’s invoking operations the platform has tested. There’s no “the agent generated a configuration file that referenced a nonexistent resource and applied it” failure mode, because the agent isn’t generating the code that talks to the cloud in the first place.
Agents inherit the platform’s identity and policy model
Agents authenticate with the same identity system humans do. An agent’s identity carries explicit permissions; it can do exactly what those permissions allow and nothing more. The same role-based access control that prevents a human from dropping production prevents an agent from doing the same.
Same audit trail, same attribution
Every agent action is logged in the same tamper-proof audit trail the platform maintains for humans, attributed to the agent’s identity. Reviewable, compliance-friendly, indistinguishable in structure from a human-initiated change. Auditors don’t need a different process for AI activity.
Read-before-write is the natural pattern
Agents can describe what they intend to do, return the plan, and only execute on confirmation. The MCP server’s discovery operations make this trivial — agents pull current state, describe intended state, and the operator stays in the loop on consequential changes.
Reproducibility is built in
Anything an agent builds can be exported as a manifest, committed to version control, reviewed, and re-applied.
Smaller surface, smaller context
Because the agent calls atomic, well-defined operations rather than writing files of code, the context it needs is small, the tokens it burns are few, and the surface area for hallucination is narrow. The platform itself is the context the agent reasons over, not a pile of YAML it has to author from scratch.
Sandbox patterns are cheap
Spin up a separate GVC for the agent to work in, give it a constrained identity, watch what it does, then promote the working configuration to production. The cost of an extra GVC is small compared to the cost of an agent doing something irreversible to a real one. For high-stakes work, this is the recommended pattern, and Control Plane makes it easy.
Try it
Connect your AI agent to mcp.cpln.io using your Control Plane API key. Or install our AI Plugin and explore usage examples.
Further reading
• AI agents on Control Plane (docs)