Why policy as code matters for non‑human identities
How can you reliably enforce policy as code for service accounts and bots without leaking credentials?
Most teams treat non‑human identities like ordinary users: they bake static API keys into CI pipelines, grant wide‑area permissions to a single service account, and let the credential travel wherever the build job runs. The result is a sprawling attack surface where a compromised token gives an attacker unfettered access to databases, clusters, or internal APIs. Auditors rarely see what a bot actually did, because the connection bypasses any logging layer and the secret is never rotated in a controlled way.
Policy as code promises a declarative way to express who may do what, when, and against which resource. In theory you can write a rule that a backup service may only read from a specific bucket or that a CI runner may only execute SELECT statements on a reporting database. The missing piece is a place where those rules are evaluated. Without a dedicated enforcement point, the request still travels straight to the target, bypassing any approval workflow, masking, or audit capture.
What a solid control model needs
The first step is a trustworthy setup. Non‑human identities are provisioned through an identity provider that issues OIDC or SAML tokens. Those tokens identify the service account, carry group membership, and let the system decide whether a request is allowed to start. This step alone does not guarantee that the request will obey the fine‑grained policy you wrote.
The second step is a data path that sits between the identity and the target infrastructure. Only a gateway that can see the full wire‑protocol can enforce policy as code, mask sensitive fields, and record the interaction. Without that gateway, the request reaches the database, Kubernetes API, or SSH daemon directly, and the policy you authored never gets a chance to act.
Introducing hoop.dev as the enforcement layer
hoop.dev is a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH servers, and internal HTTP services. It sits in the data path, so every request from a non‑human identity must pass through it before reaching the target.
In the setup phase, you configure OIDC or SAML integration, register service accounts, and assign them to groups that match the policy you have expressed as code. hoop.dev validates the token, extracts the identity, and determines whether the request may proceed to the next stage.
Once the request reaches the data path, hoop.dev evaluates the policy as code against the actual command or query. If the operation matches an allowed rule, it is forwarded; if it violates a rule, hoop.dev blocks the command before it ever hits the backend.
Because hoop.dev is the only component that can see the traffic, all enforcement outcomes originate there. hoop.dev records each session for replay, masks sensitive fields in query results, requires just‑in‑time approval for high‑risk actions, and logs a complete audit trail that auditors can query. The agent that runs inside the customer network never sees the credential, and the backend service never knows which policy decision was applied – only hoop.dev knows.
How hoop.dev enforces policy as code for bots and service accounts
Write your policies in a declarative language (YAML or JSON) and store them in version control. Each rule can specify the identity group, the target resource, allowed operations, and optional conditions such as time‑of‑day or request origin. hoop.dev loads these policies at start‑up and refreshes them on demand.
- Command‑level allowlists: A CI runner may only execute SELECT on the analytics database. Any DROP or INSERT is blocked by hoop.dev.
- Inline data masking: When a backup service reads rows that contain credit‑card numbers, hoop.dev masks those fields in the response before they reach the agent.
- Just‑in‑time approval: A deployment bot that tries to apply a Kubernetes manifest to a production cluster triggers a workflow that requires a human approver. hoop.dev pauses the request until the approval is recorded.
- Full session replay: Every SSH command issued by an automation script is recorded. If a breach is discovered, you can replay the exact sequence of actions.
Because the enforcement happens in the gateway, you can retire ad‑hoc scripts that attempted to embed policy checks in each application. The single source of truth lives in the policy repository, and hoop.dev guarantees that the rules are applied consistently across all non‑human connections.
Getting started
Start with the getting started guide to deploy the gateway and register a service account. Then use the learn section to define your first policy as code and see how hoop.dev enforces it in real time.
Explore the source and contribute on GitHub.
FAQ
Can I use hoop.dev with existing CI pipelines?
Yes. The gateway works with any standard client (psql, kubectl, ssh, etc.). Your pipeline simply points to the hoop.dev endpoint instead of the raw target.
What happens if a policy is mis‑configured?
hoop.dev will reject the request and log the reason. You can view the denial in the audit trail and adjust the policy without impacting production services.
Do I need to change my application code?
No. Because hoop.dev operates at the protocol layer, applications continue to use their normal drivers and libraries. The only change is the network address they connect to.
