Model Governance

Model access policies, data sovereignty, and cost caps

Admin Guide: Model Governance and Policies

This guide is for platform administrators who manage tenant-level model access policies, cost controls, data sovereignty requirements, and FinOps monitoring in the Admin Console.

Model access control is Dimension 4 of the platform's access control model. Tenant-level policies set the outer boundary; agent-level policies (configured by builders) can only further restrict within what the tenant allows.

Where to manage: Admin Console > Tenant Manager (/admin/tenants) > Model Policy section, Admin Console > Security Center (/admin/security) > Agent -> Model Access tab, and Admin Console > FinOps Center (/admin/finops).

Table of Contents

• Overview: Model Access Enforcement
• Tenant-Level Model Policies
• Policy Presets
• EU-Hosted Only Configuration
• Cost Caps
• Model Allow and Deny Lists
• Model Tags and Tag-Based Filtering
• Fallback Chain Configuration
• Routing Rules
• FinOps Monitoring and Cost Attribution
• Compliance Considerations
• Cedar Policy Examples

Overview: Model Access Enforcement

Every LLM call from the platform flows through the Model Access PEP (Policy Enforcement Point) before reaching T-Systems AIFS. The PEP evaluates both tenant-level and agent-level policies:

Agent's LLM call (model: "o3", messages: [...])
         |
         v
   Model Access PEP
         |
   1. Look up agent's AgentModelAccess policy
   2. Look up tenant's TenantModelPolicy (tenant-level overrides)
   3. Is "o3" in allowedModels or matches allowedModelTags?
   4. Is "o3" in deniedModels? (deny always overrides allow)
   5. Check cost guardrails (daily spend cap, per-request cap)
   6. Cedar PDP evaluates full context
         |
    ALLOW -> forward to AIFS (https://llm-server.llmhub.t-systems.net/v2)
    DENY  -> return error to agent
             if fallback model configured and allowed -> retry with fallback
             log denied access in audit trail

Key principle: Tenant policies define the outer boundary. Agent policies can only restrict further, never expand beyond what the tenant allows.

Tenant-Level Model Policies

Each tenant has a TenantModelPolicy that governs all agents in the tenant.

TenantModelPolicy Schema

interface TenantModelPolicy {
  allowedModels?: string[];            // Explicit model IDs allowed for this tenant
  deniedModels?: string[];             // Explicit model IDs denied for this tenant
  euHostedOnly: boolean;               // Restrict all agents to EU-self-hosted models
  defaultMaxCostPerRequest: number;    // Default per-request cost cap for agents
  defaultMaxCostPerDay: number;        // Default daily cost cap for agents
  preset: 'data-sovereign' | 'budget' | 'standard' | 'full-access';
}

Configuration Location

Navigate to Admin Console > Tenant Manager (/admin/tenants) > select a tenant > Model Policy section.

Policy Presets

Presets provide one-click configurations for common scenarios:

Data Sovereign

Restricts all agents to EU-self-hosted models only. No data leaves T-Systems EU infrastructure.

{
  "preset": "data-sovereign",
  "euHostedOnly": true,
  "allowedModels": [
    "Llama-3.3-70B-Instruct",
    "Qwen3-32B-FP8",
    "DeepSeek-R1-Distill-Llama-70B",
    "Qwen2.5-VL-72B-Instruct"
  ],
  "deniedModels": [],
  "defaultMaxCostPerRequest": 0.10,
  "defaultMaxCostPerDay": 50.00
}

Use case: Government agencies, healthcare, financial institutions with strict data residency requirements.

Budget

Restricts agents to budget-tier models only.

{
  "preset": "budget",
  "euHostedOnly": false,
  "allowedModels": [
    "gpt-4.1-nano",
    "gpt-4.1-mini",
    "gemini-2.5-flash",
    "Llama-3.3-70B-Instruct",
    "Qwen3-32B-FP8"
  ],
  "deniedModels": ["o3", "gemini-2.5-pro", "claude-sonnet-4"],
  "defaultMaxCostPerRequest": 0.05,
  "defaultMaxCostPerDay": 10.00
}

Use case: Teams with limited budgets, PoC deployments, cost-sensitive workloads.

Standard

Allows budget and standard-tier models but denies premium reasoning models.

{
  "preset": "standard",
  "euHostedOnly": false,
  "allowedModels": [],
  "deniedModels": ["o3", "gemini-2.5-pro"],
  "defaultMaxCostPerRequest": 0.50,
  "defaultMaxCostPerDay": 100.00
}

Use case: Most enterprise tenants with moderate usage patterns.

Full Access

No model restrictions. All models available through AIFS are accessible.

{
  "preset": "full-access",
  "euHostedOnly": false,
  "allowedModels": [],
  "deniedModels": [],
  "defaultMaxCostPerRequest": 5.00,
  "defaultMaxCostPerDay": 500.00
}

Use case: R&D teams, advanced AI development tenants, premium enterprise customers.

EU-Hosted Only Configuration

The euHostedOnly toggle provides a single-switch mechanism for full data sovereignty.

What It Does

When euHostedOnly: true:

• Only models running on T-Systems infrastructure in Germany/Switzerland are allowed.
• All external models (Claude, GPT, Gemini, o3) are automatically denied, regardless of allowedModels.
• Data never leaves the EU.

EU-Hosted Models (as of 2025)

External Models (data may leave EU)

UI Behavior

In Agent Studio, when the tenant has euHostedOnly: true:

• External models appear grayed out with a lock icon.
• Tooltip reads: "Restricted by tenant policy: EU-hosted only."
• The "EU-hosted only" toggle in the Model tab is forced on and locked.
• Builders cannot override this restriction at the agent level.

Cost Caps

Cost caps prevent runaway spending at both the tenant and agent level.

Tenant Default Cost Caps

These apply to all agents in the tenant unless the agent has a more restrictive override:

Agent-Level Cost Caps

Builders configure agent-specific cost caps in AgentModelAccess:

interface AgentModelAccess {
  maxCostPerRequest?: number;      // Dollar cap per single LLM call
  maxCostPerDay?: number;          // Daily spend cap for this agent
  maxTokensPerRequest?: number;    // Token cap per call
}

Agent caps can be lower than or equal to tenant defaults. They cannot exceed tenant defaults.

Cost Cap Enforcement at Runtime

1. Before each LLM call, the Model Access PEP checks:
   • Has this agent's daily spend (tracked in Redis) exceeded maxCostPerDay?
   • Would this call's estimated cost (based on model pricing and token count) exceed maxCostPerRequest?
2. If either cap is exceeded, the call is denied.
3. The agent receives an error. If a fallback model is configured and the fallback would be within budget, it is tried automatically.
4. The denial is logged in the audit trail.

Monitoring Cost Cap Status

In the FinOps Center (/admin/finops):

• Per-agent daily spend vs. configured maxCostPerDay is shown as a progress bar.
• Red bar indicates the agent is approaching or has hit its limit.
• Alerts fire when an agent hits its cap.
• "Agent X hit its $5/day cap 3 times this week" type notifications help identify agents that need budget increases or optimization.

Model Allow and Deny Lists

Allow Lists

Use allowedModels to restrict the tenant to a specific set of models by ID:

{
  "allowedModels": ["claude-sonnet-4", "Llama-3.3-70B-Instruct", "gpt-4.1-mini"]
}

If allowedModels is empty or omitted, all models not in deniedModels are available (subject to euHostedOnly).

Deny Lists

Use deniedModels to block specific models. Deny always overrides allow.

{
  "deniedModels": ["o3", "gemini-2.5-pro"]
}

Even if a model is in allowedModels, it will be blocked if it is also in deniedModels.

Interaction Between Tenant and Agent Lists

Model Tags and Tag-Based Filtering

Instead of listing individual model IDs, you can use tags for broader policies.

Available Tags

Using Tags in Agent-Level Policies

Builders can use allowedModelTags in the agent's modelAccess config:

{
  "modelAccess": {
    "allowedModelTags": ["eu-hosted", "budget-tier"]
  }
}

This allows the agent to use any model tagged as either eu-hosted or budget-tier.

Fallback Chain Configuration

Fallback chains define the order of alternative models to try when the primary model is unavailable or denied.

FallbackChain Schema

interface FallbackChain {
  id: string;
  name: string;
  models: { modelId: string; modelName: string; order: number }[];
}

Example Fallback Chains

Data Sovereign Chain:

{
  "name": "EU-Hosted Fallback",
  "models": [
    { "modelId": "Llama-3.3-70B-Instruct", "modelName": "Llama 3.3 70B", "order": 1 },
    { "modelId": "Qwen3-32B-FP8", "modelName": "Qwen3 32B", "order": 2 },
    { "modelId": "DeepSeek-R1-Distill-Llama-70B", "modelName": "DeepSeek R1", "order": 3 }
  ]
}

General Purpose Chain:

{
  "name": "General Fallback",
  "models": [
    { "modelId": "claude-sonnet-4", "modelName": "Claude Sonnet 4", "order": 1 },
    { "modelId": "gpt-4.1", "modelName": "GPT-4.1", "order": 2 },
    { "modelId": "Llama-3.3-70B-Instruct", "modelName": "Llama 3.3 70B", "order": 3 }
  ]
}

Fallback Behavior

When an agent's primary model is denied or unavailable:

1. The platform checks the agent's configured fallback model.
2. If the fallback is also denied by policy, the next model in the fallback chain is tried.
3. If all models in the chain are denied, the call fails with a descriptive error.
4. The audit log records: "Primary model denied (policy: [reason]), fallback used: [model]."

The fallback is transparent to the agent runtime. The agent receives a response regardless of which model in the chain served it.

Routing Rules

Routing rules allow dynamic model selection based on request characteristics.

RoutingRule Schema

interface RoutingRule {
  id: string;
  name: string;
  condition: string;           // Human-readable description
  conditionType: 'risk-level' | 'token-count' | 'cost-threshold' | 'custom';
  targetModelId: string;
  targetModelName: string;
  priority: number;            // Lower number = higher priority
  active: boolean;
}

Example Routing Rules

Configuring Routing Rules

Routing rules are managed in Agent Studio > Model Selector (/studio/models) > Routing Rules section. Rules can also be set at the tenant level by admins to enforce organization-wide routing preferences.

Rules are evaluated in priority order. The first matching rule determines the model used for the request.

FinOps Monitoring and Cost Attribution

The FinOps Center (/admin/finops) provides comprehensive cost visibility.

Key Metrics

Cost Attribution

Every LLM call tracked by the platform includes:

• usage.prompt_tokens and usage.completion_tokens from the AIFS response
• Model-specific pricing to calculate dollar cost
• Attribution to: agent ID, tenant ID, user ID (who triggered the interaction)

Model Access PEP Decisions in FinOps

The FinOps Center includes model access-specific views:

• Cost cap status: Per-agent daily spend vs. configured cap, with red indicators when approaching limits.
• Denial counts: How many times each agent's LLM calls were denied due to cost caps, with frequency trends.
• Fallback savings: When agents fall back from expensive to cheaper models due to policy, the cost savings are calculated and displayed.
• Data sovereignty cost impact: For tenants with euHostedOnly, a comparison shows the cost of EU-hosted models vs. what equivalent workloads would cost on external models.

Optimization Suggestions

The FinOps Center generates actionable suggestions:

• "Agent X uses claude-sonnet-4 for simple classification tasks. Consider switching to gpt-4.1-nano for estimated 90% cost reduction."
• "Agent Y hit its $5/day cap 3 times this week. Consider increasing the cap to $10/day or optimizing prompts."
• "Tenant Z spends $X/month on Llama-3.3-70B-Instruct. Equivalent workload on Qwen3-32B-FP8 would save 15%."

Compliance Considerations

GDPR and Data Residency

EU-hosted models keep all data within T-Systems EU infrastructure (Germany/Switzerland). No data is transmitted to external providers.

External models route inference through AIFS partner networks. While AIFS has data processing agreements with providers, the actual inference may run on infrastructure outside the EU.

Recommendation: For tenants handling personal data of EU residents, enable euHostedOnly: true to ensure full GDPR compliance through data residency.

Audit Trail

All model access decisions are logged in the Decision Audit Log:

Audit Filtering

In the Audit Explorer (/admin/audit), filter by:

• Dimension = 4 (Agent -> Model) to see all model access decisions.
• Outcome = blocked to see only denied access attempts.
• Agent ID to see a specific agent's model access history.

EU AI Act Compliance

The Compliance Reports section (/admin/compliance) includes model governance reporting:

• Which models are used by which agents and tenants.
• Data residency status per model call.
• Cost and usage patterns for regulatory reporting.
• Risk classification mapping (which agents use which tier of models).

Cedar Policy Examples

Tenant-Level: EU-Hosted Only

// Deny all non-EU-hosted models for data-sovereign tenants
forbid(
  principal,
  action == Action::"model:invoke",
  resource
) when {
  context.tenantId == "government-agency" &&
  resource.isExternallyHosted == true
};

Agent Risk-Based Model Restrictions

// Assistive agents: budget/standard tier only
permit(
  principal,
  action == Action::"model:invoke",
  resource
) when {
  principal.type == "agent" &&
  principal.riskClassification == "assistive" &&
  resource.costTier in ["budget", "standard"]
};

forbid(
  principal,
  action == Action::"model:invoke",
  resource
) when {
  principal.type == "agent" &&
  principal.riskClassification == "assistive" &&
  resource.costTier in ["premium", "reasoning"]
};

Daily Cost Cap Enforcement

// Block agent if daily spend exceeds cap
forbid(
  principal,
  action == Action::"model:invoke",
  resource
) when {
  principal.type == "agent" &&
  context.agentDailySpend >= principal.maxCostPerDay
};

Deny Specific Models Globally

// Block reasoning models for all tenants except premium tier
forbid(
  principal,
  action == Action::"model:invoke",
  resource
) when {
  resource.costTier == "reasoning" &&
  context.tenantTier != "premium"
};

Related Documentation

• Builder Access Control Guide -- How builders configure agent-level model access
• Admin Identity Guide -- Identity provider and user management
• Troubleshooting Guide -- Resolving model access issues
• LLM Provider Reference -- T-Systems AIFS connection details and available models
• Access Control Reference -- Full Dimension 4 technical specification