An offboarded contractor still has a CI job that calls a third‑party payment API every night. The job uses a static API key that was never rotated, and the logs in the build system show only a success flag – no details about the amounts transferred or who initiated the call. This scenario illustrates a classic vendor risk problem, where unmanaged credentials expose the organization to financial and compliance hazards.
Function calling has become the lingua franca for modern services. A single microservice may reach dozens of external SaaS providers, data‑warehouses, or analytics platforms with a few lines of code. Developers treat the vendor endpoint as just another function, passing credentials that were generated once and embedded in source or configuration files. This convenience hides a dangerous reality: each call is a potential data exfiltration vector, a cost‑inflation risk, or a compliance breach.
In many organizations the same credential is shared across teams, environments, and even between production and staging. CI pipelines reuse the same secret for every build, and on‑prem scripts copy the key into temporary files for debugging. Because the call travels directly from the application to the vendor, there is no central point that can inspect the payload, enforce a policy, or capture a detailed audit record. If a malicious actor compromises a build agent, they inherit unrestricted, standing access to all integrated vendors.
The immediate need is clear: enforce least‑privilege, require just‑in‑time approval for high‑risk calls, and retain an audit log of who invoked which vendor function and with what data. Yet the request still has to reach the vendor’s endpoint over the network, and without a gateway there is no place to apply those controls.
hoop.dev sits in the data path between your application and the vendor endpoint. It acts as an identity‑aware proxy that terminates the client connection, applies policy, and then forwards the request onward. The authentication layer (OIDC or SAML) decides who the request is, but it does not enforce any vendor‑specific rule on its own.
Because hoop.dev is the only component that can see the traffic, it can enforce the missing controls. hoop.dev records each function‑call session, capturing the caller identity, timestamp, request parameters, and response payload. hoop.dev masks sensitive fields such as credit‑card numbers or personally identifiable information before they are stored or displayed, reducing exposure in logs and dashboards. hoop.dev blocks calls that match a high‑risk pattern – for example, a transfer amount that exceeds a configurable threshold – and returns an error to the caller without ever reaching the vendor. hoop.dev also routes risky calls into a just‑in‑time approval workflow, pausing the request until an authorized reviewer explicitly permits it.