When a service account is granted more permissions than it ever needs, the hidden cost is a bloated access review that masks risky drift and forces auditors to chase phantom privileges.
Most teams treat non‑human identities like throw‑away keys: a long‑lived IAM user or an AWS access key that is copied into CI pipelines, Terraform modules, or legacy scripts. The credential is often shared across multiple jobs, never rotated, and rarely tied to a single owner. Because the key is static, no one knows which job actually used it, and the audit trail is a single line in CloudTrail that says “AssumeRole” without context. Over time the permission set balloons as engineers add policies to fix breakages, creating a “permission creep” problem that only surfaces during a painful, manual access review.
In practice, an access review for these accounts becomes a guessing game. Reviewers see a list of attached policies, but they cannot tell whether a policy is still required, whether a particular Lambda function still calls the service, or whether a recent code change has rendered the permission obsolete. The result is either a rush to grant blanket exceptions – inflating the attack surface – or an exhaustive manual hunt that consumes weeks of engineering time.
The root of the problem is that the identity provisioning step alone does not provide visibility or control over the actual usage of the credential. Switching to non‑human identities that are issued via OIDC or short‑lived service tokens solves the credential‑sprawl, but the request still travels directly to the target AWS service. Without an intervening enforcement point, there is still no audit of each command, no inline masking of sensitive response data, and no just‑in‑time approval workflow that could surface risky actions before they happen.
What teams need is a gateway that sits on the data path, intercepts every request from a non‑human identity, and applies policy before the request reaches the AWS resource. hoop.dev is built exactly for that purpose.
Setup: defining non‑human identities
The first step is to provision service accounts as OIDC‑backed identities or AWS IAM roles that are mapped to groups in your identity provider. The setup phase decides who can request a connection, what groups they belong to, and which resources they are allowed to target. This is the classic “who am I” question that identity providers answer, but on its own it does not enforce any runtime guardrails.
The data path: hoop.dev as the enforcement boundary
hoop.dev sits between the identity token and the AWS service. Every API call, CLI command, or SDK request is proxied through the gateway. Because the gateway is the only place the traffic passes, it can inspect the wire‑protocol, apply policies, and record the interaction before the request ever reaches the target.
Enforcement outcomes that matter for access reviews
hoop.dev records each session, preserving a replayable log that shows exactly which command was issued, by which service account, and what response was returned. This log becomes the primary evidence for any access review, eliminating the need to infer intent from static policy documents.