When access reviews are baked into every agent loop, teams see clear accountability, timely revocation, and evidence that auditors can rely on.
Current practice of agent loops
Most organizations deploy automation agents that continuously poll or push changes to databases, Kubernetes clusters, or remote hosts. Those agents often run under a static service account or a long‑lived token stored in a configuration file. The token grants the agent broad read‑write rights, and the loop executes without any human checkpoint. Because the credential never changes and the loop never pauses for a review, any drift in policy or a compromised secret goes unnoticed until an incident surfaces.
Why access reviews matter
Access reviews are periodic or event‑driven checks that confirm a principal’s right to act on a target. In the context of an agent loop, a review asks: “Is this service account still needed for this specific resource? Does it have the least‑privilege permissions?” Without a review, the loop can continue to perform privileged operations long after the business need ends, increasing the blast radius of a breach and violating compliance expectations.
What a proper review looks like
A proper review does three things. First, it identifies the identity that the loop presents to the target. Second, it evaluates the granted permissions against the current job description. Third, it records the outcome, approved, modified, or revoked, so that auditors have a reliable trail. The review itself must happen before the loop reaches the target; otherwise the loop could already have performed an unwanted action.
Enabling continuous reviews with hoop.dev
Setup components such as OIDC or SAML tokens decide who the request is and whether it may start, but they do not enforce policy on the traffic. The data path is the only place enforcement can happen. hoop.dev sits in that data path, acting as an identity‑aware proxy for the agent loop. By routing every request through hoop.dev, the gateway can apply the review logic before the request touches the target.
Once in the gateway, hoop.dev can:
- Query the identity presented by the agent against a policy store.
- Require a just‑in‑time approval if the request exceeds the baseline privilege set.
- Record the decision and the full session for later audit.
- Mask sensitive fields in responses if the policy dictates.
All of these enforcement outcomes exist only because hoop.dev occupies the data path. Without the gateway, the loop would connect directly to the resource and none of the review steps could be guaranteed.