Imagine a development pipeline where every piece of code that runs on production servers has been vetted by an access review, and the review evidence is automatically captured for auditors. In that world, a rogue command never slips past a gate, and compliance teams can prove who approved each execution without hunting through log files.
Why code execution needs access reviews
Running code on shared infrastructure is a high‑risk activity. Engineers often receive broad "execute" permissions on CI runners, Kubernetes pods, or remote shells. Those permissions are granted once, rarely revisited, and they bypass any human checkpoint. When a new script is introduced, the organization relies on the developer’s good intentions rather than a documented approval process. The result is a blind spot: a malicious insider or a compromised credential can launch arbitrary commands, exfiltrate data, or disrupt services, and the incident leaves little trace of who authorized the action.
What traditional setups get right – and where they stop
Most modern environments already enforce strong identity foundations. Single sign‑on, OIDC or SAML tokens, and least‑privilege IAM roles ensure that only known identities can start a session. That setup is essential; it tells the system *who* is trying to connect. However, identity verification alone does not answer *what* the identity is allowed to do at the moment of execution. Once the token is accepted, the request travels directly to the target – a database, a container, or an SSH daemon – without any intermediate check. No audit record of the specific command is created, no inline data masking occurs, and there is no workflow to pause a risky operation for a human sign‑off.
Putting the review gate in the data path
The missing piece is a control surface that sits between the authenticated identity and the resource it wants to touch. By inserting a gateway at the protocol layer, every execution request can be inspected, logged, and, if necessary, routed through an approval workflow before it reaches the target. This approach satisfies three requirements simultaneously:
- It keeps the enforcement point outside the agent that runs the code, so the agent cannot bypass the check.
- It records the exact command, the identity that issued it, and the outcome, providing reliable evidence for auditors.
- It can mask sensitive response fields (such as passwords or tokens) before they appear in logs or user terminals.
Only a data‑path gateway can guarantee that these outcomes happen for every execution, regardless of the underlying identity system.
How hoop.dev enforces access reviews for code execution
hoop.dev implements the gateway described above. It authenticates users via OIDC/SAML, reads group membership, and then places the request in front of a configurable policy engine. When a developer initiates a code run, whether through kubectl exec, an SSH session, or a database client, hoop.dev intercepts the wire‑level request.