Do you know exactly which service account performed a given write in your internal SaaS platform?
Most teams hand out static API keys or shared service‑account credentials to scripts, CI pipelines, and automated bots. Those identities rarely rotate, often have broad permissions, and are stored in configuration files or secret‑management tools without any per‑request context. When a job fails, a data leak occurs, or an unexpected change appears, the logs you collect usually show only the service‑account name – not the specific automation, pipeline run, or CI job that issued the request. The result is an audit trail that is either missing, overly coarse, or impossible to reconcile with business‑level accountability.
Because the credential lives directly on the host that runs the automation, the request travels straight to the target database, HTTP endpoint, or Kubernetes API. No component in the path inspects the payload, masks sensitive fields, or forces a human approval before a destructive command is executed. The only place you could intervene – the network edge or a proxy – is typically left unused, so the request bypasses any guardrails you might have imagined.
Why non‑human identity alone isn’t enough
Introducing a non‑human identity, such as a dedicated service account for a backup job, does solve one problem: it stops the practice of sharing a single credential across unrelated workloads. The identity now tells you *who* initiated the request, and you can assign that account a tighter permission set. However, the request still reaches the target directly, and the system does not capture the full context of the operation. There is still no built‑in mechanism to record the exact query, the response payload, or the sequence of commands that led to a change. In other words, the audit trail remains incomplete.
From a compliance perspective, auditors expect evidence that shows not only *which* identity accessed a resource, but also *what* was done, *when*, and *under what conditions*. Without a dedicated enforcement point, you cannot guarantee that every interaction is logged, that sensitive fields are redacted, or that a risky operation is paused for manual review.
Putting the enforcement point in the data path
This is where hoop.dev enters the architecture. hoop.dev is a layer‑7 gateway that sits between any identity – human or non‑human – and the infrastructure you protect. By routing every connection through hoop.dev, you create a single, inspectable data path. The gateway can:
- Record each request and response, building a complete audit trail that ties the action back to the exact service‑account token used.
- Mask sensitive columns or fields in real time, ensuring that downstream logs never expose secrets.
- Enforce just‑in‑time approvals for high‑risk commands, pausing execution until a human reviewer signs off.
- Block commands that match a deny list before they reach the target, reducing blast radius.
Because hoop.dev operates at the protocol layer, it sees the full payload regardless of the underlying target – whether it is a PostgreSQL database, a Kubernetes API, or an internal HTTP service. The gateway therefore becomes the only place where enforcement can happen, and the source of truth for the audit trail.
hoop.dev logs every request and response and ties each log entry to the original non‑human identity, creating an audit trail that can be verified for integrity.
How the pieces fit together
The overall flow looks like this:
- Identity provider (OIDC/SAML) issues a token to the automation script.
- The script presents the token to hoop.dev when it opens a connection.
- hoop.dev validates the token, extracts the service‑account identity, and checks the request against policy rules.
- If the request passes, hoop.dev forwards it to the target; otherwise it blocks or routes for approval.
- Every request and response is logged, and the log entry is tied to the original non‑human identity, creating an audit trail that can be verified for integrity.
This pattern satisfies the three attribution categories:
- Setup: The OIDC/SAML token defines *who* is making the request.
- The data path: hoop.dev is the only point where the request can be inspected and controlled.
- Enforcement outcomes: The audit trail, masking, approvals, and command blocking are all produced because hoop.dev sits in that data path.
Getting started with hoop.dev
To adopt this model, start with the getting‑started guide. It walks you through deploying the gateway, registering a service‑account connection, and configuring OIDC authentication. Once the gateway is running, you can explore the full feature set in the learn section, where you’ll find detailed explanations of session recording, inline masking, and just‑in‑time approvals.
FAQ
How does hoop.dev capture actions from non‑human identities?
When a non‑human token is presented, hoop.dev validates it, extracts the service‑account identifier, and logs the entire request‑response exchange. The log entry includes the token’s subject, the timestamp, and the full payload, giving you a complete audit trail.
Can I keep using my existing service‑account credentials?
Yes. hoop.dev stores the target credentials internally, so your automation never sees them. You only need to supply the OIDC token that represents the service account; hoop.dev handles the rest.
Next steps
Explore the source code, contribute improvements, or raise issues on GitHub: hoop.dev repository.
