Adding Agent Tool-Call Controls to Kong AI Gateway
Kong AI Gateway gives platform teams request-level controls such as authentication, rate limiting, and prompt and response handling. Tool-call controls decide something different: which tool an agent may invoke, with what arguments, under which identity, and whether a person must approve. To add them, place a policy enforcement point in the path of every tool call, deny unlisted tools by default, validate arguments, bind calls to the initiating identity, and record every decision as evidence.
Map the request paths and enforcement points
- 1
Call path
Check tool name, arguments, identity and scope before forwarding.
- 2
Return path
Inspect and redact tool results before they re-enter model context.
- 3
Approval path
Hold high-impact calls until a named approver decides.
- 4
Evidence path
Write each decision to durable storage outside the agent runtime.
Verify each control with a test case
- Out-of-scope tool: the agent requests an unlisted tool and the call is blocked.
- Malformed or injected arguments: parameters that violate the schema are rejected before forwarding.
- Over-limit volume: a loop exceeds the call cap and is throttled or stopped.
- Sensitive data: a protected value in a parameter or result is redacted, and the original is absent from stored records.
- Malicious tool output: instruction-like content in a result is sanitized before reaching the model.
- High-impact action: the call is held, a named approver decides, and the outcome is recorded.
Implement the controls in order
1. Tool allowlist
Grant each agent only the tools its task needs. Deny unlisted tools by default and segment agents so one compromise stays contained.
2. Argument validation
Validate parameters against an expected schema, including types, ranges and permitted values, before forwarding. Block calls that fail.
3. Identity and scope binding
Link each call to the initiating identity. Attenuate scope when authority passes to sub-agents or downstream services so it never exceeds the parent's.
4. Rate limits and caps
Set per-agent limits on tool calls, API usage and session duration, with throttles that cap the blast radius of runaway loops.
5. Redaction
Redact sensitive parameters before they leave and sensitive fields in results before they return. Treat all tool output as untrusted and strip instruction-like patterns.
6. Human approval
Define which actions escalate. Hold the call while approval is pending, and fail closed on timeout.
Why request-level controls leave a gap
A gateway sees traffic as requests. Authentication confirms who is calling, rate limiting caps volume, and prompt and response handling shapes what passes between application and model. These are necessary controls, and they work well at the request boundary.
An agent tool call is a narrower and more consequential event. The question is no longer whether this client may send a request, but whether this agent, acting for this user, may invoke this tool with these parameters right now. Request-level controls do not necessarily answer that question, because the tool name and arguments may sit inside a payload the gateway treats as opaque content.
Guidance from OWASP and NIST points to three distinct tool-call risks. Excessive agency is an agent induced to take high-impact actions beyond its intended authorization. Weak tool input validation can lead to unintended code or system command execution. Untrusted tool output, when acted on without review, lets a malicious payload trigger real-world actions. Each needs a different control: scoping and least privilege, argument validation, and output inspection.
Deciding what the gateway handles and what you add
Sort each control into one of two groups. The first group is request-level: authentication of the caller, volume limits on traffic, and handling of prompts and responses. The gateway is the natural home for these, and duplicating them elsewhere adds complexity without benefit.
The second group depends on understanding the tool call itself: per-tool and per-argument policy, scope attenuation across delegation, result-side redaction, and approval workflows. For each control in this group, ask whether your current deployment can evaluate it before the call reaches the downstream system, and whether the original sensitive value is kept out of stored records. Where the answer is no, add an enforcement point.
Trussed fits at that point. It enforces policy in the execution path at the tool call level across models, agents, tools and MCP servers: allow, redact, block, rate limit, and escalate for human approval. It is enforced at runtime, not reviewed after the fact, and it does not replace the gateway. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. The same policy plane covers 100+ models.
Capture evidence for every decision
Denied calls matter as much as allowed ones. Auditors and incident responders need to see what an agent attempted, what policy decided, and who approved exceptions. Monitoring for drift and unexpected tool use also depends on having this record.
Each decision record should contain the initiating identity and delegated scope, the tool invoked, the arguments in their redacted form, the policy and version that applied, the result (allow, redact, block, rate limit or escalate), the approver where one was involved, and a timestamp. Write records to storage the agent cannot modify, and set retention and export to match your own obligations.
Trussed generates audit-ready evidence as a product of enforcement, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST, so the record is created by the decision itself and not reconstructed afterward. It has run continuously in production at a regulated enterprise for 18+ months. Whichever tooling you use, test that a record exists for each case in the checklist above.
Tool call as the unit of control
Label: Identity
Description: Who initiated the task and what scope was delegated
Label: Tool and arguments
Description: Allowlist check and schema validation before forwarding
Label: Decision
Description: Allow, redact, block, rate limit or escalate
Label: Evidence
Description: A durable record of the call, the policy result and any approver
Add tool-call enforcement to your gateway path
See how policy is enforced in the execution path and how each tool-call decision produces audit-ready evidence.
See How Evidence Is ProducedHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.