Skip to content

Tenant Model Policy

Tenant model policy is the admin-tier rule plane that decides which AI models an organization can invoke — above picker and routing.

The four layers

Tenant model policy sits between the model invocation request and the model itself. Map any harness against four stacked decision points before you treat per-tenant rules as the right surface:

graph TD
    A[Developer picker<br>Intent] --> B[Harness routing<br>Auto-select or pinned]
    B --> C[Org rules<br>Allow / deny per tenant]
    C --> D[Tenant catalogue<br>What the vendor exposes]

The picker reflects what a user wants. The harness routing layer decides what to call. The org rules decide what is permitted. The tenant catalog defines what exists at all for the contract. When routing logic and policy logic share a code path, the strict-priority guarantee disappears — and that guarantee is the whole mechanism (see Microsoft: Authorization and Governance for AI Agents).

The three implementations

Surface How rules attach Default stance Override depth
GitHub Copilot model rules Enterprise owner targets organizations; each model is Enabled (auto-on for all orgs) or Optional (orgs opt in) (GitHub Changelog 2026-05-26) An Enabled rule auto-applies to all orgs without per-org action Enterprise overrides organization (GitHub Docs: Copilot policies)
Claude Code availableModels Managed/policy settings file; arrays merge across user/project/managed surfaces (Claude Code: Model configuration) Default-allow; "Default" picker option always available regardless of availableModels Managed settings take highest priority
Cursor Enterprise admin controls Enterprise admins "whitelist or blocklist repos, models, and MCP servers" (Cursor Enterprise); Business tier exposes no equivalent surface, per Cursor Forum Default-allow except where admin restricts No documented per-team override; teams reach for gateway workarounds

The three diverge on a critical detail: Claude Code documents that "even with availableModels: [], users can still use Claude Code with the Default model for their tier" — an availableModels allow-list is not a deny-list. To pin model identity, admins must combine availableModels, model, and ANTHROPIC_DEFAULT_*_MODEL (Claude Code: Model configuration).

Why it works

The policy decision and the model invocation sit at distinct layers. So the rule engine can reject or substitute by tenant identity before the call reaches a model. Microsoft's runtime governance framing names the mechanism: "evaluate policies in deterministic order with tenant isolation and residency checks as hard deny first, preventing approval workflows from bypassing foundational security boundaries" (Microsoft: Authorization and Governance for AI Agents). The pattern holds because lower-priority surfaces — picker, env var, CLI flag — never see the request once the strict-priority managed setting denies it.

The mechanism collapses the moment policy becomes advisory. A picker that hides a denied model but leaves it reachable via --model flag is back to four uncorrelated decision points, not a policy plane.

When this backfires

  • Allow-by-default rules under regulated workloads: when an admin sets a model's stance to Enabled, that model is on for every organization until someone disables it (GitHub Changelog 2026-05-26). Note the counter-evidence on rollout: Copilot does not auto-enable a newly-launched model for every org by default. Admins must enable each new model, and a community request to make new models enabled-by-default is still open. So the live risk is a stale Enabled rule, not silent auto-onboarding. For tenants under data-residency rules (EU public sector, healthcare), pin explicit per-model rules rather than relying on either default.
  • Silent fallback hides denials: when the picker substitutes a default model without surfacing the denial reason, denial telemetry drops to zero and the developer reads the rejection as "the tool just feels worse." Silent fallback is independently an anti-pattern that distorts metrics and trust.
  • Picker drift after deprecations: an availableModels list that was correct on day one becomes a deny-list of retired model IDs over months. Without a lifecycle tied to model-deprecation calendars, the policy ages into silent denial of every selection. Pair with Model Deprecation Lifecycle.
  • Missing override depth: a security-research team needs a long-context Opus run that the cost-ceiling rule denies. Without a per-project or team-lead exception path, the request goes off-platform and the audit boundary collapses — the exact failure mode reported on the Cursor forum.
  • Carve-outs that defeat the rule: Claude Code's documented Default-option exception means a casually-applied availableModels setting does not deny anything for that tier (Claude Code: Model configuration). Admins reading the docs without the recipe — availableModels plus model plus ANTHROPIC_DEFAULT_*_MODEL — ship policy theatre.

Example

A Copilot Enterprise owner targeting a data-residency-constrained subsidiary with model rules sets each model's stance explicitly rather than relying on the Enabled default:

Before — single enterprise-wide setting, one model launch auto-onboards every org:

Enterprise: claude-opus-4-7 → Enabled
EU-Public-Sector-Org: claude-opus-4-7 → (inherited) Enabled

After — targeted rules, the regulated org opts in explicitly:

Enterprise: claude-opus-4-7 → Optional
US-Engineering-Org: claude-opus-4-7 → enabled
EU-Public-Sector-Org: claude-opus-4-7 → (no rule) disabled

The Claude Code equivalent in managed settings, pinning a Sonnet 4.5 build to a regulated tenant:

{
  "model": "claude-sonnet-4-5",
  "availableModels": ["claude-sonnet-4-5", "haiku"],
  "env": {
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-5"
  }
}

Without the env block, a user selecting Default in the picker would land on the latest Sonnet release, bypassing the version pin (Claude Code: Model configuration).

Key Takeaways

  • Tenant model policy is the layer above harness routing and below the vendor catalogue — failure modes come from collapsing it into either neighbour.
  • An Enabled Copilot rule applies a model to every org until disabled, so it is the wrong stance for regulated workloads — but note Copilot does not auto-enable newly-launched models, so the standing risk is a stale rule, not silent auto-onboarding. Treat every new model launch as untrusted until an explicit rule says otherwise.
  • Allow-lists in isolation are not deny-lists. Claude Code's availableModels requires model and ANTHROPIC_DEFAULT_*_MODEL companions to pin model identity.
  • Explicit denial signals matter more than the deny itself: silent fallback erases the audit trail and pushes developers off-platform.
  • Tie rule lifecycle to the model-deprecation calendar — without it, policy ages into accidental total denial.
Established — multiple independent sources Last reviewed: 2026-06-12
Feedback