When function calling is locked down, organizations aim to inspect, approve, and record every external request, eliminating hidden lateral movement.
In that state, developers and automated agents can only invoke functions that have been explicitly permitted, and any data returned is scrubbed of secrets before it reaches the caller.
Achieving this requires a control point that sits between the caller and the function endpoint, can read the caller’s identity, and can enforce policies in real time.
Current risk landscape
Most teams treat function calling as a simple HTTP request from an application or an LLM prompt. The call travels directly to the backend service, often using a shared API key or a static service account token. Because the request bypasses any gateway, the backend sees the raw credential and the caller’s identity is lost. The function executes with full privileges, and the response is streamed back without any inspection.
This model creates three concrete problems. First, the shared credential can be copied and reused by any compromised component, giving an attacker a foothold that can be leveraged to reach other services. Second, there is no audit trail that ties a specific user or agent to a particular function invocation, making forensic analysis impossible after a breach. Third, sensitive fields such as passwords, tokens, or PII can be returned to the caller unchanged, exposing secrets to downstream systems that should not see them.
Why inspection alone isn’t enough
Adding a lightweight inspection layer that merely logs traffic does not solve the core issue. The request still reaches the target directly, meaning the target can still execute privileged operations before any policy is applied. Without a central enforcement point, each service would need to embed its own access checks, leading to inconsistent policies and a larger attack surface.
The missing piece is a mandatory data‑path gateway that can enforce least‑privilege, require just‑in‑time approval for risky calls, mask sensitive response fields, and record the full session for replay. The gateway must sit between the caller’s identity (derived from OIDC or SAML) and the function endpoint, ensuring that no request can bypass policy.
Introducing hoop.dev as the data‑path gateway
hoop.dev provides exactly that gateway. It proxies function‑calling traffic, validates the caller’s token, and applies policy before the request reaches the backend. Because hoop.dev is the only point where traffic passes, it can enforce every control without relying on the target to implement its own checks.
When a caller initiates a function, hoop.dev first verifies the OIDC or SAML token against the configured identity provider. The token’s groups and attributes are then matched against a policy that defines which functions the caller may invoke. If the call is classified as high risk, hoop.dev routes the request to a human approver before forwarding it.
Once the request is approved, hoop.dev forwards it to the function endpoint using a credential that only the gateway knows. The backend never sees the original caller’s secret, eliminating credential leakage.
Enforcement outcomes provided by hoop.dev
- hoop.dev records each function‑calling session, creating an audit trail that links a specific identity to the exact request and response.
- hoop.dev masks sensitive fields in the function’s response, ensuring that secrets never leave the gateway in clear text.
- hoop.dev blocks calls that exceed the caller’s allowed scope, preventing accidental or malicious privilege escalation.
- hoop.dev requires just‑in‑time approval for operations that touch critical resources, adding a manual review step only when needed.
- hoop.dev replays recorded sessions for forensic analysis, enabling security teams to reconstruct an attack path.
All of these outcomes exist because hoop.dev sits in the data path; they are not achievable by identity setup alone.
Getting started
Deploying hoop.dev is straightforward. The project offers a Docker Compose quick‑start that brings up the gateway and a network‑resident agent. The agent runs close to the function service and holds the credential needed to call the backend. For production environments, hoop.dev can be installed on Kubernetes or as a standalone binary. Detailed instructions are available in the hoop.dev getting started guide and the broader hoop.dev feature documentation.
After deployment, define policies that map identities to allowed functions, configure masking rules for sensitive fields, and enable session recording. The policy language is expressive enough to cover simple allow‑list scenarios as well as complex conditional approvals.
FAQ
How does hoop.dev differ from adding logging inside the function?
Logging inside the function only captures what the function chooses to emit. hoop.dev captures the entire request and response, regardless of the function’s internal logic, and can enforce policies before the request reaches the function.
Can hoop.dev protect against compromised service accounts?
Yes. Because the service account credential is stored only in the gateway, a compromised caller never sees the credential. hoop.dev can also require additional approval for calls that would normally use that account.
Is session replay safe for privacy?
Replay is stored in an audit‑only store that is accessible only to authorized auditors. Sensitive fields are masked at capture time, so replay does not expose secrets.
Take the next step
Explore the open‑source implementation on GitHub and start securing your function‑calling architecture today.
