Control & Trust·production

IAM.Router

Policy-driven LLM traffic routing by model, provider and perimeter.

Landing Application API endpoint ↗
IAM.Router interface
Current public IAM.Router surface. The screenshot was verified when the documentation was published.

Key capabilities

  • OpenAI-compatible inference gateway
  • Routing across local, on-premises and external models
  • Quotas, fallback, decision audit and provider health

Role in the ecosystem

IAM.Router separates an application from a specific LLM provider. The client sends OpenAI compatible request, and Router applies tenant policy, selects model and perimeter, controls the quota and records the decision.

Main scenario

POST /v1/chat/completions
Authorization: Bearer <scoped-key>
Content-Type: application/json

{"model":"policy/default","messages":[{"role":"user","content":"..."}]}

The requested model name can be a logical alias. The final provider is determined policy, health, data requirements and available budget.

Routing

Router supports several execution classes:

  • local/on-prem — data does not leave the matched circuit;
  • dedicated — dedicated endpoint for a tenant or project;
  • external — allowed cloud provider;
  • fallback — the next compatible route after retriable failure.

Retry is performed only for safe replays and is limited by deadline. Provider error should not endlessly multiply one request or bypass policy.

Integrations

IAM.Secure can inspect prompt/response before and after route. IAM.Identity specifies the tenant scope. IAM.Bot, Marketplace and other applications use Router as transport, saving own domain state regardless of the result of the LLM call.

Quotas and observability

Tenant/model/provider, tokens, latency, route decision and error are monitored class. For hosted agents, the budget is reserved before the provider call and fixed after billable result. The provider’s health is a route selection signal, not replacement for explicit policy.

Safety

  • inference keys have tenant scope;
  • administrative routes are separated from /v1/*;
  • provider secrets are not returned to the client;
  • DLP/route outcome is in the audit trail;
  • production policy is not weakened for the sake of fallback.

Before production

Check the list of models, real completion for each allowed provider, timeout/retry, budget limits, behavior at 429/5xx and security correlation id through the entire route.