Give AI agents governed access to your Kubernetes platform
The safe way to put AI to work on your Kubernetes fleet.
The way the industry is granting AI agents access to Kubernetes is embarrassingly insecure; agents are handed personal credentials and pointed at production clusters, and when something breaks nobody can say exactly what the agent did or cleanly undo it, so we built a better way. Portainer-Command is the MCP gateway between the agent and the cluster; agents get expiring read-only sessions with a stated rationale, and every change arrives as a Git pull request that a person approves before Portainer applies it.
- MCP gateway and agentic control plane sitting between AI agents and Kubernetes
- AI agents never hold a credential that can change a cluster, and never hold a real Git credential
- Read-only sessions are scoped to one environment, carry a stated rationale, route through Portainer's proxy, and expire on TTL
- Every change becomes a Git pull request; a named person approves, GitOps applies, and any change can be rolled back if something goes wrong
- Every session, proposal, and applied change carries an audited identity
The piece the market did not have
Most agentic AIOps approaches today assume the AI agent holds credentials that can change the cluster. That is where the CISO conversation ends. The missing element is the piece between the AI and the cluster: a control plane that turns the AI's read into a supervised, expiring session, and turns the AI's write into a proposal for a person to approve.
The direct answer
Portainer-Command is that missing box. AI agents connect to Portainer-Command's MCP server; the server issues read-only sessions with a rationale and TTL, receives change proposals, opens Git pull requests for them, and lets Portainer Business reconcile approved changes. The agent never holds a credential that can change a cluster, and never reaches the Kubernetes API server directly; every read passes through Portainer's proxy and Portainer's RBAC.
The core loop, in five steps
Every AI agent interaction with Kubernetes runs the same five-step loop. There is no side door.
Human sets a goal
A developer tells the agent what to do (deploy this, audit that, review the security posture).
Agent requests read
A read-only credential for one environment and the namespaces you opened, with a stated rationale. It points at Portainer's proxy, never the API server, and expires on TTL (one hour by default, eight at most).
Agent proposes change
The agent commits to a synthetic, per-environment copy of the repo and never touches the real one. Portainer-Command validates the change, then opens the pull request against your sanctioned repo, carrying the human's identity as the proposer.
Human reviews + approves
A named person reads the diff and approves. The agent cannot merge. Where you need a second reviewer or passing checks, your repository's branch protection enforces it.
Portainer applies
Portainer Business reconciles the merged change into the target cluster. Full rollback available via Git history.
The reason CISOs sign off
The convenience side of Portainer-Command (the workspace, the prompt library, the chat surface) is what makes it usable day-to-day. The administration side is what makes it sellable. Every AI action across the fleet is visible in one place, and every environment has its own controls.
Per-environment controls
Allow AI in dev, block it from prod
Administrators grant or deny agent access per environment, choosing separately whether an agent may read live cluster state, read the GitOps state, or propose changes. Namespace scoping is set the same way, and Secret access is its own switch, off by default.
Full session timeline
Every AI action, every user, one view
A single dashboard shows every AI proposal, every read session, and the rationale that opened it. Records survive revocation, and each session records the Kubernetes service account it used, so your cluster audit logs join back to a named person.
Emergency halt
One click cuts agents off
Halt an environment when you know where the problem is; it switches off agent access and ends every live session there. Halt a user when you know whose agents are the problem; it revokes their connections, ends their sessions everywhere, and stops their workspace. Nothing is deleted, so the evidence stays.
Token spend visibility
Cost per workspace, rolled up per user
Portainer-Command tracks model spend across workspaces over a 30-day window, per user and organization. A misbehaving workspace can be halted; a runaway pattern shows up before the invoice does.
Environment history
Roll back to a previous state
Every change is a Git commit, so state history is Git history. Roll back to an earlier point or revert a specific proposal; the cluster state follows.
Structural, not procedural
Guarantees the architecture makes
AI cannot merge its own changes because it holds no credential that can. AI cannot bypass GitOps because there is no other write path. Enforcement lives in Portainer's RBAC and your repository's rules, not in instructions to the model.
Assume the agent is hostile
A prompt-injected agent is the most realistic attacker; anything it reads in a pod log, manifest or annotation can carry instructions it may follow. Trusting the model to behave is not a control, so Portainer-Command bounds what a fully hijacked agent could do: read what its person can read, and open a pull request that a person has to approve.
Synthetic Git
No real Git credential, ever
Agents clone a per-environment view of your repository that contains only that environment's directory; nothing outside it exists to fetch. Pushes are validated for paths, file types and size before anything reaches your real repository, and pushing to the deploy branch is refused. Only Portainer-Command authenticates to the real repository, when it opens a pull request.
Secrets
Off by default, and measured
With Secret access off, an agent cannot read Secret values or even list their names. Where Portainer's own role bindings still expose Secrets (typically the default namespace), Portainer-Command checks every namespace after issuing a credential and reports exactly where they remain readable, so you close the gap rather than trust an assumption.
Workspace isolation
Choose where a workspace can reach
The built-in workspace has no inbound ports and runs unprivileged on a read-only root filesystem. Administrators pick a network mode: allow some (the default) reaches Portainer, the model endpoint and a list of domains you approve; block all reaches only Portainer and the model endpoint. Both are enforced by NetworkPolicy and an egress proxy.
Read the threat model
We publish what an attacker could try, what stops each attempt, and where Portainer-Command cannot stop it on its own, with the compensating control for each. Download the threat model.
Bring your own agent, or use the built-in workspace
Portainer-Command exposes an MCP server that any MCP-compatible client can connect to (Claude Code, Cursor, and others). It also ships a built-in headless OpenCode workspace that administrators can enable, giving users an AI environment inside Portainer without adopting an external AI client. Both paths run the same governed loop underneath.
The workspace is also the more secure path. An agent on a developer's laptop can find whatever credentials that laptop holds; a workspace runs in a sandbox you control, holding only the access Portainer-Command grants it. It also helps with data sovereignty, because it runs against a customer-supplied AI endpoint (OpenAI-compatible or Claude-compatible), so the model provider is your choice and the traffic is on your account.
The full walkthrough
A ten-minute demo covering the workspace, the proposal workflow, the security-hardening example, the prompt library, and the administration view CISOs care about.
Portainer-Command, answered directly
What is an MCP gateway?
An MCP gateway (or agentic control plane) sits between AI agents and the systems they act on. Portainer-Command is an MCP gateway specifically for Kubernetes: AI agents connect over MCP, the gateway issues expiring read-only sessions with a rationale, brokers change proposals as Git pull requests, and lets Portainer reconcile approved changes. The agent never holds a credential that can change a cluster.
Is Portainer-Command an MCP server for Kubernetes?
Yes. Portainer-Command exposes an MCP server that any MCP-compatible client (Claude Code, Cursor, custom agents, and others) can connect to. Unlike a bare MCP server that exposes kubectl-style tools, Portainer-Command is also a governance layer: sessions carry identity and TTL, writes go through Git, and every action is audited.
Does Portainer-Command give AI agents direct access to Kubernetes?
No. An agent can request a read-only session, which gives it a kubeconfig scoped to one environment and the namespaces you opened, pointing at Portainer's proxy rather than the API server, so every request passes Portainer's RBAC. The session expires on its own, and revoking it deletes the account behind it. Agents have no write path to a cluster; they propose changes as pull requests, and Portainer Business applies approved changes via GitOps reconciliation.
What happens when a proposal is approved?
The pull request merges to your sanctioned repo, and Portainer Business reconciles the change into the target cluster as a GitOps stack. The change carries the identity of the human who approved it, and everything is auditable via the Git history and the Portainer session log.
Can AI agents approve their own changes?
No. The agent holds no credential that can merge, and a proposal deploys only after a named person approves it. That person can be the one whose agent opened the proposal; where you need a second reviewer or passing checks before a merge, require them with branch protection on your repository, and Portainer-Command inherits those rules. Users without the right to merge their own proposals can escalate to a colleague for review.
How does emergency halt work?
There are two one-click halts. Halting an environment switches off agent reads and proposals for every agent and ends every live session held against it; the credentials stop working in the cluster immediately. Halting a user revokes their connections, ends their sessions across every environment, and stops their running workspace. Neither deletes anything, so connections, sessions and proposals stay on the record as evidence. If you need to go further, Portainer itself can shut down the add-on or delete the session accounts directly, without depending on Portainer-Command.
How long do read-only sessions last?
Sessions require a stated rationale to open and expire on TTL, one hour by default and eight hours at most, with expired access removed every minute. Agents are also set up to release a session when their task is done. Administrators see every open session and can revoke any of them at any time.
Can we allow AI in dev clusters but block it from production?
Yes. Every environment has its own controls for whether agents may read live state, read GitOps state, or propose changes, and namespaces can be restricted within an environment. A typical configuration is unrestricted read in dev, propose-only in staging, blocked entirely in production.
Whose identity does a proposal carry?
Every proposal is opened under the identity of the human user who initiated the task. Pull requests show that user as the proposer in Git, and the Portainer session log records the agent, the user, and the session together.
Does Portainer-Command work with any AI agent?
Yes. It exposes an MCP server that any MCP-compatible client can connect to (Claude Code, Cursor, and others). Portainer-Command also ships a built-in headless OpenCode workspace for organizations that want to give users an AI environment without adopting an external AI client.
What is the built-in workspace?
A headless OpenCode container hosted inside a namespace administrators designate. Users can spin one up on demand, chat with it, and it runs the same governed loop against Kubernetes as any external MCP client. Model selection is set by the administrator against a customer-supplied API key, either OpenAI-compatible or Claude-compatible, and the administrator chooses the network mode that decides what the workspace can reach.
Can we cap what AI agents cost?
You can see spend and stop it. Portainer-Command tracks token spend per workspace and rolls it up per user and per organization, with cost trends across the fleet over the last 30 days, and a per-user emergency halt stops a workspace that is running away. The hard cap belongs on the provider key itself: give Portainer-Command a dedicated key with a spend limit set at the provider. Workspace image and model configuration is controlled by administrators, not by end users.
Where does the audit trail live?
Two places, both yours. Git holds the full history of proposals and merges. Portainer-Command holds the session log: which agent, which user, which rationale, which environment, which duration. Records survive revocation, and each session keeps the Kubernetes service account subject it used, the same string your cluster audit events carry, so cluster-side logs join back to a named person.
Does customer data leave our environment?
Portainer-Command itself runs inside your Kubernetes platform, but everything an agent reads becomes model context, and the model runs wherever its provider runs. A workspace calls the AI provider endpoint you configured, using your API key, on your account; an external agent uses whatever provider its owner chose. That makes the namespaces and Secrets you open to agents your data-residency controls, because nothing outside an agent's scope can reach a provider through it. If model traffic must stay inside a boundary, use a customer-hosted OpenAI-compatible or Claude-compatible endpoint with the built-in workspace.
What do we need to have in place?
Portainer-Command delegates enforcement to systems you already run, so their configuration matters. Use a CNI that enforces NetworkPolicy, since workspace isolation depends on it; set branch protection on your GitOps repository if you want two-person review; run admission control (Pod Security Admission, Kyverno or Gatekeeper) so a merged manifest cannot do more than your policy allows; and give Portainer-Command a dedicated, spend-limited model provider key. The threat model covers each of these in detail.
See it govern AI agents on a live cluster
We will run a live demo of Portainer-Command against a governed Kubernetes environment, walk through the CISO administration view, and show what standing it up in yours looks like.
- Live demo on a real Kubernetes environment
- No obligation · a specialist will reach out to schedule
- Built on Portainer Business, trusted by 500,000+ users