How to Implement IAM for Non-Human Identities

When service accounts are treated like shared passwords, the cost to your iam program is more than a few extra tickets. A compromised credential can let an attacker roam laterally, exfiltrate data, and stay hidden for weeks, all while the organization continues to trust the same static secret.

Most teams start with a single API key or SSH private key that dozens of automated jobs, CI pipelines, and batch processes all reuse. The key lives in a repository, a config map, or a developer’s home directory. When that key is rotated, every job must be updated manually, and the window for error is large. The result is a fragile environment where a single mistake can cause outages, compliance gaps, and costly incident response.

Even when an organization adopts non‑human identities, service accounts, OIDC tokens, or short‑lived IAM roles, the underlying problem often remains. The token is issued once, stored in a vault, and then handed directly to the target system. The request travels straight to the database, Kubernetes API, or SSH daemon without any visibility. There is no record of which automation invoked which command, no real‑time check that the operation complies with policy, and no way to mask sensitive fields that appear in logs.

Why a gateway is required for IAM on non‑human identities

To close the gap, the enforcement point must sit on the data path, not merely in the identity provider. The gateway becomes the only place where traffic can be inspected, approved, or transformed before it reaches the resource. This design satisfies three essential requirements:

• Setup: Identity providers (OIDC, SAML) issue tokens that define who the caller is and what groups they belong to. The provider decides whether a request may start, but it does not enforce command‑level policies.
• The data path: A Layer 7 proxy intercepts the wire protocol, ensuring every request passes through a single, auditable boundary.
• Enforcement outcomes: Because the proxy controls the flow, it can record sessions, mask sensitive response fields, require just‑in‑time approval for risky commands, and block disallowed actions.

hoop.dev implements exactly this architecture. It sits between the non‑human identity and the target service, acting as an identity‑aware proxy that enforces policy at the protocol level.

Setup – defining the non‑human identity

First, configure an OIDC client or SAML trust that represents your automation workloads. Assign the client to a minimal set of groups that reflect the job’s purpose, read‑only access to a specific database, deployment rights to a single namespace, or monitoring privileges for a metrics endpoint. The identity provider authenticates the service account and issues a short‑lived token that includes the group claims.

These tokens are never handed directly to the target. Instead, they are presented to the gateway, which validates the signature and extracts the group membership. Because the token is short‑lived, credential leakage has a limited window of impact.

The data path – hoop.dev as the only access point

hoop.dev runs a network‑resident agent next to each resource. All traffic from the automation client is forced through the gateway. The gateway terminates the protocol (PostgreSQL, SSH, Kubernetes exec, etc.) and then opens a new connection to the backend using its own service credential. The automation never sees the backend credential, eliminating credential sprawl.

Because every request passes through hoop.dev, the system can apply consistent policy regardless of the underlying target. Whether the call is a SQL query, a kubectl exec, or an SSH command, the same enforcement engine evaluates it.

Enforcement outcomes – audit, masking, JIT approval, and blocking

hoop.dev records each session in a persistent log, providing a complete replayable audit trail. When a response contains personally identifiable information or secret tokens, hoop.dev can mask those fields in real time, ensuring logs and downstream systems never expose sensitive data.

For high‑risk operations, such as dropping a database, deleting a Kubernetes namespace, or executing a privileged shell, hoop.dev can trigger a just‑in‑time approval workflow. The request is paused, an authorized reviewer is notified, and only after explicit approval does the gateway forward the command.

If a command violates a policy rule (for example, a SELECT that attempts to read a credit‑card column), hoop.dev blocks the command before it reaches the backend, returning an informative error to the caller.

Getting started with hoop.dev for non‑human IAM

Follow the getting‑started guide to deploy the gateway in your environment. The documentation walks you through configuring OIDC trust, defining groups, and registering a target resource. For deeper policy options, consult the feature documentation, which explains how to set up masking rules, approval workflows, and session replay.

FAQ

Do I still need a vault for service‑account secrets?

Yes. The vault stores the short‑lived tokens that automation uses to authenticate to hoop.dev. The gateway never stores long‑term credentials for the backend systems.

Can hoop.dev enforce policies on existing workloads without code changes?

Exactly. Because the enforcement happens at the protocol level, existing scripts and binaries continue to work; they simply point to the gateway endpoint instead of the raw service address.

What happens if the gateway itself is compromised?

The gateway runs with its own service identity and logs every action it forwards. Compromise would be evident in the audit trail, and because the gateway does not expose backend credentials, the blast radius is limited.

Explore the open‑source repository on GitHub to get started.