Standing AWS credentials on autonomous agents create a perpetual blast radius that can be triggered by a single compromised token.
Today many teams bake long‑lived IAM keys into CI pipelines, container images, or serverless functions. The agents that run those workloads inherit the same static permissions for weeks or months, and there is no reliable record of which request touched which resource. If an attacker compromises one agent, the credential can be reused to enumerate S3 buckets, spin up privileged EC2 instances, or modify IAM policies without any alert.
Just-in-time access promises to shrink that window. Instead of granting a permanent role, a request for a privileged AWS operation is evaluated at the moment it is needed, granted for a short interval, and automatically revoked afterward. The approach limits exposure and forces a deliberate decision before any high‑impact action.
Introducing just-in-time access removes the static credential problem, but the request still travels straight to AWS’s API endpoints. Without an intermediate control point, the system cannot record the call, mask sensitive fields in responses, or require a human to approve risky actions. The gap remains: the request reaches the target directly, unobserved and ungoverned.
hoop.dev fills that gap by acting as a Layer 7 gateway that sits between autonomous agents and AWS. The gateway authenticates the agent’s OIDC token, evaluates the requested AWS operation against policy, and, if approved, forwards the request using its own short‑lived service credential. All traffic passes through hoop.dev, giving it the only place where enforcement can happen.
Setup begins with an identity provider such as Okta, Azure AD, or Google Workspace. The provider issues OIDC tokens that identify the calling service. hoop.dev validates those tokens, extracts group membership, and determines whether the caller is eligible to request just-in-time access. This step decides who the request is, but it does not enforce any permission on its own.
When a request arrives, hoop.dev checks the policy for the requested AWS action. If the policy requires approval, the request is routed to an approver before a short‑lived AWS credential is minted. For low‑risk actions, hoop.dev automatically grants a time‑boxed credential. In every case, hoop.dev records the full request and response, masks any secret fields that appear in the payload, and stores a replayable session log. These enforcement outcomes exist only because hoop.dev sits in the data path.
The result is a tightly controlled execution environment. Autonomous agents receive only the permissions they need for the exact duration required, and every API call is auditable. Security teams gain visibility into who accessed which AWS resource, when, and why. Incident responders can replay sessions to understand the sequence of commands that led to a breach, while compliance auditors receive a complete audit record of just-in-time access events.
To try this pattern, start with the getting started guide that walks through deploying the gateway, connecting an AWS account, and configuring OIDC authentication. The learn section explains policy syntax, approval workflows, and masking rules in more depth. When you are ready to explore the source code or contribute, visit the hoop.dev source repository.
Why autonomous agents need just-in-time access
Agents often run on behalf of multiple services, each with a different risk profile. Granting a single static role forces you to over‑provision, because the role must cover the union of all possible actions. Over‑provisioned roles become attractive targets for credential theft. Just-in-time access enforces the principle of least privilege at runtime, ensuring that an agent can perform only the operation it explicitly requested, and only for the time it needs to complete it.
How hoop.dev enforces just-in-time access for AWS
hoop.dev sits on the network edge, intercepting every AWS API call. It validates the caller’s identity, checks the request against a policy that defines which groups may perform which actions, and then either auto‑approves or routes the request for manual approval. After approval, hoop.dev issues a short‑lived credential that is scoped to the exact API operation. The gateway records the request and response, applies inline masking to any secret fields, and writes a replayable log. Because hoop.dev is the only point where traffic passes, it is the sole place where blocking, masking, and recording can be reliably applied.
Getting started
Deploy the gateway using the Docker Compose quick‑start or a Kubernetes manifest, depending on your environment. Register your AWS account as a connection, supplying a service‑level IAM role that hoop.dev will use to act on behalf of approved requests. Configure your identity provider so that agents receive OIDC tokens that include group claims. Finally, author a policy that maps groups to AWS actions and defines which actions require approval.
All of these steps are covered in the official documentation linked above. The docs also show how to view session recordings, configure inline masking for sensitive response fields, and integrate with existing ticketing systems for approval workflows.
FAQ
Does hoop.dev store my AWS credentials?
No. The gateway holds a service‑level credential that it uses only for the duration of an approved request. Agents never see the credential, and the credential is rotated automatically by the gateway.
Can I still use existing CI/CD pipelines?
Yes. Replace static credential usage with a call to the gateway. The pipeline obtains an OIDC token, requests just-in-time access, and the gateway returns a short‑lived credential that the pipeline uses for the specific AWS operation.
What happens if an approval is delayed?
The request remains pending in hoop.dev until an approver grants or denies it. No credential is issued until approval, so the operation cannot proceed without explicit consent.
