Misclassifying data before you split it can leak secrets across system boundaries.
Data classification is the process of assigning a sensitivity label to each piece of information. Labels such as public, internal, confidential, or regulated dictate how the data may be stored, transmitted, and processed. When classification is applied consistently, security teams can automate handling rules and auditors can verify compliance.
Chunking is the practice of breaking a large dataset into smaller pieces for parallel processing, streaming, or storage limits. Machine‑learning pipelines, ETL jobs, and API pagination all rely on chunking to keep workloads manageable.
The danger appears when chunking occurs without regard to the classification attached to each record. A confidential customer identifier might be split across dozens of small payloads that travel through different services. Each micro‑service then treats the fragment as if it were unmarked, increasing the chance that a log, cache, or backup will expose the data. Regulators consider that a breach of data‑handling policy, and incident responders spend hours stitching fragments back together to assess impact.
To avoid that scenario, organizations need a control point that can read the classification label, decide whether a particular chunk is allowed, and enforce the appropriate protection before the data leaves the source. The control point must sit on the data path, not merely at the authentication layer, because only the gateway can see the actual payload that is being chunked.
Enter a layer‑7 access gateway that proxies connections to databases, Kubernetes, SSH, and HTTP services. This gateway sits between the client that requests a chunk and the backend that serves it. By placing enforcement in the gateway, you guarantee that every chunk passes through a single, auditable checkpoint.
hoop.dev fulfills that role. It verifies the user’s identity with OIDC or SAML, then inspects each protocol message. When a request to read a set of rows arrives, hoop.dev checks the data classification attached to those rows. If the request includes confidential fields, hoop.dev masks those fields in the response, records the exact query and the user who issued it, and, if the data is highly regulated, routes the request to a human approver before it proceeds.
Because hoop.dev lives in the data path, it can produce enforcement outcomes that would be impossible with identity checks alone. It records every chunking session, so auditors can trace who accessed which slice of data and when. It applies inline masking so that downstream services never see raw confidential values. It can require just‑in‑time approval for chunks that cross a sensitivity threshold, and it blocks commands that would extract entire tables of regulated data.
The surrounding setup remains essential but insufficient on its own. You still need to provision OIDC clients, assign group memberships, and grant least‑privilege roles to the gateway. Those steps decide who may start a connection, but they do not enforce how the data is handled once the connection is active. hoop.dev provides the enforcement layer that turns those identities into concrete protection.
In practice, you start by classifying your data at the source, database columns, message fields, or object tags receive a classification label. Then you configure hoop.dev with classification rules that map labels to actions such as mask, audit, or require approval. When a client issues a chunk request, hoop.dev evaluates the request against those rules, applies the appropriate action, and streams the result back to the client. The client sees only the data it is permitted to see, and the organization retains a complete audit trail.
This approach reduces blast radius because a compromised client can only retrieve masked fragments. It also satisfies compliance programs that demand evidence of who accessed regulated data and how it was protected. The audit logs generated by hoop.dev can be fed into SIEMs or retained for SOC 2 Type II examinations.
For a step‑by‑step walkthrough, see the getting started guide. The feature documentation explains how to define classification policies, enable inline masking, and configure just‑in‑time approvals.
Explore the source code and contribute on GitHub.
How data classification shapes chunking policies
When you tag each column or field with a classification, the gateway can automatically decide whether a chunk containing that column should be allowed. For example, a query that selects only public columns can pass without interruption, while a query that includes a confidential column triggers masking. The policy is expressed once, and the gateway enforces it consistently across every client and every chunk.
Why the gateway must sit in the data path
Only a component that sees the actual payload can enforce masking and approval. An identity provider knows who you are, but it does not see the rows you are pulling. By placing hoop.dev between the client and the backend, you guarantee that every piece of data is examined before it leaves the trusted zone.
Key enforcement outcomes
- Inline masking of confidential fields during chunk extraction.
- Session recording that captures the exact query and result set.
- Just‑in‑time approval workflow for high‑sensitivity chunks.
- Command blocking when a request would exceed the allowed classification level.
FAQ
Do I need to change my existing applications?
No. Applications continue to use their standard client libraries (psql, kubectl, ssh, etc.). The only change is that they point to the gateway endpoint instead of the raw backend.
Yes. hoop.dev reads classification labels from database metadata, object tags, or a custom policy file. You simply map those labels to the desired enforcement actions.
Is the audit data stored securely?
hoop.dev writes session logs to a storage backend you configure. The logs are immutable from the perspective of the gateway, and you can forward them to any tamper‑evident store of your choice.
