Restrict model/provider access

Current rules and conditions

A matching active model/provider deny can refuse a supported Gateway request with HTTP 403. No matching deny means admission is allowed by default. An allow record does not grant human approval.

Budget records have their own configured scope, window, action, conditions, and exclusions. Confirm the supported subject and condition values for the deployment before authoring a rule. A group shown in a reporting chart is not automatically a policy scope.

Add a deny rule

You need the organization's Admin role and a live Gateway management view. Sample records do not permit writes.

1. Open Gateway → Access and select Add deny rule.
2. Choose Organization, Team or Member under Scope. For Team or Member, select the subject from the organization directory.
3. Enter an exact model ID, select a provider, or set both filters. At least one filter is required. When both are set, confirm that both match the intended request.
4. Select Add deny rule to save an active deny rule.
5. Confirm the saved scope, filters and active status in the refreshed list.
6. Test the intended supported request path and check for a correlated HTTP 403 refusal. The saved row alone does not establish application to a request.

Default admission remains allow when no active deny matches. Use the list's supported disable or delete action to stop an existing rule; verify the subsequent configuration and affected request path.

Routing is a separate control

Smart Router's allowed-model list restricts replacement targets. It is not a policy fence around an otherwise admitted original request: an incompatible replacement can preserve the original model. Use actual access rules for model/provider admission requirements.

See Routing controls and Policy boundaries.