What success looks like
When every API response contains only the fields a user is authorized to see, data leakage stops at the source. The system delivers trimmed, field‑level output, records who asked for what, and requires an explicit approval before any sensitive column is revealed. Engineers can trust that the least privilege principle is enforced automatically, without writing custom filters in each service.
Current reality with unfiltered output
Most production services expose full objects to callers. A request for a customer record often returns name, address, credit‑card number, and internal identifiers in a single payload. Developers typically rely on static service accounts that have blanket read access to the entire table. Because the request travels directly to the database, there is no point where the response can be examined for over‑exposure. The result is a high‑risk surface: a compromised credential instantly reveals every column, and compliance audits struggle to prove that only authorized fields were delivered.
Why field‑level control alone isn’t enough
Introducing a policy that says "only finance users may see credit‑card numbers" sounds like a fix, but the request still reaches the backend with full privileges. The backend executes the query, returns all columns, and the client decides what to discard. Without a gate in the data path, there is no guarantee that a rogue user cannot capture the full payload before it is filtered. Moreover, the system lacks a record of which fields were accessed, who approved the request, or whether the session was recorded for later review.
How hoop.dev enforces least‑privilege output
hoop.dev sits in the data path as a layer‑7 gateway. It receives the request after identity verification, inspects the protocol, and applies field‑level policies before the response leaves the gateway. The gateway can:
- Mask or redact sensitive fields in real time, ensuring only authorized data reaches the client.
- Require a just‑in‑time approval workflow for high‑risk columns, pausing the response until a designated reviewer grants access.
- Record every session, including the exact query, the filtered response, and the approving identity.
- Replay sessions for forensic analysis, giving auditors a complete trail of who saw what.
Setup determines who may initiate a connection. Engineers configure OIDC or SAML providers, assign groups, and provision service accounts with the minimal role needed to reach the gateway. These identities are the only factor that decides whether a request can start. The enforcement happens exclusively inside hoop.dev, because it is the sole point where traffic can be examined and altered.
Defining field‑level policies
Administrators create policies that map identity attributes to response fields. For example, a policy can state that users with the Finance group may see the credit_card_last4 column, while all other users receive a masked placeholder. The policy engine lives inside the gateway, so the backend never learns which fields are being concealed.