A model allowlist defines which models a given team, application or agent is permitted to call. A deny-list defines which are forbidden regardless of any allowlist. Together they are how a platform team stops an engineer routing production traffic to an unvetted, unapproved or expensive model — enforced at the gateway, so it applies whether or not the caller cooperates.
Why per-team is the unit that matters
A single organization-wide list fails in both directions. Set it by the most restrictive team and research cannot work. Set it by the most permissive and a regulated workload reaches a model nobody reviewed.
Scoping to the team resolves it: a research group gets the experimental models, a customer-facing application gets the two that passed review, and a workload handling regulated data gets only models approved for it. The same boundary usually carries spend caps and rate limits, because the team that needs a frontier model is rarely the team that needs unlimited access to it.
In Smartflow the boundary is the virtual key. A key is created with model_restrictions, request-per-minute and token-per-minute limits, and a spend cap, and a policy preset can be assigned to a team, a role or an individual key rather than managed per-policy. Details are in the API reference.
The property that decides whether it holds
Most implementations check the model named in the request. That is not sufficient in a gateway that also rewrites model choice for routing, failover or cost — because if the allowlist is evaluated before the rewrite, a permitted model can be rewritten into a forbidden one and the check has been bypassed by the system's own optimization.
Smartflow evaluates the allowlist on the rewritten model, after routing has decided what will actually be called. That ordering is the difference between a control and a formality, and it is worth asking any vendor which way theirs runs.
The second property is precedence. A deny-list entry must override an allowlist entry, or a broad permission silently defeats a specific prohibition. The same rule governs MCP tools, where disallowed_tools overrides allowed_tools — see MCP security.
Models are only half of it
Restricting which model a team may call does nothing about what that model is allowed to do once called. An approved model with unrestricted tool access is a larger exposure than an unapproved model with none.
The complete control is two lists on the same control plane: which models, and which capabilities. Vendors commonly ship one — gateway products do model allowlists, security products do capability guardrails — which leaves the buyer integrating two control planes and reconciling two audit trails. Governing both on one path is what makes the enforcement record answer a single question: what was this team permitted to do, and what did it do. See AI guardrails, agent authority scope and runtime governance, with the comparison view on all comparisons and cost implications in AI cost optimization.
Related terms
MCP security · Agent authority scope · AI guardrails · Runtime governance · Full glossary
Put this in the path of your own agents.
Policy enforced inline between your agents and every model and tool they reach, with a record bound to the human who owns it.
Request a Demo Read the docs