Enforcing per-team model allowlists in Kong AI Proxy Advanced

Start with team identity, not model names

An allowlist is only as reliable as the identity it is keyed to. Before editing any AI plugin configuration, decide how the gateway knows which team is calling. Kong offers consumers, consumer groups and per-route separation as building blocks, and an authentication plugin (key, JWT, OIDC or mutual TLS, depending on your standards) must establish the caller before any team-specific policy can apply.

Three decisions matter most. First, give each team its own credential or credentials. If one credential is shared across teams, the gateway cannot tell them apart and the allowlist becomes ambiguous. Second, decide whether teams map to individual consumers, to consumer groups that collect several consumers, or to dedicated routes. Groups suit teams with many services. Dedicated routes suit a small number of teams with distinct endpoints. Third, decide what happens to a request with no identity. It should be rejected, not routed to a permissive default.

This follows a general access control pattern. Policy is tied to attributes of the caller's credential, such as issuer, principal and audience, and the gateway acts as an enforcement point that allows or denies each request. Client-side settings, such as a model name hard-coded in an application, cannot be verified at the gateway and should not be treated as controls.

Scope plugin configuration and restrict models and providers

With identity established, define the allowlist as data before translating it into configuration. For each team, record the approved providers, the approved models and the person who approved them. That record becomes the source for the gateway configuration and for later reviews.

Then apply it in Kong. Each team's AI Proxy Advanced configuration should be attached at a scope that only that team's traffic can match, and its provider and model settings should name only approved values. Avoid wildcard or open-ended model settings. If a team is approved for several models, list each one deliberately, and check how requests are distributed or failed over among them, because every target in a balanced or fallback set is effectively part of the allowlist.

• Define each team's approved providers and models, with an approver and a change date.
• Enable authentication on every route that serves AI traffic.
• Attach one AI Proxy Advanced configuration per team scope, using consumer, consumer group or route as your design requires.
• Name only approved providers and models in that configuration, including any fallback or load-balanced targets.
• Keep the configuration declarative and in source control so changes are reviewed and versioned.
• Avoid attaching a permissive AI plugin configuration at a broader scope that could apply to a team's traffic.

Common failure modes

Most allowlist gaps come from a small set of causes. The first is a model named in the request body. Many clients send a model field, and your configuration must produce a deliberate outcome when that field differs from what the team is allowed. Acceptable outcomes are rejecting the request or using only the configured approved model. Passing the requested model through to the provider is not acceptable. Behavior can differ by provider and request format, so test each combination your teams actually use.

The second is plugin scope. When a team-level configuration and a broader configuration both exist, one of them must be the effective one for each request. Do not assume which. Remove overlap where you can, and prove the effective configuration with a test from each team's credential.

The third is routing breadth. A fallback target or a load-balanced set that includes a model outside the approved list defeats the allowlist even when the primary target is correct. The fourth is identity drift: a credential reused across teams, a consumer placed in the wrong group, or a route left without authentication. Each of these produces requests that look legitimate to the gateway but are attributed to the wrong team.

Evidence, change control and review

An allowlist that cannot be shown to reviewers is hard to defend. Three kinds of evidence are useful. The first is the configuration itself, versioned so you can show which team was permitted which model at any point in time. Guidance on AI configuration management points to versioning and tracking model configurations and related rules for this reason. The second is the test record: the matrix above, with outcomes, captured per team and per change. The third is the runtime record of allow and deny decisions. Decide in advance which fields your gateway logging must capture for a useful review, such as caller identity, route, requested model, resulting model and outcome, and check that they are present for both allowed and denied requests.

Treat adding a model or provider to a team's list as a reviewed change with defined approval criteria, in the same way you would treat a deployment approval. The change should carry the approver, the reason and the test results that show the new entry works and nothing else opened up.

Where gateway allowlisting ends

A gateway allowlist answers one question: which models and providers can this team's traffic reach. It does not evaluate what is sent in an individual interaction, what an agent does with the response, or which tools and MCP servers an agent calls afterward. Those decisions happen in the execution path, and a routing control at the gateway does not see them.

Trussed addresses that layer. It enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval, applied to individual interactions and tool calls. The enforcement generates audit-ready evidence of what was permitted and what occurred. This complements gateway routing controls rather than replacing them: Kong decides which model a team can reach, and runtime policy enforcement governs what happens within the interactions that follow.