Unmasked prompts let sensitive data leak directly to large language models, making data masking essential.
How teams handle ReAct today
Most engineering groups that experiment with ReAct embed raw user inputs, API keys, or internal identifiers straight into the prompt string. The agent then forwards the entire payload to the model without any transformation. Because the gateway is absent, there is no place to inspect the request, no audit of which fields were sent, and no way to prevent accidental exposure of personally identifiable information (PII) or secrets. In practice this means a single mis‑typed variable can appear in model logs, be cached by the provider, and become searchable forever.
That approach also makes it hard to enforce least‑privilege principles. The same ReAct routine that needs to read a customer name may also receive a credit‑card number, and the code does not differentiate between the two. When the model returns a response, the raw data travels back to the caller unchanged, so downstream services inherit the same risk.
Why data masking is the missing control
Data masking means replacing or redacting sensitive fields before they leave the trusted boundary, while preserving the overall structure needed for the model to operate. For ReAct this typically involves:
- Identifying PII, secrets, or proprietary identifiers in the prompt.
- Applying a policy that substitutes those values with placeholders or hashes.
- Ensuring the masked version is the only payload the model ever sees.
Even with a perfect masking policy, the request still travels directly from the client to the LLM endpoint. Without a dedicated gateway, you cannot record the session, require a human approval for high‑risk fields, or enforce inline blocking of disallowed commands. The enforcement outcomes, masking, approval, audit, must happen where the traffic is inspected.
hoop.dev as the data‑path solution
hoop.dev is built to sit in the data path between the ReAct client and the LLM service. It acts as an identity‑aware proxy that inspects each request at the protocol layer. Because hoop.dev is the only point that can see the clear payload, it can apply masking policies, log the full session, and optionally require just‑in‑time approval for flagged fields.
The setup phase uses standard OIDC or SAML authentication to decide who is making the request. That step defines the identity, groups, and least‑privilege roles, but it does not enforce any data protection on its own. The enforcement outcomes, masking of sensitive fields, recording of the exchange, and optional replay for audit, are all delivered by hoop.dev because it is the gateway that actually handles the traffic.
When a ReAct workflow initiates a call, the request is routed through hoop.dev. The gateway matches the payload against configured masking rules, replaces any identified secrets with safe placeholders, and then forwards the sanitized request to the LLM. The response follows the same path, allowing hoop.dev to mask any returned data that should not be exposed downstream. Every interaction is stored as a session record that can be replayed for compliance reviews.
High‑level steps to enable data masking for ReAct
- Deploy the hoop.dev gateway using the official getting‑started guide. The deployment runs a network‑resident agent close to your ReAct service.
- Register the ReAct endpoint as a connection in hoop.dev. Provide the target URL and the service account that hoop.dev will use to authenticate to the LLM provider.
- Configure OIDC or SAML identity providers so that each user or automation token is mapped to a role. This determines who can invoke the ReAct workflow.
- Define masking policies in the hoop.dev UI or configuration files. Policies describe which JSON fields, regex patterns, or token types should be redacted before the request leaves the gateway.
- Optionally enable just‑in‑time approval for high‑risk operations. When a policy flags a request, hoop.dev can pause the flow and present the details to an authorized reviewer.
- Test the end‑to‑end flow with a sample prompt that contains a credit‑card number and a secret API key. Verify that the logged session shows the masked values and that the LLM never receives the raw data.
All of the above is described in detail in the learn section, which walks through policy syntax, role mapping, and session replay.
FAQ
Does hoop.dev store the original unmasked data?
No. hoop.dev only records the masked payload that was sent to the LLM and the masked response it received. The original sensitive values remain in the client environment and are never persisted by the gateway.
Can I apply different masking rules per user or per ReAct workflow?
Yes. Because identity is resolved during the setup phase, hoop.dev can select a rule set based on the caller’s groups or the specific connection you register for a workflow.
Masking happens synchronously as the request passes through the gateway, so there is no added latency beyond the normal network hop.
Ready to try it out? View the source and contribute on GitHub.
