With just-in-time access in place, autonomous agents only talk to Kubernetes clusters when an explicit, time‑bound request has been approved, and every command is recorded, masked where needed, and can be replayed for audit.
Today many teams hand autonomous workloads static service‑account tokens or long‑lived kubeconfig files. Those credentials are baked into CI pipelines, stored in secret managers, and often granted cluster‑admin or broad namespace rights. The result is a moving target: an agent can spin up a pod, delete a service, or exfiltrate secrets at any moment, and there is no reliable record of what it did. Breaches become hard to trace, and compliance teams struggle to prove who performed which action.
Why just-in-time access matters for autonomous agents
The core problem is that identity and authorization are decoupled from the actual data path. Identity providers (OIDC, SAML) can tell us *who* the agent is, and RBAC can limit *what* it may do, but without a gate that sits on the traffic flow there is no point where we can enforce dynamic policies, request approvals, or mask sensitive responses. Even with the strictest RBAC, a compromised token still gives the attacker unfettered access until the token expires.
What we need is a boundary that:
- Accepts a short‑lived identity token from the agent.
- Verifies the token against the organization’s IdP.
- Requires an explicit approval step before forwarding privileged commands.
- Records every API call and streams it to a storage backend.
- Redacts fields such as secrets or tokens in responses, so they never leave the cluster unprotected.
These controls must be applied *where the request passes through the network*, not after the fact.
How hoop.dev becomes the data‑path enforcement point
hoop.dev is a Layer 7 gateway that sits between agents and the Kubernetes API server. The gateway runs a lightweight agent inside the same network as the cluster, and all traffic is proxied through this agent. Because the gateway is the only place the request traverses, it is the sole location where enforcement can happen.
When an autonomous process wants to run kubectl or use the Kubernetes client library, it first obtains an OIDC token from the corporate IdP. hoop.dev validates that token, extracts group membership, and maps the identity to a predefined policy. If the policy requires a human approval for the requested operation, say, creating a Deployment in a production namespace, the request is held at the gateway until an approver grants access. Once approved, the gateway forwards the request to the Kubernetes API using a credential that it alone holds; the original agent never sees the cluster’s bearer token.
Because the gateway inspects the wire‑protocol, it can also apply inline masking. If a response contains a secret stored in a ConfigMap, hoop.dev can replace the secret value with a placeholder before the data reaches the agent. This ensures that even a compromised agent cannot exfiltrate sensitive data that it does not need for its job.
Every command that passes through the gateway is logged with the requesting identity, timestamp, and full request/response payload (masked as configured). The logs are streamed to a storage backend that is independent of the cluster, providing an audit trail that satisfies forensic and compliance needs. The recorded sessions can be replayed in a sandboxed environment to reproduce exactly what happened.
Putting the pieces together: architecture at a glance
The end‑to‑end flow looks like this:
- Deploy the hoop.dev gateway in the same VPC or subnet as the Kubernetes control plane. The quick‑start guide walks through a Docker‑Compose deployment that includes the gateway and its network‑resident agent.
- Configure a Kubernetes connection in hoop.dev, supplying the cluster URL and a bearer token that the gateway will use. This token is stored only inside hoop.dev; agents never receive it.
- Register the autonomous service account in the IdP and grant it the minimal groups needed for its workload. The service account receives short‑lived OIDC tokens.
- When the autonomous agent runs, it authenticates to hoop.dev with its OIDC token. hoop.dev validates the token and determines whether the requested operation is covered by a just‑in‑time policy.
- If the policy requires approval, a workflow notification is sent to the designated approver. Once approved, the gateway forwards the request to the Kubernetes API.
- hoop.dev records the request and response, applying any configured masking, and streams the audit record to the external store.
This pattern satisfies the three required categories:
- Setup: Identity, OIDC tokens, and minimal RBAC are established, but on their own they do not enforce dynamic controls.
- Data path: hoop.dev is the only point where traffic is inspected and altered.
- Enforcement outcomes: just‑in‑time approval, command‑level recording, inline masking, and replayability are all delivered because hoop.dev sits in the data path.
Benefits for security and operations teams
By moving the enforcement layer out of the Kubernetes control plane and into a dedicated gateway, teams gain several advantages:
- Reduced blast radius: A compromised agent cannot act without passing through hoop.dev, and any suspicious command can be blocked before it reaches the API.
- Granular auditability: Every API call is captured with identity context, making investigations faster and more precise.
- Compliance readiness: The audit trail provides the evidence needed for SOC 2, ISO 27001, and other standards that require per‑user activity logs.
- Data protection: Inline masking prevents secrets from leaking to logs or downstream systems.
- Operational agility: Engineers can grant autonomous agents temporary access without creating long‑lived credentials, and approvals can be automated through existing ticketing systems.
Getting started
To try this pattern in your environment, follow the getting‑started guide. It walks you through deploying the gateway, registering a Kubernetes connection, and configuring just‑in‑time policies. The documentation also explains how to integrate with your IdP and how to set up masking rules. For deeper details on masking capabilities and policy configuration, see the learning hub.
All of the source code is open source under the MIT license. You can explore the repository, contribute, or fork it for custom extensions at github.com/hoophq/hoop.
FAQ
Does hoop.dev replace Kubernetes RBAC?
No. RBAC still governs what actions a token can perform inside the cluster. hoop.dev adds a layer of dynamic control, just‑in‑time approval, masking, and recording, on top of those static permissions.
Can I use hoop.dev with existing CI pipelines?
Yes. CI jobs can obtain an OIDC token from the same IdP used by developers, then route their kubectl commands through hoop.dev. The pipeline will automatically benefit from the same approval and audit controls.
What happens if the gateway itself is compromised?
Because the gateway does not store long‑lived credentials for agents, an attacker would still need a valid OIDC token to act. Additionally, all activity is logged, so any misuse of the gateway is immediately visible in the audit stream.
