Adding Model Context Protocol permissions to Azure API Management

What permissions mean in an MCP context

An MCP server exposes tools that an AI client can call. Authenticating that client answers who is connecting. It does not answer what the client may do once connected. A permission, in the sense used here, is a rule that binds an identity to a specific tool and, where needed, to constraints on the arguments and the conditions of the call.

NIST guidance on API protection offers a useful frame. It says each service behind an API endpoint should perform two levels of authorization: service authorization, which asks which workload or client may call, and end-user-to-resource authorization, which asks on whose behalf the call is made and against which object. For MCP, the first maps to the agent or client identity and the second to the delegated user. Both need to be represented at the point of decision.

The same guidance recommends annotating endpoints with the permissions they require, so that tooling can run authorization checks consistently. The MCP analogue is a permission attached to each tool definition. Attribute-based access control extends this: decisions evaluate attributes of the subject, the object, the requested operation and, in some cases, environment conditions against policy. That is a workable model for conditions such as caller, tool, parameters and context.

What the gateway covers and where tool-call decisions begin

An API gateway is a natural place for coarse controls. The practical question is which decisions can be expressed using what the gateway evaluates, typically the path, headers and token claims. Tool-level decisions often depend on attributes deeper in the request.

• Authentication and token validation: Gateway: well suited. Validate issuer, signature, expiry and audience before traffic reaches the MCP server. Tool-call level: consumes the validated identity but adds no new checks here.
• API-level policy: Gateway: allow or deny by route, client or token claim. Tool-call level: needed when several tools sit behind one endpoint and a path rule cannot tell them apart.
• Rate limiting: Gateway: limits per client or subscription. Tool-call level: limits per tool, per identity or per sensitive operation.
• Parameter and context conditions: Gateway: possible only if the arguments are visible to policy and the rules stay maintainable. Tool-call level: evaluates parameters, delegated user and environment against attribute-based policy.
• Escalation and redaction: Gateway: generally outside API-level policy. Tool-call level: can route a call for human approval or alter content before it reaches the tool.
• Decision evidence: Gateway: request records. Tool-call level: records of the decision, the attributes evaluated and the policy version.

Evidence a regulated enterprise should be able to produce

Authorization design is only half the requirement. A regulated enterprise may be asked to show what an AI client was allowed to do and what it did. Request-level gateway records show that a call arrived and was routed. They do not by themselves show which permission applied to a tool call, which attributes were evaluated, or why a call was denied.

The two-level authorization model implies that a useful record names both the calling agent and the end user. Because attribute-based decisions depend on attributes and environment, reconstructing a decision generally needs the evaluated attributes and the policy version retained with the outcome. That is a design inference rather than a fixed requirement, and it is a sound basis for specifying what your evidence should contain.

NCCoE concept and working-session material on AI agent identity and authorization, which references OAuth 2.0 and MCP and pairs delegation controls with accountability for automated systems, remains in draft form as of November 2026. It is useful direction for design, not a binding obligation.

Where Trussed fits: runtime enforcement at the tool call

Trussed addresses the tool-call 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. Outcomes are allow, redact, block, rate limit or escalate for human approval, enforced at runtime, not reviewed after the fact.

Because enforcement happens in the path, it generates audit-ready evidence continuously, 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. It sits alongside gateway controls such as authentication, token validation and API-level policy rather than replacing them.