An auditor points at a row in your logs and asks who approved an agent's access to the production account on Tuesday, why it was still active on Thursday, and what it did in between. If the honest answer is a shrug, the finding writes itself. Just-in-time access is the control that lets you answer all three without flinching, because it makes every grant a deliberate, time-boxed, recorded event.
Rather than list setup steps, walk this from the review backward. Start with what a reviewer wants to see, then build the control that produces it.
The questions a review actually asks
An access review of an AWS agent tends to come down to a short set of questions:
- Who, specifically, had access, and was it a distinct identity or a shared role?
- What scope did they hold, and was it the least that the task required?
- When did access begin and end, and why did it end when it did?
- Who or what approved it?
- What happened during the session, captured outside the thing being reviewed?
Standing access answers almost none of these cleanly. A long-lived role assumed by everything cannot say who or why, and "it never ended" is not an answer a reviewer likes.
How just-in-time access answers them
Just-in-time access turns each of those questions into a recorded fact. Access is requested by a named agent identity, scoped to the task, granted for a short window, approved by policy or a person, and the session is recorded. The review stops being an archaeology project and becomes a query: pull the grants for that account and that day, and every one carries its identity, scope, duration, approver, and recording.
This only holds if the grants and records are produced by something the agent does not control. If the agent issues its own access and keeps its own log, a reviewer is reading the suspect's diary. The issuing and recording layer has to sit outside the agent. hoop.dev is built that way: the agent reaches AWS-hosted infrastructure through a Layer 7 access gateway that connects with its own scoped IAM role, access is granted per task, and each session is recorded on the gateway side where the agent cannot edit it. The learn pages explain the access model, and the getting-started docs cover fronting an AWS-hosted resource.
A walkthrough of one request under review
Trace a single grant the way a reviewer would. An agent requested read access to a logs bucket at 14:02. Policy matched the agent identity to an allowed scope and issued a grant for one prefix, expiring at 14:12. The session recording shows the objects read and nothing else. The grant expired on schedule. Every question above is answered by that one record, and none of the answers depend on trusting the agent.
Notice what the reviewer did not have to do. They did not cross-reference three systems to figure out which agent was behind a shared role. They did not ask an engineer to remember why access was granted. They did not accept "the log says the call succeeded" as proof the access was authorized. The grant carried its own justification, and the recording sat next to it.
What changes for the team being reviewed
The quieter benefit is that just-in-time access changes the review from an event you brace for into a property of the system. When every grant is already scoped, time-boxed, approved, and recorded, there is no scramble to assemble evidence before an audit, because the evidence accumulated as the work happened. A review becomes a query against records that were correct the day they were written. That is a very different posture from exporting six months of logs and hoping they tell a coherent story.
Pitfalls that still produce findings
- Shared agent identity. If many agents share one identity, "who" is unanswerable no matter how good the rest of the control is.
- Approvals that are not recorded. An approval that happened in a chat message and not in the access record cannot be shown to a reviewer.
FAQ
Does just-in-time access replace our audit logging?
No, it strengthens it. Just-in-time access makes each grant a discrete, attributable event, which is what gives the audit log something precise to record.
What if a task legitimately needs longer access?
Grant the scope it needs and record the full session, rather than making the grant permanent. Duration should match the task and still end on its own.
hoop.dev is open source. To put just-in-time access in front of AWS, start from the repository on GitHub.
