Nested agents: what they mean for your least privilege (on Kubernetes)

Many teams assume that if a Kubernetes pod runs a sidecar that launches another pod, the permissions of the sidecar automatically limit the child pod. The reality is that the child pod inherits the service account of the node or the upstream pod, and the original least privilege intent is lost. The misconception often leads teams to think they have achieved least privilege, but nested agents break that guarantee.

Why the assumption breaks down

In Kubernetes, a service account is attached to a pod, not to the process inside the pod. When a sidecar container starts a new pod – often called a nested agent – the API server creates the child pod with the service account that the node’s kubelet is allowed to use. If the node’s default service account has broad permissions, the nested agent can act on resources that the original pod was never meant to touch. The setup stage – creating service accounts, binding roles, and configuring OIDC tokens – tells the system who is making the request, but it does not stop the request from reaching the API server with excessive rights.

What true least privilege requires

To enforce least privilege, the enforcement point must sit where the request actually travels. The Kubernetes API server is the only place that can verify whether a call complies with a fine‑grained policy. If the request bypasses that gate, the policy is ineffective. Therefore, a control layer that intercepts every API call, evaluates the caller’s identity, and applies masking, approval, or blocking is essential.

The role of a Layer 7 gateway

A Layer 7 gateway operates at the protocol level, between the client (human, service account, or AI agent) and the Kubernetes API server. By positioning itself in the data path, the gateway can inspect each request, enforce policies, and produce audit records. This is where the enforcement outcomes – session recording, inline masking of secrets in responses, just‑in‑time approval for risky operations, and command blocking – are realized.

How hoop.dev delivers least‑privilege enforcement for nested agents

hoop.dev sits in the data path for every Kubernetes connection, including exec, port‑forward, and API calls made by nested agents. Because hoop.dev is the only component that sees the traffic before it reaches the API server, it can enforce the following outcomes:

• hoop.dev records each session, creating a replayable audit trail that shows which service account issued which command.
• hoop.dev masks sensitive fields – for example, it can redact token values returned by the API before they reach the caller.
• hoop.dev blocks commands that match a deny list, preventing a child pod from creating cluster‑wide resources it should not have.
• hoop.dev routes high‑risk operations to a human approver, turning a potentially dangerous nested‑agent request into a controlled workflow.
• hoop.dev scopes access on a per‑request basis, so even if a sidecar launches a new pod, the request is evaluated against the original requester’s least‑privilege policy.

All of these capabilities stem from the fact that hoop.dev is the sole enforcement point in the data path. The initial identity verification – OIDC or SAML – tells hoop.dev who the caller is, but the gateway’s policies are what actually limit the caller’s power.

Getting started with hoop.dev on Kubernetes

Deploy the gateway using the official Docker Compose quick‑start or the Helm chart. Register your clusters as connections, bind them to the appropriate service accounts, and configure policy rules in the hoop.dev UI. Detailed steps are available in the getting‑started guide and the broader learn section. Once the gateway is in place, every nested‑agent request will pass through hoop.dev, ensuring that least‑privilege guarantees are enforced consistently.

FAQ

Q: Does hoop.dev replace Kubernetes RBAC?
A: No. RBAC still defines which identities exist. hoop.dev adds an enforcement layer that validates each request against policy before it reaches the API server.

Q: Can I use hoop.dev with existing clusters?
A: Yes. The gateway is deployed as an agent inside your network and can proxy connections to any cluster that you register, without changing the cluster itself.

Q: What happens if a nested agent tries to bypass the gateway?
A: Because hoop.dev sits in the data path, any direct connection that skips the gateway will be blocked by network policies you place around the API server. The gateway is the only approved route for API traffic.

Ready to see how hoop.dev can lock down nested agents and enforce least privilege on your Kubernetes workloads? Explore the source code on GitHub.