An automated CI pipeline runs a nightly build that pushes a new Docker image, then triggers a ReAct‑driven job using a non-human identity. The job runs under a service account whose credentials were copied from a shared credentials file and never rotated.
In many organisations, that is exactly how non-human identities are used today. Engineers create a long‑lived API token, embed it in a configuration repository, and hand the same token to every automation script that needs to talk to ReAct. The token carries broad privileges – it can read, write, and delete data across multiple environments – and there is no central log of which script issued which request. When a bug in the automation code runs, the damage spreads quickly and the forensic trail is a mess.
This pattern satisfies the immediate need for a machine identity that can act without a human present, but it leaves three critical gaps. First, the identity is static; rotation is manual and infrequent. Second, the privilege set is coarse; the token is often over‑scoped for the specific task. Third, there is no visibility into the exact commands that the non-human entity issued, nor any way to block a dangerous operation before it reaches the target system.
Why a dedicated gateway matters for non-human identity
Non-human identity, by definition, is an identity that is not tied to a human user – service accounts, CI jobs, bots, and AI agents are all examples. The security model for these identities must enforce least‑privilege, provide just‑in‑time (JIT) access, and generate immutable evidence of every interaction. Those controls cannot be reliably applied at the identity provider alone; the provider decides *who* can start a request, but it does not sit in the data path where the request actually reaches the ReAct backend.
Enter hoop.dev. It is a Layer 7 gateway that sits between the non-human identity and the ReAct service. The gateway receives the OIDC token that represents the service account, validates it, and then proxies the protocol‑level traffic to ReAct. Because hoop.dev is the only point where the request passes before reaching the backend, it can enforce the missing controls.
Once the request is inside the data path, hoop.dev records the entire session, masks any sensitive fields that appear in responses, and can require a human approver for high‑risk commands. If a command is deemed unsafe, hoop.dev blocks it before it is executed. All of these enforcement outcomes are possible only because hoop.dev is the active component in the data path; without it, the service account would talk directly to ReAct with no guardrails.