A CI pipeline runs under a non-human identity that automatically writes structured output containing customer IDs to a log file. The job never logs in interactively, yet the data it produces travels across the network and can be intercepted or stored without any visibility.
Non-human identity is the core of the problem because it operates without human oversight.
Non-human identities, such as service accounts, automation bots, and CI jobs, are essential for modern development, but they also create a blind spot. Their output often includes JSON records, CSV exports, or metric payloads that embed personally identifiable information (PII) or proprietary secrets. When those streams reach a database, an API endpoint, or an SSH session, there is no guarantee that sensitive fields are redacted, that the command was authorized, or that a record of the interaction exists for later review.
Why non-human identity matters for structured output
Structured output is machine‑readable and therefore easy to index, forward, or cache. If a service account dumps a full customer record into a log, downstream tools may ingest that data and amplify the exposure. Because the identity is not a human, there is no natural checkpoint where an operator can verify the content before it leaves the system. This makes it difficult to enforce least‑privilege policies, to apply real‑time data masking, or to generate audit evidence that satisfies compliance audits.
In addition, many organizations treat service‑account credentials as static secrets. When those credentials are used to push structured data, any compromise of the account instantly grants an attacker the ability to exfiltrate or alter large volumes of information without triggering an alert.
Policy gaps when only setup is used
Typical setups rely on OIDC or SAML tokens, IAM roles, or service‑account permissions to decide *who* can start a request. Those mechanisms provide authentication and coarse‑grained authorization, but they stop at the edge of the target resource. The request then travels directly to the database, Kubernetes API, or SSH daemon without any inspection. As a result, there is no guarantee that the payload will be examined, that risky commands will be blocked, or that a human will approve a dangerous operation. The enforcement point is missing.
Even if a policy requires that only certain groups may write to a table, the database itself cannot verify that a JSON field does not contain a secret. Likewise, a Kubernetes admission controller cannot see the contents of a CSV file streamed over an exec session. Without a gateway that sits in the data path, those gaps remain unchecked.
Putting enforcement in the data path
This is where a Layer 7 gateway becomes essential. hoop.dev sits between the non-human identity and the infrastructure resource, acting as an identity-aware proxy that inspects traffic at the protocol level. Because every connection passes through the gateway, hoop.dev can apply policy decisions in real time.
hoop.dev records each session, masks sensitive fields in structured output, routes high‑risk commands to an approval workflow, and blocks disallowed operations before they reach the target. The gateway holds the credential required to talk to the backend, so the identity that initiates the request never sees the secret.
Key enforcement outcomes
- Session recording and replay for every non-human request, providing a complete forensic trail.
- Inline masking of PII or secret fields in JSON, CSV, or other structured formats before the data is stored or forwarded.
- Just-in-time approval workflows that pause risky commands until a human reviewer signs off.
- Command blocking that prevents execution of patterns known to be dangerous, such as destructive SQL statements or privileged shell commands.
All of these outcomes exist only because hoop.dev occupies the data path. Without the gateway, the same identities and IAM policies cannot enforce masking, approval, or recording on the fly.
Getting started
To try this approach, follow the getting started guide and explore the feature documentation on the learn page. The quick‑start uses Docker Compose to launch the gateway and an agent near your resource, then shows how a service account can connect through hoop.dev with standard clients.
FAQ
- Can existing IAM policies provide the same masking capabilities? No. Masking requires inspection of the data stream, which only a gateway positioned in the data path can perform.
- Does hoop.dev store credentials for the service accounts? The gateway holds the credential; the non-human identity that invokes the gateway never sees it.
- Is the solution compatible with CI/CD pipelines? Yes. Automation jobs can call the hoop.dev CLI or use standard client binaries; every request is still subject to the gateway’s policies.
- How does hoop.dev handle high-volume streaming data? The gateway processes the protocol layer in real time, applying masking rules and approval checks without adding noticeable latency.
Explore the source code on GitHub.
