A Guide to Compliance Evidence in Non-Human Identities

How do you prove to an auditor that a service account or automated job never over‑reached its permission?

Why non‑human identities break compliance evidence

Most teams treat non‑human identities like any other credential: they create a long‑lived API key, embed a service‑account password in a CI pipeline, or grant a cloud role that never expires. The credential lives in a secret store, a configuration file, or even in plain text inside a container image. When the job runs, it connects directly to the target database, Kubernetes cluster, or SSH host. No central point observes the traffic, no guardrails intervene, and the only log that exists is whatever the target service decides to emit. Auditors therefore see a gap: they can verify that the credential existed, but they cannot see who used it, what commands were issued, or whether sensitive data was exposed.

This situation satisfies the first part of the compliance requirement, identity exists, but it fails the second part, evidence of actual usage. Without a trustworthy record, a regulator can question whether the organization truly enforced least‑privilege, whether data leaks were prevented, or whether the job behaved as intended.

What auditors need from non‑human identities

Compliance frameworks expect three artifacts for any automated identity:

• Identity provenance: a verifiable link between the service account and the business purpose that created it.
• Access trace: a detailed log that shows every connection, the exact query or command, and the user or system that initiated it.
• Data protection proof: evidence that any sensitive fields that appeared in responses were masked or redacted according to policy.

Auditors also look for approval trails when a high‑risk operation occurs, and for replayable session recordings that can be examined in case of an incident. The key is that all of these artifacts must be generated at the point where the request traverses the network, not after the fact in a downstream log aggregation system that the service itself controls.

How hoop.dev creates that evidence

hoop.dev sits in the data path between the non‑human identity and the target resource. When a service account authenticates via OIDC or SAML, hoop.dev validates the token, extracts group membership, and then proxies the connection to the backend. Because the proxy is the only path the traffic can take, hoop.dev can enforce every guardrail in real time.

• Session recording: hoop.dev records each protocol exchange, preserving a replayable artifact that shows exactly what the automated job sent and what the backend returned.
• Inline masking: hoop.dev inspects response payloads and redacts fields such as credit‑card numbers, SSNs, or API secrets before they reach the caller, while retaining a log of the original values for audit purposes.
• Just‑in‑time approval: when a request matches a high‑risk pattern, e.g., a DROP DATABASE command or a privileged Kubernetes exec, hoop.dev pauses the operation and routes it to an approver. The approval decision is stored alongside the session record.
• Command blocking: hoop.dev can reject dangerous commands outright, ensuring that a mis‑configured automation never performs a destructive action.

All of these outcomes are generated by hoop.dev, not by the underlying service. If you removed hoop.dev from the path, the session would proceed without any of the above evidence, leaving the auditor with a blind spot.

Because hoop.dev holds the credential for the target connection, the service account never sees the secret. This design satisfies the principle of “the agent never sees the credential” while still allowing the job to act on behalf of the identity.

To get started, follow the getting‑started guide. The documentation walks you through deploying the gateway, registering a non‑human identity, and defining masking policies. For deeper insight into the feature set, explore the learn section of the website.

FAQ

Can hoop.dev work with existing service accounts?

Yes. You register the existing credential in the gateway configuration, and hoop.dev will proxy all traffic for that account, adding recording and masking without requiring code changes.

Do I need to change my CI/CD pipelines?

No. The pipelines continue to use the same client binaries (psql, kubectl, ssh, etc.). The only change is the endpoint address, which now points to the hoop.dev gateway.

How long are session recordings retained?

Retention is configurable in the gateway settings. You can align the policy with your organization’s data‑retention requirements, ensuring that auditors have access to the evidence for the required period.

Ready to see the code, contribute, or run a self‑hosted instance? Explore the repository on GitHub.