A newly hired contractor finishes a short‑term project, but the CI pipeline they left behind still has a token that can invoke any internal function the team has built. The next day a production alert triggers, and the pipeline silently calls a billing‑reset routine, wiping out weeks of revenue data. The incident highlights a classic gap: the system trusted the same credential to both request and execute a high‑impact operation.
Why segregation of duties matters for function calling
Function calling lets large language models (LLMs) or automation agents request concrete actions – for example, creating a user, adjusting a quota, or issuing a refund – by invoking a backend API or microservice. The power of this pattern is undeniable, but it also collapses several traditional control points into a single request flow.
Segregation of duties (SoD) is a principle that requires two or more independent actors to complete a critical transaction. In the context of function calling, SoD means that the entity that initiates a request should not be the same entity that authorizes or executes the most sensitive part of that request. Without SoD, a compromised credential can both ask for and perform a dangerous operation, eliminating the chance for a human review or a second‑factor check.
What to watch for
- Over‑broad tokens. Service accounts or CI tokens that have blanket execute rights across all functions make it impossible to enforce a split‑responsibility model.
- Lack of approval workflow. If a function call proceeds directly to the backend without any intermediate decision point, there is no opportunity to apply a “four‑eyes” review.
- No immutable audit trail. Without a recorded log of who called what, when, and with what payload, post‑incident forensics become guesswork.
- Unmasked sensitive fields. Functions that return secrets, tokens, or personal data should never expose that information to the caller unless explicitly allowed.
- Static access grants. Granting permanent rights to a function ignores the principle of least‑privilege and prevents just‑in‑time (JIT) elevation when a higher‑risk operation is needed.
These gaps are often invisible because the surrounding identity system – OIDC, SAML, or IAM – can confirm that the caller is legitimate. The identity layer decides who the request is, but it does not enforce how the request is processed. That is where a dedicated data‑path component becomes essential.
Enforcing segregation of duties with a gateway
hoop.dev is a Layer 7 gateway that sits between the caller (human, AI agent, or CI job) and the function endpoint. By placing enforcement in the data path, hoop.dev can apply the missing controls without changing the function implementation.
When a request reaches hoop.dev, the gateway can:
- Require a separate approval step before forwarding the call to the backend, ensuring that a second actor validates the intent.
- Record every function invocation, including caller identity, payload, and response, creating an immutable audit record for compliance and forensic analysis.
- Mask or redact sensitive fields in the response, so downstream callers never see secrets unless they have explicit clearance.
- Grant just‑in‑time credentials that expire after the call completes, eliminating static, over‑privileged tokens.
Because hoop.dev is the only point that can see the traffic, the enforcement outcomes – approval, audit, masking, and JIT credential issuance – exist only because hoop.dev sits in the data path. If the gateway were removed, the identity system alone would still allow the request, but none of the SoD controls would be applied.
How the model works in practice
1. Identity verification. The caller presents an OIDC or SAML token. hoop.dev validates the token and extracts group membership, which determines the caller’s baseline permissions.
2. Policy evaluation. A policy engine inside the gateway checks whether the request touches a high‑risk function. If it does, the request is paused for approval.