AI Provider Preferences

Configure a per-tenant allowlist and priority order for LLM providers that Guard uses across all AI capability workloads.

Overview

AI Provider Preferences gives tenant administrators control over which large language model (LLM) providers Guard is permitted to use and in what priority order. This setting is designed for organizations with vendor restrictions, procurement constraints, or compliance requirements that limit which AI providers may process their data.

When a policy is configured, Guard enforces it across every AI capability workload — including frontier, standard, fast, lite, and embedding model tiers.

How It Works

Guard selects models from an internal tiered registry. Without a provider policy, Guard chooses from all available providers at each tier. When the ai-provider-preferences setting is configured, Guard applies the following behavior:

Filters the model registry at every tier to include only providers on the allowlist.
Reorders candidates to match the priority sequence specified in the policy.
Walks the fallback chain — if the highest-priority provider is unavailable, Guard tries the next enabled provider in order, rather than falling back to any available model.

This ensures that Guard never silently routes workloads to a provider that is not permitted under your policy, even during a partial outage or capacity event.

Configuring Provider Preferences

The ai-provider-preferences setting accepts an ordered list of enabled provider identifiers. The order of entries determines fallback priority: the first entry is preferred; subsequent entries are used in sequence if earlier ones are unavailable.

Requirements

Constraint	Detail
Non-empty list	The policy must contain at least one provider.
Known providers only	Each entry must reference a provider recognized by Guard. Unknown identifiers are rejected at write time.
No duplicates	Each provider may appear at most once in the list.

Policies that violate any of these constraints are rejected before taking effect, preventing misconfigured rules from being silently applied.

Example policy (ordered list)

ai-provider-preferences:
  - anthropic
  - openai

In this example, Guard prefers Anthropic-hosted models at every tier. If Anthropic is unavailable, Guard falls back to OpenAI. Any providers not listed are excluded from selection entirely.

Scope and Coverage

The policy applies uniformly across all tiers that Guard uses internally:

Tier	Purpose
Frontier	High-capability reasoning tasks
Standard	General-purpose workloads
Fast	Latency-sensitive operations
Lite	Lightweight or high-volume tasks
Embedding	Semantic search and retrieval

There is no per-tier override; the same ordered allowlist governs provider selection at every tier.

Access and Permissions

Configuring AI provider preferences requires tenant administrator access. The setting is scoped to the tenant and applies to all workloads run on behalf of that tenant.

Relationship to AI Budget

AI Provider Preferences controls which providers are eligible for use. The AI Budget setting controls how much spend is permitted. Both settings can be active simultaneously; Guard honors the provider allowlist first, then applies budget enforcement within the permitted set.

Frequently Asked Questions

What happens if my allowlist contains only one provider and that provider is unavailable? Guard will not fall back to an unlisted provider. Workloads that require LLM inference will be unable to complete until the listed provider is available again.

Can I update the policy without downtime? Yes. Policy changes take effect for subsequent workloads. In-flight workloads are not interrupted.

Does this setting affect Marcus AI Assistant? Yes. The provider preference policy applies to all AI-powered features in Guard, including Marcus.

What provider identifiers are valid? Valid identifiers are the provider slugs recognized by your Guard instance. Contact your Praetorian representative or consult the tenant settings interface for the current list of supported providers.