Are you still treating service accounts like permanent human users?
If you answer yes, you are likely missing a fundamental least privilege control for non‑human identities.
In many internal SaaS platforms, non‑human identities, service accounts, CI/CD bots, and automated agents, are provisioned once and never change. Because the same secret is reused across environments, a single compromise can give an attacker unfettered access to production databases, internal APIs, or admin consoles. The result is a classic over‑privilege problem: the identity can do far more than its intended job, and there is no visibility into which automated process performed which action.
Organizations have begun to replace static passwords with OIDC‑based service principals or cloud‑native roles that are scoped to a narrow set of permissions. This shift is a necessary first step. It reduces credential sprawl and lets identity providers enforce token expiration. However, the request still travels directly from the automation to the target service. No gateway sits in the middle to verify that the call complies with the organization’s least privilege policy, to mask sensitive fields in responses, or to record the exact command for later review. In other words, the setup alone does not guarantee enforcement.
Why least privilege matters for non‑human identities
Non‑human identities are attractive attack vectors because they operate without human oversight. An over‑privileged bot can enumerate all tables in a database, delete log files, or exfiltrate customer data with a single API call. Applying least privilege means each identity should have only the permissions required for its specific function, no more. This principle limits blast radius, makes breach containment easier, and satisfies audit requirements that demand evidence of permission boundaries.
Enforcing least privilege at the point where the request leaves the automation is essential. The enforcement layer must be able to:
- Validate that the requested operation matches the identity’s declared intent.
- Require a human approval step for high‑risk commands before they reach the target.
- Mask or redact sensitive data in responses so downstream systems never see raw secrets.
- Record the full session for replay, forensic analysis, and compliance reporting.
The missing enforcement layer
Without a dedicated gateway, the only place to enforce least privilege is inside the target service itself. That approach has two drawbacks. First, it couples policy logic with business logic, making updates error‑prone and difficult to audit. Second, the target often cannot see who or what initiated the request once the credential is presented, because the credential is static and shared among many agents.
To close this gap, an external, protocol‑aware proxy must sit between the non‑human identity and the infrastructure. This proxy becomes the single source of truth for every access decision, ensuring that the least privilege policy is applied consistently across databases, Kubernetes clusters, SSH sessions, and HTTP APIs.
hoop.dev as the data‑path enforcement point
Enter hoop.dev. It is a Layer 7 gateway that runs a network‑resident agent close to your services and intercepts traffic at the protocol level. Because hoop.dev is the only place the request passes through, it can enforce the least privilege model for every non‑human identity.
When a service account authenticates via OIDC, hoop.dev validates the token, extracts group membership, and maps the identity to a set of fine‑grained permissions. Before the request reaches the target, hoop.dev checks whether the operation is allowed. If the command is deemed risky, such as a DROP DATABASE or a privileged kubectl exec, hoop.dev can pause the flow and trigger an approval workflow. Only after an authorized reviewer approves does the request continue.
In addition to approval gating, hoop.dev can mask sensitive fields in responses, ensuring that downstream logs or monitoring tools never capture raw secrets. Every session, whether a psql query, a kubectl command, or an SSH shell, is recorded and stored for replay, providing the audit trail required by compliance frameworks. Because the gateway holds the target credentials, the automation never sees them directly, eliminating credential leakage at the source.
All of these enforcement outcomes exist solely because hoop.dev occupies the data path. The initial OIDC setup defines who can ask for access, but hoop.dev is the mechanism that actually enforces least privilege, records activity, and applies inline masking.
Getting started
To adopt this model, begin with the getting‑started guide. It walks you through deploying the gateway, registering a non‑human identity, and configuring a simple policy that limits the identity to read‑only access on a specific database. The learn section provides deeper insight into approval workflows, masking rules, and session replay.
Because hoop.dev is open source, you can review the implementation, contribute enhancements, or host the gateway in your own environment. The full source code is available on GitHub, where you’ll also find community discussions and deployment examples.
FAQ
Does hoop.dev replace my existing IAM policies?
No. Your identity provider still decides which service accounts exist and what tokens they can obtain. hoop.dev complements that by enforcing least privilege at the connection level, adding approval, masking, and audit capabilities that IAM alone cannot provide.
Can I use hoop.dev with any OIDC provider?
Yes. hoop.dev acts as a relying party for any OIDC‑compatible IdP, such as Okta, Azure AD, or Google Workspace. The provider issues the token; hoop.dev validates it and applies the policy.
What happens to credentials for the target service?
The gateway stores the target credentials securely and presents them only after the request has passed all policy checks. The calling automation never sees the raw secret, eliminating credential exposure in logs or code.
