As AI agents move from answering questions to acting on production infrastructure, a pressing security gap has opened for cloud-native teams. Developers are already connecting tools like Claude Code and Cursor to clusters using their own kubeconfigs, and when something breaks, nobody can say exactly what the agent did or cleanly undo it. Ahead of KubeCon + CloudNativeCon North America 2026 in Salt Lake City, VMblog sat down with Neil Cresswell, CEO of Portainer, to discuss how his company is tackling the problem with Portainer-Command, a governed, audited workspace that acts as an MCP gateway between AI agents and Kubernetes. Cresswell’s message is blunt: with Portainer-Command, an AI agent never holds a credential that can change your cluster.
In this wide-ranging conversation, Cresswell explains why Portainer treats every agent as potentially hostile, how expiring read-only sessions and Git pull requests approved by a named person replace risky write access, and why he believes “AI scale” is about the number of agents acting on a platform rather than tokens per second. He also previews Portainer’s full AI line-up, including Portainer-Run, Portainer-AiGrid and Portainer-IDP, outlines the live prompt-injection demo attendees can try at booth 250, and shares the questions every CISO should ask before letting an agent touch a cluster.
++
VMblog: What’s your elevator pitch for KubeCon + CloudNativeCon North America 2026? If attendees only remember one thing about your company after visiting your booth, what should it be?
Neil Cresswell: The way the industry is giving AI agents access to Kubernetes is 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.
Portainer-Command is a better way. It’s a governed, audited workspace where developers use AI agents manage the clusters and application workloads using whatever AI harness they choose. Agents get temporary, auto expiring read-only sessions, and if they want to make changes, those change are intercepted and captured as a Git pull request, which a named person approves before GitOps applies it.
If attendees remember one thing: with Portainer-Command, an AI agent never holds a credential that can change your cluster.
VMblog: CNCF has introduced a brand-new “AI Inference + Agentic” track for 2026, covering GPU scheduling, model serving, and observability for production AI systems. Where does your company fit into that conversation, and what’s driving your investment there?
Cresswell: We sit firmly on the agentic side of that track. We don’t build schedulers or inference servers. Portainer-Command addresses what happens when an agent stops answering questions and starts acting on a cluster.
That shift is already under way. Developers are connecting Claude Code, Cursor and other MCP clients to clusters using their own kubeconfigs. Most agentic ops tooling assumes the agent holds credentials that can change the cluster, and that is usually where the CISO conversation ends.
Our investment is driven by a gap we kept seeing: nothing sat between the agent and the cluster. Portainer already owns RBAC, GitOps and audit for Kubernetes fleets, so building the control plane that turns an agent’s read into a supervised, expiring session and its write into a proposal for a person to approve was a natural extension.
VMblog: Let’s get technical — what specific architectural challenges or operational bottlenecks does your solution address for cloud-native teams heading into 2027?
Cresswell: Portainer-Command addresses three problems that appear the moment agents touch Kubernetes.
Agents holding write credentials. In Portainer-Command, an agent’s only access is a read-only kubeconfig scoped to one environment and the namespaces an administrator opened. It points at Portainer’s proxy, not the API server, so every request passes Portainer’s RBAC. It requires a stated rationale and expires on a TTL: one hour by default, eight at most.
No safe write path. The agent commits to a synthetic, per-environment copy of the repo and never holds a real Git credential. Portainer-Command validates the push for paths, file types and size, then opens a pull request against its own GitOps repository under the identity of the human who set the task. A named person approves; GitOps reconciles. There is no other write path, so the agent can’t merge its own change or bypass GitOps.
No audit trail or undo. Every session, proposal and applied change carries a named identity. Each session records the Kubernetes service account it used, so cluster audit logs join back to a person. Because state history is Git history, any change can be reverted and an environment rebuilt from the repo.
Portainer-Command runs alongside existing pipelines and Argo CD or Flux, using its own GitOps repository, so teams can start with new services or a non-production environment without touching what’s already in production.
VMblog: The industry narrative has shifted from “Kubernetes for web scale” to “Kubernetes for AI scale.” How has your technology evolved to meet that shift, particularly as inference is projected to overtake training as the dominant AI compute workload?
Cresswell: We read “AI scale” differently from the GPU vendors. The scale problem we see in enterprises isn’t tokens per second. It’s the number of AI agents suddenly acting on the platform, each one an identity that needs permissions, approval and an audit trail.
Portainer’s evolution has been to treat agents as governed actors rather than as users borrowing someone’s kubeconfig. Our core platform already handled RBAC, GitOps reconciliation and audit across cloud, on-prem, edge and air-gapped clusters. Portainer-Command extends that model so every agent session and proposal carries a named human identity and lands in the same trail.
On inference itself, Portainer-Command’s built-in workspace runs against a model endpoint the customer supplies, either OpenAI-compatible or Claude-compatible, including one hosted inside their own boundary. Model choice and data residency stay with the customer, wherever their inference runs.
VMblog: Where does your solution fit within the modern cloud-native stack? How do you integrate with and complement projects like vLLM, KServe, Ray, and OpenTelemetry that are anchoring the new AI Inference + Agentic track?
Cresswell: Portainer-Command sits between AI agents and the cluster, as an MCP gateway. vLLM, KServe and Ray are workloads; Portainer-Command governs how an agentis allowed to deploy, change or inspect workloads like them. We don’t ship purpose-built integrations for vLLM, KServe or Ray.
Where it connects directly:
MCP. Portainer-Command exposes an MCP server any MCP-compatible client can use, including Claude Code, Cursor and custom agents. Unlike a bare MCP server that exposes kubectl-style tools, sessions carry identity and a TTL, writes go through Git and every action is audited.
Model endpoints. The built-in OpenCode workspace runs against an OpenAI-compatible or Claude-compatible endpoint the customer supplies. That can be a self-hosted model served inside their own boundary.
GitOps. Every change is a pull request against Portainer-Command’s own GitOps repository, reconciled by GitOps. It runs alongside Argo CD or Flux rather than replacing them.
Policy and networking. Enforcement is delegated to systems teams already run: admission control (Pod Security Admission, Kyverno or Gatekeeper),branch protection on the Git repository and a CNI that enforces Network Policy.
OpenTelemetry. Portainer Business’s Observability Policy can deploy and manage an OpenTelemetry Collector on each attached environment, so agent-deployed workloads are observed the same way as everything else.
VMblog: Agentic AI workflows are emerging as a new class of Kubernetes workload, with autonomy and orchestration requirements that differ from traditional services. How is your platform adapting to support these agentic systems?
Cresswell: We start from one assumption: treat the agent as potentially hostile/rogue. A prompt-injected agent is the most realistic attacker on a cluster, because anything it reads in a pod log, manifest or annotation can carry instructions. Telling the model to behave is not a control.
Portainer-Command is built on that assumption. It acts as an MCP gateway between the agent and the cluster, and every interaction follows the same loop:
- A developer sets a goal for the agent.
- The agent requests a read-only session for one environment, with a rationale and a TTL, pointed at Portainer’s proxy rather than the Kubernetes API server.
- The agent proposes a change by committing to a synthetic, per-environment copy of the repo. It never holds a real Git credential.
- A named person reviews the pull request and approves it. The agent cannot merge.
- Portainer Business reconciles the approved change into the cluster.
Around that loop, administrators decide per environment whether agents may read live state, read GitOps state or propose changes. A typical setup is open reads in dev, propose-only in staging and blocked in production. Secret access is off by default. A one-click halt per environment or per user ends every live session without deleting the record. We also publish a threat model that names where Portainer-Command cannot protect you on its own and what compensating control to use.
VMblog: Platform engineering continues reshaping how organizations approach cloud-native infrastructure. What’s your perspective on this shift, and how does your technology enable effective platform teams and internal developer platforms?
Cresswell: Platform engineering is about giving developers self-service inside guardrails. AI agents are now part of that self-service, whether the platform team planned for it or not. Developers will use agents to deploy and debug; the question is whether that happens through the platform or around it.
Portainer-Command brings agents inside the platform. Administrators set guardrails once, per environment: whether agents may read live cluster state, read GitOps state or propose changes, which namespaces they can see and whether Secret access is on. A typical setup is open reads in dev, propose-only in staging and blocked in production. Developers get an agent that can actually do work; the platform team keeps every change in Git and every action in one audit view.
It also fits the platform team’s existing contract with developers. Proposals arrive as pull requests, branch protection can require a second reviewer or passing checks, and admission policy limits what a merged manifest can do. Teams can use their own MCP client or a built-in workspace that runs in a sandbox the platform team controls.
VMblog: Multi-cloud and hybrid strategies are now table stakes, and GPU capacity is often the scarcest resource across those environments. How does your solution help organizations navigate distributed, heterogeneous infrastructure — including accelerator availability?
Cresswell: Portainer Business already manages Kubernetes across public cloud, on-prem, edge and air-gapped sites from one control plane. Portainer-Command inherits that reach, so one set of agent policies covers the whole fleet rather than one cluster at a time.
Portainer-Command doesn’t place GPU workloads; that belongs to the Kubernetes scheduler. What it does is make sure any agent deploying to scarce, expensive capacity does so through an approved pull request, under a named identity.
VMblog: Security, compliance, and governance remain top concerns, especially as AI systems introduce new supply chain and runtime risks. What’s your approach to helping organizations build secure, compliant cloud-native systems without sacrificing velocity?
Cresswell: We put controls in the architecture rather than in instructions to the model. Portainer-Command assumes the agent may be hostile, because a prompt-injected agent is the most realistic attacker: anything it reads in a pod log, manifest or annotation can carry instructions. The design bounds what a fully hijacked agent could do to two things: read what its person can read, and open a pull request a person has to approve.
In practice:
- No real Git credential, ever. Agents clone a per-environment view containing only that environment’s directory. Pushes are validated, and pushing to the deploy branch is refused.
- Secrets off by default, and measured. With Secret access off, an agent can’t read Secret values or even list their names. Where Portainer’s own role bindings still expose Secrets, Portainer-Command reports exactly which namespaces remain readable.
- Isolated workspace. The built-in workspace has no inbound ports, runs unprivileged on a read-only root filesystem, and reaches only Portainer, the model endpoint and domains you approve, enforced by Network Policy and an egress proxy.
- Evidence that survives. Records persist after revocation, and emergency halts end sessions without deleting anything.
We publish a threat model covering each attack, what stops it and where a compensating control is needed. Velocity comes from that clarity: security approves the path once, and developers use agents without waiting on a review for each one.
VMblog: As we head toward 2027, what’s your unique value proposition? With dozens of vendors claiming similar AI-infrastructure capabilities, why should CTOs choose your solution?
Cresswell: Most AI-infrastructure vendors are selling capacity. Portainer-Command sells permission: the ability for a CISO to say yes to agents on Kubernetes because the guarantees are structural, not procedural.
Three things set it apart:
- The agent never holds a write credential. Not to the cluster and not to Git. Enforcement lives in Portainer’s RBAC and the GitOps repository’s rules, not in the model’s instructions.
- GitOps Centric. Any change the agent proposes is automatically a PR, and every approved PR is reconciled into the cluster via GitOps, period.
- Low-risk start. It runs independently of existing pipelines, so teams begin with new services or a non-production environment and nothing in production has to change.
We also show our work. The published threat model lists where Portainer-Command can’t protect you on its own and what to put in place instead. We think that’s what CTOs should expect from any vendor asking to sit between AI and production.
VMblog: Are you launching any new products, unveiling significant features, or announcing partnerships at KubeCon NA 2026? What should attendees watch for?
Cresswell: KubeCon Salt Lake City is the first North American KubeCon where we’ll show our full AI line-up together:
- Portainer-Run, the governed landing zone for AI-built business apps, with direct MCP deploy from Claude Desktop, ChatGPT Desktop and Cursor, plus an offramp for apps already running on Lovable, Bolt or Replit.
- Portainer-Command, a governed workspace where developers use AI agents on Kubernetes. Agents get expiring read-only sessions and propose every change as a pull request. It works with any MCP client or with a built-in workspace that runs against a model endpoint the customer chooses.
- Portainer-AiGrid, a self-hosted retrieval platform that builds a private, citable index from your documents using idle workstations out of hours.
Alongside them, attendees can see Portainer-IDP, our no-cost internal developer portal for Portainer Business customers, which is where AI-built apps graduate once engineering takes ownership.
VMblog: Give us your executive pitch — how do you articulate ROI and business value to C-suite leaders who need to justify cloud-native and AI infrastructure investments?
Cresswell: AI agents can take real work off engineering teams: deploying services, auditing configuration, reviewing security posture. Most organizations aren’t capturing that value because the only way to give an agent access today is a credential nobody wants to sign off on.
Portainer-Command turns that blocked decision into an approved one. Developers get agents that do real work on Kubernetes. Security gets read-only sessions, human approval on every change, a full audit trail and a one-click halt. And because every change is in Git, a bad change costs a revert rather than an incident review. The ROI is the agent productivity you were already paying for in model spend but couldn’t safely use.
VMblog: FinOps and cost optimization have become even more critical as GPU spend joins cloud spend under scrutiny. How does your solution help organizations maximize efficiency and control costs across both traditional and AI workloads?
Cresswell: Agent spend is the new line item most teams can’t see. Portainer-Command tracks token spend per workspace, rolled up per user and per organization, with30-day cost trends across the fleet. A runaway pattern shows up before the invoice does, and a per-user halt stops a workspace immediately. The hard cap belongs on the provider key, so we recommend giving Portainer-Command a dedicated, spend-limited key.
On infrastructure, the control is approval. An agent can’t scale up a deployment or claim expensive capacity on its own; it proposes the change, and a person decides.
VMblog: What is an MCP gateway, and why does Kubernetes need one?
Cresswell: An MCP gateway, or agentic control plane, sits between AI agents and the systems they act on. A bare MCP server for Kubernetes typically exposes kubectl-style tools with whatever credentials it was given, which means the agent effectively holds those credentials.
Portainer-Command is an MCP gateway built specifically for Kubernetes. Agents connect over MCP, and the gateway issues expiring read-only sessions with a stated rationale, brokers change proposals as Git pull requests, and lets Portainer reconcile only what a person approved. The agent gets enough access to be useful and none that can change the cluster.
VMblog: What should a CISO ask before letting an AI agent touch a Kubernetes cluster?
Cresswell: Four questions:
- Does the agent hold any credential that can change the cluster? It shouldn’t.
- Can every change be traced to a named person who approved it?
- Can I allow agents in dev and block them in production, per environment?
- If the agent is prompt-injected tomorrow, what’s the worst it can do, and can I cut it off in one click?
If a vendor’s answer to the first question relies on instructions to the model rather than on architecture, keep asking. We designed Portainer-Command so all four have structural answers, and published a threat model so security teams can check our work.
VMblog: Where exactly can attendees find you on the showfloor at the Salt Palace Convention Center, and what’s the one must-see demo or experience you’ve built that showcases your technology’s real-world impact?
Cresswell: You’ll find us at booth 250.
The must-see demo is a prompt-injected agent meeting Portainer-Command. We’ll point an agent at a live cluster, feed it a malicious instruction hidden in a pod annotation, and show what it can actually do: read what its user can read, and open a pull request that a person has to approve. Then we hit the emergency halt and show the session timeline that ties every action back to a named person.
VMblog: Walk us through your booth strategy — what interactive elements, live demonstrations, or hands-on experiences will help attendees truly understand your solution’s differentiation?
Cresswell: The booth is built around Portainer-Command running on real Kubernetes, with two seats at every demo: the developer’s and the CISO’s.
- The developer seat: connect Claude Code or Cursor to Portainer-Command, give the agent a goal, and watch it request a read-only session, propose a change and wait. Then approve the pull request yourself and see Portainer apply it.
- The CISO seat: the administration view. Set per-environment permissions so agents can read in dev but are blocked in production, review the session timeline and token spend, roll back a change from Git history, and use the one-click halt.
- Attack the agent: the prompt-injection demo described above, for anyone who wants to try breaking it.
VMblog: Looking beyond KubeCon NA 2026, what emerging trends or technologies should cloud-native practitioners be preparing for? What’s on your company’s innovation roadmap that signals where the industry is heading?
Cresswell: Prepare for agents becoming routine operators. The question is no longer whether agents touch production but under what identity, with what approval and with what audit. We expect MCP gateways and agentic control planes to become as standard a part of the Kubernetes stack as ingress controllers.
Two practical steps teams can take now. First, inventory how agents reach clusters today: if the answer is developers’ personal kubeconfigs, that’s the first thing to fix. Second, get admission control, Network Policy enforcement and branch protection in place, because any serious agent governance will lean on them.
On our roadmap, Portainer-Command manages its own workloads through its own GitOps repository today, and we’re working on extending it to applications customers deploy from their own repositories through Portainer GitOps.
##
