Non-Human Identities and Data Classification: What to Know

Non‑human identities that can pull data without oversight are a prime vector for data leaks, and data classification is essential to stop those leaks.

Service accounts, CI/CD runners, and AI agents often receive long‑lived credentials that grant them unrestricted access to databases, storage buckets, or internal APIs. Those credentials are usually provisioned once and never rotated, and the permissions attached are based on convenience rather than a careful analysis of what data the identity actually needs. When a build pipeline, for example, is granted full read access to a production PostgreSQL instance, any script that runs in that pipeline can retrieve rows containing personally identifiable information, credit‑card numbers, or proprietary business metrics. The same problem appears with AI assistants that query internal knowledge bases: without explicit controls, they can surface unfiltered sensitive content to downstream users.

This unrestricted access directly conflicts with a data classification strategy. Data classification is the practice of labeling data according to its sensitivity, public, internal, confidential, or restricted, and then applying controls that match each label. In theory, a service account that only needs to read public logs should never be able to query a table that holds customer SSNs. In practice, most organizations lack a technical enforcement point that can read the classification label on a piece of data and then decide whether to allow, mask, or log the request.

Why the current approach falls short

The typical workflow for non‑human identities follows three steps:

1. Provision a static credential such as an API key, password, or IAM role and embed it in a CI/CD configuration file or an AI‑agent secret store.
2. Grant the credential a broad set of permissions, often at the database or service level, to avoid permission‑ticket bottlenecks.
3. Run the workload, trusting that the identity will only request data it knows about.

This model leaves two critical gaps for data classification enforcement:

• No audit of what is actually accessed. The identity talks directly to the target system, so the organization cannot see which rows or fields were read, nor can it prove that a policy was respected.
• No inline protection. If a workload inadvertently requests a restricted column, the target system will return the raw value. There is no point where a classification label can trigger masking or a denial.

In short, the request still reaches the database, the API, or the storage bucket unchanged. The setup decides who may start the request, but it does not enforce what the request may retrieve.

Introducing hoop.dev as the enforcement layer

To bridge this gap, the access path must include a gateway that can read classification metadata and act on it before the data leaves the protected system. hoop.dev provides exactly that: a Layer 7 gateway that sits between non‑human identities and the infrastructure they target.

When a service account or AI agent initiates a connection, hoop.dev authenticates the identity via OIDC or SAML, extracts group membership, and then routes the traffic through its data‑path proxy. Because the proxy sits on the wire, it can inspect each query or API call, compare the requested resource against the organization’s data classification policy, and take one of several actions:

• Inline masking. If a response contains a field labeled “restricted,” hoop.dev can replace the value with a placeholder before it reaches the caller.
• Just‑in‑time approval. For high‑risk classifications, hoop.dev can pause the request and require a human approver to confirm the access.
• Session recording. Every interaction is logged and stored for replay, giving auditors a complete evidence trail that aligns with data classification requirements.
• Command blocking. Dangerous operations such as bulk export of confidential tables can be rejected outright based on the classification label.

All of these outcomes are possible only because hoop.dev occupies the data path. The identity setup alone cannot enforce them; the gateway is the point where policy meets traffic.

How the model works for non‑human identities

In practice, the workflow changes as follows:

1. Deploy hoop.dev as a container or Kubernetes pod near the target resource. The deployment includes the built‑in OIDC verifier, so no additional identity‑provider configuration is required beyond the usual client registration.
2. Register the target, for example a PostgreSQL instance, with hoop.dev, providing the credential that the gateway will use. The credential is stored only inside the gateway; the service account or AI agent never sees it.
3. Configure a data classification policy in the hoop.dev UI or via its API. Labels such as public, confidential, and restricted are mapped to masking rules, approval thresholds, and logging levels.
4. When a non‑human identity connects, hoop.dev validates the OIDC token, determines the identity’s groups, and then enforces the classification policy on every request.

This approach satisfies the missing enforcement point without altering the existing client tools. A CI job still runs the database client, a script still calls the AWS CLI, and an AI agent still sends HTTP requests, all through the hoop.dev proxy.

Benefits for a data‑classification program

• Reduced blast radius. Even if a service account is compromised, the gateway can prevent the attacker from exfiltrating restricted data.
• Evidence for auditors. The recorded sessions and approval logs provide concrete proof that classification policies were honored.
• Dynamic policy updates. Changing a classification label or masking rule takes effect immediately, without rotating credentials on every service.
• Least‑privilege enforcement. The gateway can deny access to data that the identity’s role does not cover, regardless of the static permissions granted on the underlying resource.

By placing policy enforcement at the network edge, organizations can finally align their non‑human identities with an effective data classification framework.

Getting started

To see hoop.dev in action, start with the getting‑started guide. The documentation walks you through deploying the gateway, registering a target, and defining a simple classification policy. For deeper insight into masking, approval workflows, and session replay, explore the feature overview.

Ready to try it yourself? The source code and deployment manifests are available on GitHub: github.com/hoophq/hoop.