How can you securely provision non-human identity for automated agents without exposing static secrets?
Most teams start by creating a service account, storing its password or API key in a vault, and then handing that credential to every CI job, bot, or background process that needs to talk to a database, a Kubernetes cluster, or an internal API. The credential lives on disk, in environment variables, or in a CI secret store that is often shared across many pipelines. Because the same secret is reused, a single leak grants an attacker, or a careless developer, full access to every downstream system the account can reach.
This practice creates three concrete problems. First, the credential is a single point of failure: if it is exfiltrated, the attacker can act with the same privileges as the automation. Second, the organization loses visibility; there is no reliable way to attribute a specific query or command to the exact job that issued it. Third, the automation runs with standing access that is broader than any single task actually needs, inflating the blast radius of a compromised job.
Non-human identity is essential for any automated workflow. Without a dedicated identity, you either resort to human‑owned credentials (which defeats the purpose of automation) or you give every bot unrestricted rights. Even when you introduce a service account, the request still travels directly from the agent to the target system. The connection bypasses any enforcement layer, so there is no audit trail, no inline data masking, and no opportunity to require a human approval before a risky operation.
To close that gap, the enforcement point must sit on the data path, between the agent loop and the protected resource. This is where a Layer 7 gateway can provide the missing controls.
Why a gateway is required for non-human identity
hoop.dev acts as an identity‑aware proxy that terminates the agent’s connection, verifies the caller’s OIDC or SAML token, and then forwards the request to the target only after applying policy. By placing the gateway in the data path, every request, whether it originates from a CI job, a scheduled script, or an AI‑driven agent, passes through a single control surface.
Setup: defining the non-human identity
The first step is to register a service account in your identity provider and grant it the minimal set of permissions required for its job. hoop.dev consumes the OIDC token, extracts group membership, and maps those attributes to a policy that limits which resources the identity may reach and what operations it may perform. Because the token is short‑lived, the risk of credential reuse is dramatically reduced.
The data path: proxying the connection
When the agent initiates a connection, hoop.dev terminates the protocol, inspects the traffic, and then re‑establishes a backend session using its own credential. The original non‑human identity never sees the target’s password or private key. All traffic flows through the gateway, giving it the sole authority to enforce masking, command validation, and just‑in‑time (JIT) approvals.
Enforcement outcomes that only a gateway can deliver
- hoop.dev records each session, producing a replayable audit log that ties every query back to the originating service account.
- It masks sensitive fields, such as credit‑card numbers or personal identifiers, in real time, ensuring that downstream systems never expose raw data to the automation.
- It blocks dangerous commands before they reach the target, preventing accidental data loss or privilege escalation.
- For high‑risk operations, hoop.dev routes the request to a human approver, enforcing a JIT approval workflow.
- All activity is recorded in an audit log, providing compliance teams with evidence without relying on the target’s own logs.
Because hoop.dev is the only component that can see both the identity token and the raw payload, these outcomes disappear the moment the gateway is removed. The setup alone, creating a service account and assigning permissions, does not provide any of these guarantees.
Practical steps to adopt non-human identity with hoop.dev
- Define a dedicated service account for each automation workload in your IdP.
- Assign the least‑privilege role needed for that workload; avoid wildcard permissions.
- Register the workload in hoop.dev’s connection catalog, selecting the appropriate target type (PostgreSQL, SSH, Kubernetes, etc.).
- Configure hoop.dev to use your OIDC provider for token verification. The gateway will then map token claims to access policies.
- Enable JIT approval for any operation that modifies schema, deletes data, or changes cluster configuration.
- Turn on session recording and inline masking for any data‑sensitive flow.
When these steps are complete, every automated request is forced to travel through the gateway, where hoop.dev enforces the policy you defined. The result is a clean separation: identity provisioning happens in the IdP (setup), enforcement happens in the gateway (data path), and the audit, masking, and approval capabilities (enforcement outcomes) are guaranteed by hoop.dev.
Further reading
Start with the getting‑started guide to spin up a test gateway. For deeper details on policy configuration, see the learn section of the documentation.
FAQ
Do I still need to rotate service‑account credentials?
Yes. The gateway protects the credential while it is in use, but rotating secrets remains a best practice to limit exposure if a token is ever compromised.
Can hoop.dev enforce policies on encrypted traffic?
Because hoop.dev terminates the protocol at Layer 7, it can inspect and enforce rules on the clear‑text payload before re‑encrypting it for the backend.
Is the audit data stored in the same location as my application logs?
No. hoop.dev writes audit records to a dedicated store that is independent of the target system, simplifying compliance reporting.
Explore the source code on GitHub to see how the gateway is built and to contribute.
