When shadow AI respects JSON schema, developers see only the fields they need, sensitive data stays hidden, and every model request is captured for later review.
In practice, many teams hand a language model a raw JSON payload directly from a service. The model can read every key, including passwords, API tokens, or personal identifiers, and then echo those values in logs or downstream responses. Because the request bypasses any inspection point, a compromised model or a careless prompt can leak secrets without a trace.
Why shadow ai matters for JSON schema
The core problem is that JSON schema defines the shape of data, but it does not enforce who may see which properties. Without a gate, a model can request the entire document, extract credit‑card numbers, and store them in an uncontrolled cache. The organization gains no evidence that the model accessed the data, and there is no way to block or mask fields on the fly.
Real‑world incidents illustrate the risk. A data‑science team once fed a customer‑support chatbot the full order record, including SSNs, and the model later reproduced those numbers in a public forum. The breach was discovered only after a manual audit, weeks after the exposure. That gap existed because the request traveled directly from the application to the JSON service, never encountering a policy enforcement point.
What teams need is a control that checks each request against the schema, hides privileged attributes, and records the interaction. The control must sit on the path between the AI agent and the JSON service so that the model never sees the raw document. Even after the check, the request still reaches the target service, but the sensitive parts are already redacted and the transaction is logged.
Enter a layer‑7 gateway that acts as an identity‑aware proxy for JSON endpoints. hoop.dev is built to sit in the data path, inspect protocol traffic, apply inline masking based on schema rules, and capture a replayable session.
Setup: identity and least‑privilege grants
First, users and service accounts authenticate through an OIDC provider. The gateway validates the token, extracts group membership, and decides whether the caller is allowed to initiate a JSON request at all. This step only determines who may start a connection; it does not enforce data‑level policies.
The data path: where enforcement lives
Once the identity is verified, the request travels through the gateway before reaching the JSON service. Because the gateway terminates the client connection, it can parse the JSON document, compare it to the declared schema, and replace any field marked as sensitive with a placeholder. The masked payload is then forwarded to the downstream service, and the response follows the same path in reverse.
Because the gateway is the only place that sees the unmasked payload, any attempt by the model to bypass masking will be stopped before it leaves the gateway. This isolation also means that compromised agents cannot re‑configure the policy without a separate, tightly‑controlled deployment process.
Enforcement outcomes delivered by hoop.dev
- hoop.dev masks fields that match schema‑defined secrets, ensuring the model never sees raw values.
- hoop.dev records each request and response, creating an audit trail that can be replayed for investigations.
- hoop.dev can trigger a just‑in‑time approval workflow if a request attempts to access a high‑risk attribute, pausing the flow until a human reviewer approves.
- hoop.dev blocks commands that would modify the schema or retrieve entire collections without explicit permission.
These outcomes exist only because the gateway sits in the data path; removing the gateway would return the system to the original, unchecked state.
Beyond security, the recorded sessions provide compliance evidence for standards that require visibility into AI‑driven data access. Auditors can query the logs to confirm that no protected fields were exposed, and the just‑in‑time approvals demonstrate a documented review process.
Scaling to many services is straightforward. Each JSON endpoint registers with the gateway once, and the same masking policies can be reused across environments. Because the gateway is stateless with respect to the payload, horizontal scaling does not affect the consistency of enforcement.
For teams ready to adopt this approach, the getting‑started guide walks through deploying the gateway, registering a JSON endpoint, and configuring schema‑based masking rules. The open‑source repository provides the reference implementation and a community for extensions.
Explore the hoop.dev codebase on GitHub to see how the proxy integrates with existing OIDC providers and how you can customize masking policies for your own schemas.
FAQ
Does hoop.dev change the JSON service itself?
No. The service remains untouched; all inspection and masking happen in the gateway before traffic reaches the service.
Can I use hoop.dev with any OIDC provider?
Yes. The gateway is provider‑agnostic and works with any OIDC or SAML identity source that can issue JWTs.
What happens to audit data after a session ends?
hoop.dev stores a replayable log that can be queried by auditors or security analysts, providing evidence of what the model accessed and when.
How does just‑in‑time approval work for high‑risk fields?
When a request includes a property marked as high‑risk, hoop.dev pauses the flow and sends a notification to a designated reviewer. The reviewer can approve or deny the request from a web console; only an approved request is forwarded to the JSON service.
The gateway adds a small amount of latency while parsing and masking JSON, but because it runs close to the target service and scales horizontally, the impact is typically negligible for most workloads.
