A newly created CI job launches a temporary agent that relies on just-in-time access to run a data‑migration script. The service account that the job uses has read‑write rights on the entire database and never expires. Hours later, a developer forgets to delete the job and the agent remains active, able to execute any query it chooses.
This pattern is common in modern automation. Teams rely on non‑human identities, service accounts, OIDC tokens, or CI‑generated credentials, to give agents the ability to talk to databases, Kubernetes clusters, or remote hosts. Granting the least privilege needed for the job is a best practice, but it still leaves a standing connection that can be abused if the agent is compromised or if the job runs longer than intended.
What the setup alone does not solve is the moment‑to‑moment decision about *when* an agent should be allowed to act and *what* it is allowed to do. The identity verification step tells the system *who* the request is, but it does not enforce *what* commands are executed, nor does it capture a replayable record of the session. Without a gate that sits on the data path, every command flows directly to the target resource, unfiltered and unapproved.
To close that gap, the access control point must live between the agent and the infrastructure. It needs to inspect the protocol, apply policy, and decide in real time whether to allow, block, or route the request for human approval. Only a gateway that intercepts traffic can provide true just-in-time access: granting permission at the exact moment it is required, revoking it immediately after, and logging the full interaction for audit.
Enter hoop.dev, an open‑source Layer 7 gateway that sits on the network edge of your infrastructure. It consumes identity tokens from your IdP, validates them, and then becomes the sole enforcement point for every connection that agents make to databases, Kubernetes, SSH, RDP, or internal HTTP services.
In practice, the gateway is deployed as a Docker Compose stack or a Kubernetes daemon set, and a lightweight agent runs next to each protected resource. When an orchestrated agent initiates a connection, it talks to the gateway instead of the target directly. The gateway reads the OIDC or SAML token, maps group membership to a policy, and then decides whether to forward the traffic, mask sensitive fields, or pause execution for a manual approval step.
How just-in-time access secures agent orchestration
Because the gateway sits in the data path, it can enforce the following controls on every request:
- Dynamic approval: If a command exceeds a predefined risk threshold, such as a DROP DATABASE statement or a privileged kubectl exec, the gateway can halt the request and send a notification to an approver. The approver’s decision is recorded and the command proceeds only after explicit consent.
- Command‑level masking: Responses that contain sensitive columns (e.g., credit‑card numbers or personally identifiable information) can be stripped or redacted before they reach the agent, preventing accidental leakage.
- Just‑in‑time credential issuance: The gateway can generate short‑lived, scoped credentials on the fly, ensuring the agent never holds a long‑lived secret. Once the session ends, the credential is revoked automatically.
- Session recording and replay: Every byte that passes through the gateway is recorded in a persistent audit log. Auditors can replay a session to see exactly what was typed and what data was returned.
These capabilities turn a static service account into a truly just‑in‑time identity. The agent receives permission only when the policy says it is safe, and the decision is tied to a concrete audit record.
From an operational perspective, this approach reduces blast radius. If an attacker compromises an agent, they inherit only the permissions granted for the current request, not a blanket token that lasts days or weeks. Because the gateway enforces policies centrally, you no longer need to scatter approval scripts or custom wrappers across your CI pipelines.
Getting started is straightforward. The getting‑started guide walks you through deploying the gateway, registering a database connection, and configuring a simple just‑in‑time policy. The learn section provides deeper examples of masking, approval workflows, and session replay.
FAQ
Q: Does just‑in‑time access replace existing IAM policies?
A: No. IAM defines *who* can request access. hoop.dev adds a layer that decides *when* and *what* that access can do, based on real‑time policy.
Q: Will my CI jobs need to change their client commands?
A: No. Agents continue to use standard clients (psql, kubectl, ssh, etc.). The only change is that they point to the gateway endpoint instead of the raw resource.
Q: How is audit data protected?
A: The gateway records session logs separately from the target resource, giving auditors a reliable audit trail.
Ready to see just‑in‑time access in action? Explore the open‑source code on GitHub and start securing your agent orchestration today.
