Solutions · Cloud and Kubernetes
Host control on Linux clusters you operate.
If the agents run on Linux you own, the host envelope is the same product. The Kubernetes-shaped questions — DaemonSet install, per-pod egress, multi-cluster operation — are labeled for what has actually been proven.
If the workload runs on Linux you own and enroll, Phantom Engine's host control applies, and Optics still works on the supported application paths inside those pods or nodes. The Helm DaemonSet and Linux daemon install paths are documented, and per-pod scoped egress control is implemented.
Operating this across multiple nodes or multiple clusters, on infrastructure Vantio does not run, has not been proven. That is the honest edge of the Kubernetes story today.
What you are actually trying to do
Agents in Kubernetes look contained until they are not. A pod can still open a socket, spawn a child, talk to a model API you did not intend, or write somewhere the application path never recorded.
The question is not whether you have a cluster policy. It is whether the control follows the process when the wrap is skipped, and whether you can still name the gap when application logs and host events disagree.
Vantio is aimed at that host and pod envelope on Linux you operate. It is not a generic Kubernetes security suite, and it is not a claim that every cluster Vantio has never seen is already covered.
What works today on this node class
On configured and enrolled Linux workloads, Phantom Engine can enforce declared controls over supported process, filesystem, and network paths. Exact coverage and residual limitations are documented for the deployment.
- Available todayHelm DaemonSet and Linux daemon install paths
- You can enroll Linux with the documented Helm chart on a cluster you operate, or with the Linux daemon on standalone hosts. Those install paths exist today. They are not a completed pass on a stranger cluster.
- Available todayPer-pod scoped egress control
- On configured and enrolled Linux workloads, Phantom Engine can scope egress by cgroup and CIDR so the control sits with the workload rather than with a cluster-wide blanket. Exact coverage and residual limitations are documented for the deployment.
- Available todayOptics and Phantom Engine on the supported application path
- Inside the pod or node, Optics still records destination, process, timing, volume, and trace for supported Node and Python paths, and Phantom Engine still applies destination, sensitive-data, and spending policies on that wrap. Browser paths and processes that never enter the wrap stay outside application-path enforcement.
- RoadmapMulti-node and multi-cluster operation on infrastructure we do not run
- Fleet-scale enrollment, independent operator validation, and running this as a managed pattern across clusters Vantio does not operate have not been proven. Company-operated hosts cannot close that test.
What is not available yet
- No customer cluster has been validated by an independent operator. What we have proven so far, we proved on infrastructure we run ourselves.
- Windows and macOS host enforcement are not available. A Kubernetes control plane on those operating systems does not change that.
- Vantio does not replace cluster policy, service mesh, or cloud IAM. It adds process-aware host control on the Linux you enroll.
- Control of every process on every node is not on offer. Residual paths get named rather than implied away.
What stays true regardless
- You own the policy. Vantio does not decide what your agents are for.
- You set the level of autonomy, and you can turn it down at any time.
- You can revoke a capability, and the enforcement point stops honoring it.
- You can export the evidence and take it with you.
- There is no hidden Vantio remote override on your infrastructure.
- Independent safety systems keep the authority they were designed with. Vantio does not replace an interlock, an e-stop, or a local controller.
Talk through the cluster you actually have
If you already run Linux agents in Kubernetes you operate, we would rather map the install path against that cluster than pretend every cluster looks the same. Optics is still the lowest-risk first step on the application path.