When every function call reliably respects a clear data classification policy, developers can trust that no personal or confidential value ever leaks to a language model.
In practice, however, many teams expose raw user inputs directly to LLMs via function calling. The payload often contains identifiers, financial numbers, or health details that have never been labeled, filtered, or logged. Without a guard at the call site, a single request can spread sensitive fields to downstream services, create audit gaps, and violate compliance mandates.
Why the current approach falls short
Function calling is designed for convenience. A developer defines a JSON schema, the model populates it, and the result is sent straight to the target API. The precondition for a secure implementation is a clear data classification framework that tells the system which fields are public, internal, or restricted. Even when that framework exists, the request still reaches the downstream endpoint unchanged, with no real‑time check, no masking, and no record of who supplied which value.
Because the enforcement point is missing, teams cannot answer questions such as: Who sent the social security number? Was the value approved by a manager? Did the system redact the field before storage? The answer is often “no” – the call bypasses any policy enforcement and proceeds unchecked.
Placing enforcement in the data path
The missing piece is a layer‑7 gateway that sits between the caller and the function endpoint. This gateway must be the only place where policy can be applied, because it is the only point that sees the full request before it leaves the trusted network. That is exactly the role of hoop.dev.
hoop.dev acts as an identity‑aware proxy for function calls. It verifies the caller’s OIDC or SAML token, determines the user’s groups, and then inspects the JSON payload. Based on a data classification policy, hoop.dev can:
- Mask or redact fields marked as restricted before the payload reaches the downstream service.
- Require a just‑in‑time approval workflow for high‑risk values.
- Record the entire request and response for replay and audit.
- Block calls that attempt to write prohibited data.
All of these outcomes happen because hoop.dev sits in the data path. The surrounding setup – the identity provider, the least‑privilege token, the service account – only decides who may start a request. Without hoop.dev, those decisions never translate into concrete enforcement.
How the pieces fit together
Setup: Teams configure an OIDC provider (Okta, Azure AD, Google Workspace, etc.) and grant the gateway a token that can read group membership. The token itself does not grant any data‑handling rights; it simply identifies the caller.
The data path: hoop.dev receives the function‑calling request, parses the JSON, and applies the classification rules. Because the gateway terminates the TLS session and re‑issues a new connection to the target API, it is the sole enforcement point.
Enforcement outcomes: hoop.dev masks restricted fields, logs who supplied them, and stores the session for later replay. If a request contains a field classified as “confidential”, hoop.dev either redacts it or routes it to an approval queue, depending on policy. The result is a complete audit trail that satisfies most regulatory evidence requirements.
Practical steps to get started
- Define a data classification schema that covers the domains your application handles – for example, public, internal, confidential, and restricted.
- Tag each function‑calling parameter with the appropriate classification in your API contract.
- Deploy hoop.dev using the getting started guide. The quick‑start installs the gateway and an agent inside your network.
- Configure classification policies in the feature documentation. Policies can specify masking rules, approval thresholds, and logging levels for each classification level.
- Update your client code to point at the hoop.dev endpoint instead of the direct API URL. No code change is needed beyond the endpoint address.
- Test the flow by sending a request that contains a confidential value. Verify that hoop.dev redacts the field and records the session.
After these steps, every function call will be subject to the same classification enforcement, and you will have an audit‑ready record of who sent what.
Benefits of a classification‑aware gateway
- Reduced blast radius: Sensitive data never leaves the network in clear text.
- Audit readiness: Full request and response logs satisfy evidence requirements for SOC 2, GDPR, and other frameworks.
- Dynamic risk management: Approvals can be introduced on a per‑field basis without rewriting application code.
- Consistent policy enforcement: All callers, whether human engineers or automated agents, pass through the same gate.
FAQ
Is hoop.dev required for every function‑calling use case?
No. The gateway is only needed when you must enforce data classification, masking, or audit. If your workload handles only public data, you can call the API directly.
Can I still use my existing identity provider?
Yes. hoop.dev acts as a relying party for any OIDC or SAML provider. It reads the token, extracts group claims, and applies the classification policy based on those groups.
What happens to a request that fails a classification check?
hoop.dev blocks the request and returns a clear error indicating which field caused the failure. If the policy requires approval, the request is queued for a designated reviewer.
How do I access the recorded sessions?
Recorded sessions are stored in the gateway’s backend storage. The UI and API let you search by user, time range, or classification level, enabling quick forensic analysis.
Start protecting your function‑calling pipelines today by deploying hoop.dev as the enforcement layer. The source code and contribution guide are available on GitHub.
Explore the hoop.dev repository on GitHub
