Adding Human Approval for AI Agents Behind Azure API Management

Where approval sits relative to API Management

API Management is built to handle authentication, quotas, routing and request-level policies for the agents, tools and APIs published behind it. Those are properties of a request. Whether a specific agent tool call with real-world consequences, such as a write, a payment, a record change or an external message, should proceed without a person's approval is a different question. It depends on what the action is, who the agent is, what data is involved and what triggered the call.

Guidance on this is consistent on one point. A draft NIST publication on securing RESTful APIs describes a human-in-the-loop control for AI-agent calls to APIs: a manual confirmation step outside the AI agent's control for high-stakes calls. The placement matters. If the approval prompt lives only inside agent code, the agent, or content that manipulates it, can skip, reword or self-approve it.

A useful mental model is a spectrum. NIST's work on agent identity and authorization describes managing the range of actions an agent may take, from controlled human-in-the-loop approval to autonomous action. Approval is one outcome alongside allow, redact and block, assigned per class of action. API Management stays in front as the gateway, and the approval decision is made where each tool call can be evaluated individually.

Which tool calls should trigger approval

Start with an allowlist. OWASP's agentic guidance recommends limiting the actions an agent may take autonomously to an explicit allowlist, with anything outside it requiring explicit approval. This inverts the common failure mode, where approval is bolted onto a few known-dangerous calls and everything else passes silently.

Then classify by blast radius and irreversibility. OWASP DSOMM makes the distinction plainly: reading data is harmless, transferring money is not. It describes graduated human oversight assigned by class of agent action. A practical classification uses four inputs: the action type (read, write, payment, external message), the sensitivity of the data involved, the target system, and the identity and scope of the calling agent.

Input provenance is a fifth trigger. OWASP recommends human confirmation before high-impact actions, particularly when the action was prompted by externally retrieved content. A call that would be routine on a user's direct instruction deserves a second look when it follows a retrieved document or untrusted tool output.

For the highest-risk actions, consider dual authorization. NIST SP 800-53 describes it as requiring the approval of two authorized individuals. Decide in advance who holds approval authority, because approver roles are part of documented human oversight.

Choosing where to enforce approval

There are three plausible places to enforce approval. The right choice depends on whether the agent can bypass it and whether the decision can be evaluated per tool call with durable evidence.

• Agent application code: Closest to the action and easy to build, but it sits inside the agent's control and is reimplemented per agent. It conflicts with the guidance that confirmation happen outside the agent's control.
• API Management policies: Strong for authentication, quotas, routing and request-level rules applied uniformly. Use them to establish who is calling and what is permitted at the gateway. Stateful, asynchronous approval with an approver workflow and durable decision records is a different job.
• Enforcement in the execution path: Evaluates each interaction and tool call at runtime, can return approval as an outcome, and can attach evidence to the decision. This fits consequential calls where bypass resistance and an accountable record are required.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Its outcomes are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and enforcement generates audit-ready evidence mapped to frameworks including HIPAA, NYDFS, the EU AI Act and NIST. It can be deployed self-managed in the customer's cloud, with configurable retention and data residency.

In this architecture, API Management continues to handle gateway concerns while approval of consequential tool calls is decided in the path where each call can be evaluated. Trussed does not claim transaction-level governance or end-to-end tracing of agentic workflows. Its scope is the individual interaction and tool call.