Many teams assume that service accounts are harmless because they never log in interactively. In reality, they are a prime vector for insider threat, especially when the same credential is reused across scripts, CI pipelines, and automated bots.
Non‑human identities, service accounts, API keys, AI agents, and other machine principals, are typically provisioned with broad, long‑lived permissions. The credentials often live in plain‑text configuration files or secret stores that are accessible to anyone with repository access. When an insider obtains or misuses those secrets, there is no real‑time check on what commands are issued, no audit of data that flows back, and no way to stop a dangerous operation before it reaches the target system.
Because the identity layer only tells the system *who* is making a request, it cannot alone enforce *how* that request is used. An OIDC token or a static key confirms that a service account exists, but it does not guarantee that the account only performs its intended job. Without a control point on the traffic path, privileged commands can be executed silently, and sensitive fields can be exfiltrated without detection.
Why enforcement must sit on the data path
The only place to inspect and intervene on a request is where the request actually travels. A gateway that proxies the connection can see every protocol command, every query result, and every byte that moves between the non‑human identity and the infrastructure resource. By placing policy checks at that point, you can enforce least‑privilege, require just‑in‑time approval, mask data in responses, and record the entire session for later review.
hoop.dev as the enforced gateway
hoop.dev implements exactly that data‑path control. It sits between the machine principal and the target database, Kubernetes cluster, SSH host, or HTTP service. When a request arrives, hoop.dev validates the OIDC or SAML token, extracts group membership, and then decides whether the request may proceed.
- hoop.dev records each session, creating a replayable audit trail that shows who issued every command.
- hoop.dev masks sensitive fields, such as passwords, tokens, or personal data, before they are returned to the caller.
- hoop.dev blocks dangerous commands in real time, preventing destructive actions from ever reaching the backend.
- hoop.dev routes high‑risk operations to a human approver, enabling just‑in‑time access without granting permanent rights.
- hoop.dev never exposes the underlying credential to the calling process; the gateway holds the secret and presents a short‑lived connection on behalf of the identity.
These enforcement outcomes exist only because hoop.dev occupies the data path. If the gateway were removed, the same service account would connect directly to the resource, and none of the above protections would apply.