Configuring AI agents access to AWS with just-in-time access

What does an agent actually need to touch in AWS this minute, and for how long? If you cannot answer that per task, the agent is running on standing access, and just-in-time access is the control that closes the gap. The hard part is not turning it on. The hard part is knowing what a grant has to cover before you trust it.

So this is a checklist. Five things a just-in-time access control for an AWS agent has to get right, what each one means in practice, and how to tell when it is missing.

The five things a grant must cover

• Identity. The grant ties to a specific agent identity, not a shared role everything assumes. If two agents look identical at the access layer, no later control can tell them apart.
• Scope. The grant carries the narrowest AWS permissions the task needs, named down to the action and the resource ARN. A grant that hands out s3:* is just-in-time in name only.
• Duration. The grant expires on its own, in minutes, not at the end of a shift. Time is half of blast radius.
• Approval. Higher-risk scopes route through a human or a policy decision before the grant issues. Low-risk reads can pass automatically so the agent stays fast where it is safe.
• Record. Every request, decision, and expiry is written somewhere the agent cannot reach. A grant nobody can reconstruct later is a grant you cannot defend.

Run any agent setup against that list. Most fail on the last item first: the only record of what the agent did lives inside the agent, which means a compromised agent can rewrite its own history.

Why the record has to sit outside the agent

The five items are not independent. Identity, scope, and duration decide what can happen. The record decides whether you can prove what did happen. And the record only counts if it is issued and stored by something the agent does not control. If the agent mints its own just-in-time access and writes its own log, it can extend the first and edit the second, and the checklist collapses into theater.

That requirement, a grant issued and recorded outside the process that uses it, is the architecture hoop.dev is built around. The agent connects through hoop.dev as a Layer 7 access gateway instead of holding AWS keys, access to each AWS-hosted resource is granted per task, and each session is recorded on the gateway side. hoop.dev reaches the resource with its own scoped IAM role, so the agent never becomes an AWS principal. The checklist items stop being things you assemble and become properties of one access path. The getting-started docs cover fronting an AWS-hosted resource, and the learn pages go into how grants are scoped and recorded.

A worked example

An agent needs to read one object from a reporting bucket. Under just-in-time access the sequence is: the agent asks hoop.dev for a connection to that bucket, policy checks the request against the agent identity and the scope, a short-lived grant to that single connection is issued, hoop.dev reads the object using its own scoped role, the session is recorded, and the grant expires. The agent holds no AWS credentials at any point, and nothing about that access survives the task.

Contrast that with the same agent holding a static key. The key grants the bucket read whether or not a task needs it, it grants the same read tomorrow, and if the agent is ever turned against you, the read is already authorized. The just-in-time version has no resting state to abuse: between tasks the agent holds nothing at all. That is the practical payoff of the checklist, not the individual items but the fact that access only exists while it is being used.

Where the checklist usually fails

• Scope without time. A tight policy on a grant that never expires is still standing access.
• Time without scope. A five-minute grant carrying account-wide permissions can do enormous damage in five minutes.
• Approval on everything. Gating every low-risk read trains approvers to click yes. Reserve approval for scopes that deserve the friction.

FAQ

Is just-in-time access overkill for a read-only agent?

No. Read-only at the application layer still means standing read access to data, which is exactly what leaks in an incident. A scoped, expiring grant limits what a confused or compromised agent can read.

How long should a grant last?

Long enough for the task and no longer, measured in minutes. If a task genuinely runs for hours, scope the grant tightly and record the full session rather than stretching the duration.

hoop.dev is open source. To configure just-in-time access in front of AWS, start from the repository on GitHub.