Unencrypted traffic can expose proprietary prompts, model responses, and API keys, opening the door to data breaches, regulatory fines, and loss of customer trust.
In many organizations, ReAct services are called from internal scripts or CI pipelines that trust the corporate network, often neglecting encryption in transit.
Engineers often skip TLS because the service runs on a private subnet, they use self‑signed certificates, or they rely on a VPN that they assume is sufficient. The result is a direct socket connection that carries clear‑text JSON payloads across the wire, with no guarantee that a rogue host on the same VLAN cannot sniff the data.
Even when a team decides that encryption is a must, the typical fix is to add TLS at the application level and hope every developer configures it correctly. The request still travels straight to the ReAct endpoint, meaning there is no central point that can enforce the policy, record the handshake, or block a connection that deviates from the approved cipher suite. Without a gateway, the organization lacks visibility into who accessed the model, when, and what data was exchanged.
hoop.dev provides the missing data‑path control. It sits between the identity provider and the ReAct service, terminating inbound TLS, validating the cipher suite, and re‑establishing a trusted TLS session to the backend. Because the gateway is the only place that traffic flows, hoop.dev can guarantee encryption in transit for every request, regardless of how the client is configured.
Why the data path matters for encryption
The setup stage, assigning OIDC or SAML tokens, defining least‑privilege roles, and provisioning service accounts, decides who may initiate a request. Those decisions are necessary, but they do not enforce transport security. The enforcement point must be the gateway that actually carries the bytes, otherwise a misconfigured client could bypass TLS or downgrade to an insecure protocol.
When hoop.dev occupies that gateway position, it becomes the authoritative enforcer of encryption in transit. It checks that the client presents a valid TLS handshake, rejects connections that attempt to use deprecated versions, and logs the outcome of each negotiation. Because the gateway holds the credential for the ReAct endpoint, the client never sees the backend secret, reducing the attack surface.
Enforcement outcomes delivered by the gateway
- hoop.dev encrypts every request and response, ensuring data never travels in clear text.
- hoop.dev records each session, providing an audit trail that shows who accessed the model and what was transmitted.
- hoop.dev can mask sensitive fields, such as API keys or personally identifiable information, in the response before it reaches the client.
- hoop.dev supports just‑in‑time approval, allowing a security reviewer to approve high‑risk prompts on demand.
- hoop.dev blocks commands that match a denylist, preventing accidental execution of destructive operations.
All of these outcomes exist only because the gateway sits in the data path. Remove hoop.dev and the enforcement layer disappears, leaving the original direct connection and its unencrypted traffic.
How to adopt hoop.dev for ReAct
Start by deploying the gateway in the same network segment as the ReAct service. The official getting‑started guide walks you through a Docker Compose deployment, which includes OIDC authentication, TLS termination, and default masking policies. Once the gateway is running, register the ReAct endpoint as a connection in the hoop.dev UI or via the API. The gateway will store the backend credential, so client applications never need direct access.
From the client side, use any standard HTTP library to call the ReAct endpoint through the gateway’s address. Because hoop.dev performs the TLS handshake, you do not need to embed certificates in your code. The gateway will enforce the chosen cipher suite and record the session automatically.
For teams that need deeper insight, the learn section describes how to enable inline masking, configure just‑in‑time approval workflows, and integrate with existing alerting pipelines. All configuration is declarative and stored outside the gateway process, preserving the separation between setup and enforcement.
Frequently asked questions
Does hoop.dev replace TLS on the ReAct service?
No. hoop.dev terminates TLS at the gateway and then establishes a new TLS session to the backend. This double‑hop model preserves end‑to‑end encryption while giving the gateway a point of control.
Can I use existing certificates?
Yes. hoop.dev can import your organization’s certificates for termination, or it can generate self‑signed ones for internal testing. The important factor is that the gateway validates the client’s handshake against the chosen policy.
What audit data is available?
hoop.dev logs the identity of the requester, the time of the connection, the TLS version and cipher suite used, and a full transcript of the request and response (with optional masking). These logs can be shipped to your SIEM or retained for compliance evidence.
Next steps
Review the open‑source repository, explore the configuration examples, and spin up a test instance to see encryption in transit enforced automatically.
Explore the hoop.dev codebase on GitHub
