Uncontrolled data flow from planner‑executor agents can expose confidential business information in seconds. Data classification is essential to prevent such leaks, as it tags each field with a sensitivity label that should be enforced at runtime.
Start by reviewing the open‑source repository on GitHub.
In many organizations the agent that runs a planning step and the executor that carries out the work share a single service account or static credential. The credential is often granted read‑write access to every database, storage bucket, and internal API the team owns. There is no label attached to the data that passes through the agent, and no real check that a piece of information classified as “PII” stays within a protected boundary. The result is a system where a single compromised workflow can sweep through production tables, copy customer records, and write them to an external endpoint without anyone noticing.
Consider a nightly batch that extracts orders, enriches them with customer profiles, and writes the result to a reporting store. The planner‑executor pair pulls the raw orders, joins on a customer table that contains social security numbers, and then pushes the enriched rows downstream. Because the agent runs with unrestricted privileges, the join operation can be altered by a malicious change in the planner script to include additional columns. No classification policy stops the extra fields from being exported, and no audit log shows who added the column. The data leaves the controlled environment unfiltered, creating a compliance breach before any human ever looks at the output.
Why data classification matters for planner‑executor agents
Data classification is the practice of assigning a sensitivity label, such as public, internal, confidential, or regulated, to each data element. Those labels drive downstream controls: masking of regulated fields, routing of high‑risk queries to a reviewer, and retention policies that differ by classification. For planner‑executor agents the challenge is twofold. First, the agent must be aware of the label attached to each column or document it processes. Second, the system must enforce the label at runtime, preventing accidental or intentional leakage.
Even when a team defines a classification scheme in a data catalog, the enforcement point is missing. The planner‑executor workflow still sends raw queries directly to the target database or API. The request bypasses any gate that could inspect the payload, compare it to the classification policy, and apply the required guardrails. In that state the classification policy is a document that no component actually enforces.
How hoop.dev provides the enforcement layer
hoop.dev is a Layer 7 gateway that sits between the planner‑executor agents and the infrastructure they access. The gateway is the only place where traffic can be inspected, classified, and acted upon. It receives the user’s OIDC token (the setup that decides who is making the request), but the token alone does not enforce any rule. The real enforcement happens in the data path, where hoop.dev examines each query, response, or API call.
When a planner‑executor request reaches the gateway, hoop.dev looks up the classification of the target columns in the policy store. If a query attempts to read a field marked “regulated,” hoop.dev automatically masks that field in the response. If a write operation would introduce a new regulated column, hoop.dev blocks the command and routes it to a human approver before it is executed. Every session, successful or blocked, is recorded by hoop.dev for replay, providing a complete audit trail that satisfies internal and external reviewers.
Because hoop.dev holds the credential for the downstream resource, the agents never see the secret. This isolation means that even if a compromised planner script tries to exfiltrate data, the gateway can still enforce masking or denial based on the classification policy. The result is a system where data classification is not just a label in a spreadsheet, but an active control enforced at the point of access.
Key enforcement outcomes
- hoop.dev masks regulated fields in real time, ensuring that downstream services only receive sanitized data.
- hoop.dev blocks commands that would violate classification rules and routes them for just‑in‑time approval.
- hoop.dev records each session, creating immutable evidence for auditors and incident responders.
- hoop.dev isolates credentials, so the planner‑executor agents never handle the secret directly.
Getting started
To adopt this model, begin with the getting started guide. Deploy the gateway in the same network segment as your databases and APIs, register the resources, and configure your classification policies in the feature documentation. The open‑source repository provides example manifests and Helm charts for production deployments.
FAQ
Does hoop.dev replace the need for a data catalog?
No. hoop.dev consumes the classification metadata that a catalog provides. It does not store the taxonomy itself, but it enforces the rules defined by the catalog at runtime.
Can existing planner‑executor scripts be used without changes?
Yes. Because hoop.dev proxies standard protocols (PostgreSQL, MySQL, HTTP, SSH, etc.), scripts continue to use their usual client libraries. The only change is the connection endpoint, which now points to the gateway.
What happens if an agent tries to bypass the gateway?
Since the credential lives only inside hoop.dev, any direct connection attempt without the gateway will fail authentication. This forces all traffic through the enforced data path.
