Many believe that function calling can be secured by simply trusting the caller’s token, but that approach ignores the need for enforceable, testable policies expressed as policy as code.
Function calling lets a service invoke a piece of code, often a microservice, a serverless routine, or an LLM‑driven tool, by sending a request that includes arguments and expects a response. The convenience is undeniable, yet the security surface expands with every new endpoint. A caller can be a human, an automated job, or an AI agent, each with different risk profiles. Without a systematic way to express and enforce constraints, teams end up relying on ad‑hoc checks, scattered configuration files, or manual reviews that are hard to audit.
What policy as code brings to function calling
Policy as code treats access rules, data‑handling requirements, and operational limits as version‑controlled, testable artifacts. Instead of a prose document that lives in a wiki, the policy lives in the same repository as the code that defines the function. This alignment gives three concrete benefits:
- Automated validation: CI pipelines can lint, test, and verify that a new function respects the declared policy before it reaches production.
- Clear audit trail: Each change to the policy is recorded in the version‑control history, providing evidence of intent and review.
- Dynamic enforcement: At runtime the system can read the policy definition and apply it to every request, ensuring that the declared intent is actually enforced.
The policy language typically expresses who may call, what arguments are allowed, and how responses must be treated. For example, a policy might forbid a function from returning credit‑card numbers, or it might require that any request originating from a non‑interactive service be approved by a human before execution.
Why a data‑path gateway is required
Even with policy as code in place, the enforcement point matters. The identity and token verification step (often an OIDC or SAML flow) tells the system *who* is making the request, but it does not guarantee that the request complies with the policy. If the enforcement logic lives inside the function itself, a compromised function can bypass the checks, and the policy evidence becomes unreliable because the function could tamper with logs.
The enforcement must sit on the path that the request travels, between the caller and the function runtime. Only a gateway that intercepts the wire‑level protocol can see the full request, apply masking, block disallowed commands, and trigger just‑in‑time approvals before the function sees the payload. Without that data‑path control, the policy remains a declaration without a technical guarantee.