A newly hired contractor leaves the company, but the service accounts embedded in the CI pipelines that drive the planner‑executor framework remain active. Those accounts can still spin up compute, read databases, or write logs, because the automation never revokes them. This is a classic illustration of service account sprawl: dozens of long‑lived credentials drifting across environments without visibility.
Why service account sprawl happens in planner‑executor agents
Planner‑executor agents are designed for flexibility. Each job defines a service account that has just enough permissions to complete its task, and the account details are baked into the job definition or stored in a shared vault. Over time, teams create new agents for new features, copy‑paste existing definitions, and never retire the old ones. The result is a growing inventory of accounts that overlap in scope, some of which are never used, others that are over‑privileged, and none that are centrally audited.
The immediate benefit is speed: developers can push code without waiting for a manual approval process. The hidden cost is risk: a compromised build runner can impersonate any of those accounts, and there is no single place that can see which credential was used for which request.
The missing enforcement layer
Even when organizations enforce least‑privilege policies at the identity provider, the enforcement stops at token issuance. The request still travels directly from the planner‑executor agent to the target service, whether a database, a Kubernetes API, or an SSH host. No gateway sits in the middle to verify that the request matches an approved policy, to record the exact command, or to mask sensitive fields in the response. Without that data‑path enforcement, the setup alone cannot guarantee that service account usage is auditable or that risky commands are blocked.
In this state, the only controls are:
- Setup of OIDC or SAML tokens that authenticate the agent.
- Static role bindings that grant the service account its permissions.
Both are necessary, but they do not provide runtime guardrails. The request reaches the target directly, and there is no way to intervene, log, or mask data on the fly.
How hoop.dev closes the gap
hoop.dev is a Layer 7 gateway that sits in the data path between any planner‑executor agent and the infrastructure it accesses. By proxying the connection, hoop.dev becomes the only point where enforcement can happen.
When a request arrives, hoop.dev validates the OIDC token, extracts the identity, and checks the request against a policy that can require just‑in‑time approval. If the policy demands it, hoop.dev pauses the operation and routes it to a human approver before allowing it to proceed.
Every command that passes through the gateway is recorded. hoop.dev stores a session log that can be replayed later for forensic analysis. Because the gateway controls the response stream, it can mask sensitive fields, such as credit‑card numbers or personal identifiers, before they reach the caller.
Crucially, the enforcement outcomes exist only because hoop.dev sits in the data path. If hoop.dev were removed, the planner‑executor agent would once again talk directly to the target, and none of the session recording, inline masking, or approval workflow would occur.
Setup still matters. Organizations must provision OIDC clients, define least‑privilege roles for each service account, and configure the planner‑executor agents to use those identities. hoop.dev consumes those identities but does not replace the need for proper provisioning. The gateway simply adds the runtime enforcement layer that was missing.
Because hoop.dev is open source, teams can self‑host the gateway, integrate it with their existing identity provider, and extend the policy engine to match their internal compliance requirements. The documentation walks through a quick‑start deployment and shows how to register a planner‑executor target, so teams can get started without building a custom proxy.
To explore the source code and see how the gateway is built, visit the GitHub repository. For a hands‑on walkthrough, start with the getting‑started guide and then dive into the learn section for deeper policy examples.
FAQ
Does hoop.dev replace my existing identity provider?
No. hoop.dev relies on the tokens issued by your IdP. It validates those tokens and uses the identity information to enforce policies, but it does not issue or store credentials itself.
Can I still use existing service accounts with hoop.dev?
Yes. You register the service account credentials with the gateway, and hoop.dev ensures they are never exposed to the calling agent. The accounts continue to function, but every use is now logged and subject to policy.
What happens if a request is denied by hoop.dev?
The gateway returns a clear denial response to the planner‑executor agent. The event is logged, and an optional notification can be sent to the approver team for review.
