Implementing agent tool-call controls in Azure API Management

Map agent tool calls to API Management constructs

Start with an inventory. List every tool an agent can call, what it reads or changes, and which backend operation performs the work. Classify each tool by risk. OWASP guidance states that medium, high, critical and unmapped tools require approval, and that classification alone does not grant permission to run a tool. Classification informs the policy. It is not the policy.

Then map the inventory onto API Management. A tool that fronts a REST backend maps naturally to an operation within an API. A group of tools intended for one class of agent maps to a product. Each agent or agent class receives its own subscription or credential, so traffic can be attributed to a specific caller. Policies attach at the API, operation or product scope and carry the controls described below. An MCP server exposed through the gateway is another surface for agent traffic, and it should receive the same identity, scoping and rate controls as any API.

Separate tool sets by trust level. An internal automation agent and a user-facing assistant should not share a product, because they do not share a trust boundary. Distinct products give you distinct scoping boundaries and make later review simpler.

Where API-level policy stops

Gateway policy evaluates a request to an operation. It sees the caller, the path, the headers and the body. It does not inherently know why the agent is making the call, what task it is performing, or whether the arguments are appropriate given the conversation that produced them. NIST resource-level authorization is expressed as permissions annotated on endpoints, which is endpoint granularity and not tool-intent granularity.

Three gaps follow from this. First, argument-level decisions: a transfer operation may be permitted, but a particular amount or recipient may not be. Schema validation checks shape and type, and it does not replace a decision about the value. Second, intent and sequence: individual calls can each be allowed while the chain of calls is not. Third, human approval. NIST describes human-in-the-loop as a manual confirmation step outside the agent's control for high-stakes calls, and a gateway that simply forwards or rejects requests has no native place to hold a call, route it to an approver and release it.

NIST guidance also calls for continuous runtime verification of each tool invocation based on current state, context and risk. Static per-product configuration cannot fully meet that on its own.

Design approval for high-risk calls

Define risk thresholds that trigger human review, and route each escalation to the person with the authority to decide. Tune the thresholds carefully. NIST warns about consent fatigue, where frequent escalation trains approvers to approve by habit. If everything escalates, approval stops being a control.

The approval itself must be something the agent cannot assert. OWASP states that a simple user_confirmed flag is insufficient. The approval must belong to the current actor and the exact tool call, remain valid, and not already be consumed. In practice that means the approval record carries the agent identity, the tool, a hash or copy of the arguments, an expiry, and a used marker that is set when the call executes. Authorization should be enforced in the execution component, outside the agent's context, and should fail closed when an approval requirement is missing.

Gateway policy and runtime enforcement compared

The table separates what request-level policy is suited to from what needs a decision point in the execution path.

• Caller authentication: Request-level: token validation at the gateway. Runtime: ties the verified agent identity to each tool decision.
• Tool authorization: Request-level: permission per API, operation or product. Runtime: per-tool, per-agent decisions evaluated at call time, failing closed for unknown tools.
• Rate limiting: Request-level: calls per period per caller. Runtime: limits applied per tool call and per interaction.
• Payload checks: Request-level: schema conformance and extra-field rejection. Runtime: decisions on argument values and redaction of sensitive content.
• Human approval: Request-level: not designed to hold and release a call. Runtime: escalate, bind approval to actor and exact call, and mark it consumed.
• Evidence: Request-level: records of requests and responses. Runtime: records of the decision, policy applied and approval state.

Define the evidence before you need it

An auditor will ask what an agent was allowed to do and what it did. Answer both halves. The first half is configuration evidence: the tool inventory, risk classes, agent-to-tool mappings, policy versions and approval thresholds in force at a given time. The second half is activity evidence: for each call, the agent identity, tool, outcome (allowed, blocked, redacted, rate limited or escalated), the policy that produced the outcome, a timestamp and a correlation identifier.

For escalated calls, retain the approval record: who approved, for which exact call, when, and whether it was consumed. Record blocked calls with the same care as allowed ones, since they show the controls working. OWASP recommends clear audit trails of agent decisions and actions.

Make the evidence durable. Operational diagnostics are usually tuned for troubleshooting, not for retention. Write decision records to storage whose retention period, access controls and tamper resistance you set deliberately, and confirm that sensitive argument values are masked before they are stored.

Where Trussed fits

Trussed is one way to add the runtime layer described above. It enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. Enforcement is at runtime, not reviewed after the fact.

The same enforcement produces audit-ready evidence, mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency. For a regulated enterprise running Azure API Management as its gateway, this complements the gateway controls above and does not replace them.