Enforcing per-team AI policies with Azure API Management products and subscriptions

Model teams as products and subscriptions

When several internal teams share Azure-hosted model endpoints, each team needs its own access scope, quota, and usage rules. In Azure API Management, the product is the natural unit for that boundary. A product groups one or more APIs and carries the policies that apply to everyone who consumes them through it. A subscription ties a consumer to a product and produces the identifier your gateway sees on each request.

Start by deciding what a team means for policy purposes. If a team has one risk profile and one set of limits, one product is enough. If a team runs a production assistant and an experimental sandbox with different quotas and allowed models, create two products. A product should map to a distinct policy outcome, not to an org chart box. Products that differ only in name add maintenance without adding control.

Issue subscriptions per application or environment, not per team. A team-wide subscription means one leaked or misused credential affects every workload, and usage cannot be attributed below team level. Per-application subscriptions let you revoke one consumer, measure it separately, and still inherit the team's product policy.

This follows a pattern NIST describes for rate limiting: different usage limits by role or subscription level. The specific quotas must be set by your own capacity and risk decisions.

Attach policies at the right scope

Policies in API Management can be defined at several scopes: global, product, API, and operation. Narrower scopes can build on broader ones, so the design question is which rule belongs at which level. A useful rule of thumb is to put a rule at the broadest scope where it is true for every consumer beneath it.

Keep the policy per team at the product scope, because that is where team differences live. Keep the properties of the model API at the API scope, because they apply to every team. Use the operation scope sparingly, for cases such as a different limit on an embeddings operation than on a chat completion operation. Check how each scope combines with its parent so that a narrow policy does not silently drop a broad one.

• Global scope: Baseline rules for all traffic, such as required headers and consistent error handling for denied requests.
• Product scope: Per-team token limits, rate limits, quota, allowed callers, and which backend deployment the team is routed to.
• API scope: Rules tied to the model API itself, such as authentication to the backend and request shaping.
• Operation scope: Exceptions for a single operation, used only where behavior must differ.

Per-team token limits, rate limits, and routing

AI traffic is not well described by request counts alone. A single request can consume very different amounts of model capacity depending on prompt and completion size. A token limit policy applied at the product scope, keyed on the subscription, lets you give each team and each application a ceiling that reflects model consumption. A request rate limit remains useful as a separate control against bursts and runaway loops. Using both gives you two independent dimensions to tune per team.

Backend routing is the other per-team lever. Products can steer a team to a specific model deployment, so a team approved for one model is not routed to another. Treat this as access scoping by routing, and confirm that a team cannot reach a different deployment by calling the backend directly. Backend endpoints should accept traffic only from the gateway.

If you cache responses, scope the cache so one team's responses are never served to another. Caching that crosses product boundaries undermines the very separation the product model is meant to create.

Define each team's limits and allowed access as explicit policy kept in version control, not as informal agreement. NIST's attribute-based access control guidance makes the same point: policies should be machine-enforceable and held where enforcement mechanisms can consume them.

Strengthen identity beyond subscription keys

A subscription key is a shared secret. Whoever holds it can present it, and the key says nothing about which person or workload is actually calling. Keys get copied into configuration files, shared in chat, and reused across services. As team identity, a key is a reasonable attribution and metering handle but a weak proof of who is calling.

Pair the key with stronger identity. Validating a Microsoft Entra ID token at the gateway lets the policy check that the caller is an authenticated principal and read claims such as application identity or group membership. You can then require that the identity on the token is permitted for the product the key belongs to, so a stolen key alone is not sufficient. On the backend side, having the gateway authenticate to the model endpoint with a managed identity removes model-endpoint keys from consumers entirely, so only the gateway can call the model.

This is consistent with NIST zero trust guidance, which describes identity-tier policies based on service and user identities and calls for multi-tier policy rather than reliance on a single factor. It also supports applying the same controls to internal consumers as to external ones. Internal callers are in scope for runtime API protection on every request.

Where API-layer controls stop

API Management policy operates on requests as API calls: who is calling, how often, how many tokens, and where the request goes. It is the right place to enforce those properties. It is not designed to make decisions about what an AI interaction means.

Three requirements typically fall outside it. The first is content-level redaction: removing sensitive values from a prompt before it reaches a model, or from a response before it reaches the user. The second is tool-call control: deciding whether an agent may invoke a particular tool with particular arguments, which happens inside the agent's execution rather than at the model API edge. The third is human approval: pausing a consequential action until a person approves it. Writing these as gateway policy tends to produce brittle pattern matching and still leaves tool and agent traffic uncovered.

Evidence has a similar boundary. Gateway telemetry can show which subscription called which API and how much it consumed. That supports a statement of what each team was able to reach and how much it used. It does not by itself show what an individual interaction contained or why it was allowed. NIST guidance on API protection expects telemetry sufficient to confirm that policies are being enforced, so decide up front what per-team record you need and whether the gateway alone can produce it.

Extending enforcement into the execution path

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, at the level of individual interactions and tool calls. Decisions are allow, redact, block, rate limit, or escalate for human approval, enforced at runtime, not reviewed after the fact. This complements the Azure API Management pattern rather than replacing it. The gateway holds the team boundary and quota, and execution-path enforcement handles the content and tool decisions the gateway cannot.

Enforcement produces audit-ready evidence of what was permitted and what happened, mapped to HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. Trussed is self-managed in the customer cloud, with configurable retention and data residency, which matters to a regulated enterprise that needs evidence to stay in its own environment.