AI Model Access Control: How to Decide Which Models Each Team Can Use

Last updated: October 2026

Tetrate Agent Router Enterprise gives each team only its approved models and keeps the rules with admins, before the most expensive model becomes everyone’s default.

AI model access control works in four layers in Tetrate Agent Router Enterprise. An admin approves models once in the organization catalog. Each team works in a project that lists only the models the team should use. The admin sets which model the team’s requests go to. Roles decide who can change any of these rules. Nobody gets a model they didn’t choose.

Most companies start the other way. Every team gets every model, and the invoice tells you later which team picked the expensive one.

Step 1: Approve Models Once in the Organization Catalog

The organization catalog is the list of every provider and model your company allows. In the Admin Console, Catalog → Providers stores the provider credentials, and Catalog → Models lists the models you can turn on. The model and provider guide covers the setup.

Enabling a model in the catalog approves the model. Granting the model to a project makes the model callable. Approval and access are two separate decisions, on purpose.

New models arrive through Tetrate’s published catalog. The tare api catalog sync command compares your catalog with the published list and shows what would change. A sync never deletes anything, and self-hosted data planes can run the sync every night. The catalog guide explains the dry run and the nightly job.

Step 2: Give Each Team a Project With Only the Models the Team Should Use

A project is the unit that keeps one team’s access apart from another’s. Each project has its own gateway address, its own API keys, and its own list of models. A key from one project is refused on another project’s gateway. A request for a model the project doesn’t have is refused too, per the key concepts page.

The Create Project wizard has five steps: Details, Members, Models, MCP servers, and Review. To add models later, switch the scope selector from Organization to the project, then use Add to project on Catalog → Providers and Catalog → Models. The project models guide walks through both.

David Wang’s post on keeping marketers away from Fable calls this the nuclear option. Leave the model out of the project catalog, and the team can’t call the model at all.

What you want	How to set the project	What the team sees
A team uses only approved low-cost models	Grant only those models	Only those models, in every tool
A team needs a frontier model for one workload	Grant the model to a separate project for that workload	The frontier model on that project’s keys only
A new team starts with a safe default	Grant one general model	One model, until you add more

Step 3: Set Which Model the Team’s Requests Go To

Granting models decides what a team can reach. You also decide which model answers when the team asks for a model by name.

Control	How the control works	Docs
Model alias	Apps ask for a name such as `chat-default`, and an operator maps the name to a model. Repoint the alias and every app moves with no code change.	Smart routing
100% traffic split on a key	Every request on the key goes to the model you pick, while the calling code keeps its old model name	Traffic splitting
Degrade gracefully	When a key’s budget runs out, requests move to a cheaper model you picked	Enforce budget caps

To move a whole team to a newer or cheaper model, change one setting. The team’s apps keep working.

Two tips. Give a team its own alias when you want to move that team on its own schedule. And set the split on each of the team’s API keys, so every app the team runs moves together.

For a full rollout method with canary splits and quality checks, see how to switch LLM models safely.

Step 4: Add People Through Your Identity Provider and Teams

Teams come from your directory. Each user belongs to one team, created under Directory → Teams. Team names show up in cost reports, so use real names such as Platform Engineering. The teams guide covers the setup.

Grant a team access to a project once under Directory → Access, and every team member gets that access. When someone joins or leaves the team in your directory, the change applies at their next sign-in. If you use Microsoft Entra ID, you can map Entra groups to teams and cost centers.

For how sign-in and role mapping work, see AI gateway security.

Roles Keep Admins and Developers Apart

Roles decide who can change the rules. Admin roles cover the whole organization or one project. Developers get access to their own project’s models and keys and nothing more. The roles guide lists every permission.

Role	What the role can change
Super Admin	Everything
Model Admin	The model catalog
Provider Admin	Provider connections and credentials
Billing Admin	Usage analytics and budgets
User Admin	Users and teams
MCP Admin	MCP servers
Viewer	Views settings and reports, with read-only access
Project admin	Members and keys inside one project
Project member	Use the project’s models and keys

Developers work in the Developer Console, and their access follows project membership. Read permissions control what each person sees in the console menus. Write permissions control what each person can create, edit, or delete. The server checks both permissions on every action.

Budgets Add a Spending Limit on Top of Model Access

Model access decides which models a team can call. A budget decides how much the team can spend. Budgets attach to a whole team, to each teammate, or to one API key, and offer three actions: Watch spend, Hard stop, and Degrade gracefully. The budget guide covers each one.

Read the team’s spend in cost analytics before you take a model away. The team you expect to be spending the most often isn’t.

How to Get Started

The organization catalog, projects, model aliases, traffic splitting, roles, and budgets all ship in Agent Router Enterprise today. Start with the model and provider guide, then create your first project with the project guide. To see team-level control on a live gateway, request a demo.

Agent Router Enterprise

Tetrate Agent Router Enterprise routes AI agent traffic across providers and your own models, with policy, cost controls, and audit on every request — in cloud, on-prem, or edge.

Learn more

Frequently asked questions

What is AI model access control? AI model access control decides which AI models each team, person, or app can call. In an AI gateway, an admin approves models, grants them to projects, and the gateway refuses requests for any model a project doesn’t have.

How do I restrict which LLM models a team can use? Put the team in a project and grant the project only the approved models. Every key from that project can reach only those models, in every tool the team uses.

How do I set a default model for a team? Point the team’s apps at a model alias and map the alias to the model you want. Or send 100% of a key’s traffic to one model. To move the team to a new model later, change that one setting.

What roles exist in an AI gateway? Agent Router Enterprise has organization roles such as Super Admin, Model Admin, Provider Admin, Billing Admin, User Admin, MCP Admin, and Viewer. Inside each project, admins manage members and models, and members use the project’s models and keys.

Who can change which models a team uses? Admins with the right role add models to a project or change the organization catalog. Developers use the models their project has.

What happens when I enable a model in the catalog? The model joins the organization catalog as an approved model. A team can call the model once an admin grants the model to the team’s project.