Skip to main content
You can run AI agents on Kubernetes, with each agent run in its own pod. An agent runs commands that a prompt can influence, so if you give its pod an API key, such as from a Kubernetes Secret, the key can leak through a prompt injection. With Agent Vault, agent pods contain no API keys. Each pod receives a session token instead, and sends its requests through an Agent Vault proxy that attaches the real credentials. This page explains how the pieces fit together in a cluster and how to choose an isolation level for agent pods.

Set up Agent Vault on Kubernetes

Deploy the proxy, lock agent pods to it, and start an agent with its own session.

​
How the pieces fit together

You need an orchestrator: a program that starts each agent run. It can be a script, a job in your CI pipeline or job runner, or a Kubernetes controller. For each agent run, your orchestrator does the following:
  1. Creates a session for the run with the Infisical API
  2. Starts the agent’s pod with the session token
  3. Revokes the session and deletes the pod when the agent finishes
Agent pods can only be limited to the proxy if your cluster’s network plugin enforces network policies, such as Cilium or Calico. Some network plugins, such as Flannel, accept network policies without enforcing them.
A network policy applies to a whole pod. A proxy in the agent’s pod would need a route to the internet that the agent could also use, and its proxy token would sit beside the agent.
Code in the agent’s container can ignore HTTPS_PROXY and connect to an API directly. With a network policy that only allows the proxy, every request must go through Agent Vault. This also blocks your cloud’s metadata service and the Kubernetes API.
Your orchestrator uses the machine identity to create sessions, and the machine identity can create a session for any access bundle it has access to. If the machine identity’s credentials were in an agent’s pod, the agent could use them to create a session for an access bundle it wasn’t given. A separate container in the agent’s pod doesn’t keep the credentials out of reach, because gVisor and Kata isolate a pod from the node, not one container from another. An agent pod gets only a session token, which you can revoke and which expires.
Yes. Agent Sandbox is an official Kubernetes project with custom resources for agent sandboxes, such as SandboxTemplate, SandboxClaim, and SandboxWarmPool. Its sandboxes are pods, so the proxy and the agents namespace work the same way, with these differences:
  • Session tokens: a SandboxTemplate serves every claim, so your orchestrator has to deliver each sandbox’s session token after its claim binds
  • Warm pools: pods in a SandboxWarmPool start before any session exists, so they also get their session token after the claim binds
  • Network policies: a network policy that the Agent Sandbox controller creates can allow traffic that the agents namespace’s policy blocks, so turn it off or limit it to the proxy, then check direct egress

​
Choose an isolation level

A standard container shares the node’s Linux kernel. If an agent ran code that exploited a bug in that kernel, the code could reach the node and every pod on it. To give agent pods a stronger boundary, run them with a different container runtime by setting runtimeClassName in the pod spec. Everything else on this page stays the same at every isolation level.
Kata Containers only runs on nodes with hardware virtualization (KVM), and most cloud VMs don’t provide it:
  • Supported: bare metal nodes, such as EC2 .metal instance types, and VMs with nested virtualization turned on, such as Google Compute Engine N2 or C3 VMs created with --enable-nested-virtualization
  • Not supported: standard EC2 instance types, EKS on Fargate, and GKE Autopilot
To check a node, run ls /dev/kvm on it. If the file doesn’t exist, Kata pods can’t start on that node.
An isolation level limits what a process can reach after it escapes its container. It doesn’t limit what requests the agent can make with its session’s access. Agent Vault and the network policies control that access.

​
Next steps

Set up on Kubernetes

Deploy the proxy, lock agent pods to it, and start an agent with its own session.

Create sessions with the API

Create and revoke a session for each agent run from your orchestrator.