Why just-in-time access matters for planner‑executor agents
Over‑provisioned access for automated planner‑executor agents can inflate cloud spend, expose sensitive data, and amplify the impact of a single compromised token. When a planner runs with a static credential, every downstream service it touches inherits that privilege, creating a blast radius that grows with each new job. The cost is not only monetary; it also erodes confidence in the automation pipeline because a breach can propagate silently.
Current practice: static credentials and standing access
Most teams hand a long‑lived API key or service‑account password to a planner‑executor component and trust that the component will use it responsibly. The credential is stored in configuration files or secret managers, but the agent itself can read it at any time. There is typically no real‑time audit of what commands the planner runs, no masking of sensitive fields in responses, and no way to intervene if the planner attempts an unexpected operation.
What a just-in-time model still needs
Moving to a just-in-time access model solves the over‑privilege problem by issuing short‑lived, scoped tokens only when a specific job starts. The model still requires a non‑human identity (service accounts or OIDC clients), a least‑privilege policy, and a mechanism to request the token. However, the request still travels directly to the target resource, meaning the system cannot see which command is being executed, cannot mask data in flight, and cannot record the session for later review.
hoop.dev as the data‑path enforcement point
hoop.dev sits in the protocol layer between the planner‑executor identity and the infrastructure it needs to reach. By proxying every connection, hoop.dev becomes the only place where enforcement can happen. It issues just‑in‑time credentials on demand, checks each request against approval policies, masks sensitive fields in responses, and records the entire session for replay.
Setup: identity and least‑privilege provisioning
Deploy an OIDC or SAML identity provider (Okta, Azure AD, Google Workspace, etc.) and create a service account for the planner. Assign the account only the permissions required for a single job. hoop.dev validates the token, extracts group membership, and uses that information to decide whether a request may proceed.
Data path: the gateway that proxies every request
All traffic from the planner to a database, Kubernetes cluster, or SSH host is routed through hoop.dev. The gateway holds the credential for the target, so the planner never sees it. Because the gateway intercepts the wire‑level protocol, it can inspect commands before they reach the backend.
Enforcement outcomes: just‑in‑time approval, masking, and recording
When a planner asks for access, hoop.dev issues a short‑lived token that expires as soon as the job finishes. If the request matches a rule that requires human approval, hoop.dev pauses the connection and routes the request to an approver. For any response that contains sensitive columns (credit‑card numbers, passwords), hoop.dev masks those fields in real time. Every session is stored for replay, giving auditors a complete view of who did what and when.
Practical steps to adopt the pattern
- Deploy the gateway using the getting‑started guide.
- Register each planner‑executor target (PostgreSQL, Kubernetes, SSH, etc.) in hoop.dev.
- Define just‑in‑time policies, approval workflows, and masking rules in the learn section.
- Monitor recorded sessions and audit logs to verify compliance and detect anomalies.
FAQ
- What is just-in-time access for planner‑executor agents? It is the practice of granting a short‑lived, scoped credential only when a specific automated job starts, and revoking it automatically when the job ends.
- How does hoop.dev enforce JIT without exposing credentials to the planner? The gateway holds the backend credential and issues a temporary token after validating the planner’s identity. The planner never sees the long‑lived secret.
- What evidence does it generate for auditors? hoop.dev records every session, logs approval decisions, and stores masked response data, providing a complete audit trail that maps a planner’s identity to each command executed.
Ready to try it? Explore the open‑source repository and follow the quick‑start guide.
