OpenRouter controls for AI agents

The control gap

Agents can create unexpected spend or route sensitive prompts to an unapproved provider when model access is treated as one broad permission.

OpenRouter access decisions can include model, provider route, data policy, maximum tokens, estimated spend, organization budget, and whether the request may use fallback providers. A single API key can reach models with different cost, residency, and retention characteristics, so `run_inference` should not be treated as an undifferentiated action when those attributes matter.

Endram’s LLM gateway can apply verified identity policy, proxy allowed requests, preserve streaming, isolate the provider credential, and attach signed execution evidence. Test an allowed model, an unapproved provider, a request over the spend threshold, a stream interrupted mid-response, and an unavailable upstream. Do not record prompts or model output in authorization logs unless the organization has explicitly chosen that data boundary.

What good looks like

Routine OpenRouter work continues automatically while sensitive actions are denied or held for a named reviewer.

• Classify list_models and run_inference separately from change_routing and raise_spend_limit.
• Scope policy to model, provider route, budget instead of granting one undifferentiated OpenRouter capability.
• Require approval for unapproved providers, budget changes, or requests above the configured cost threshold.
• Preserve the delegated user, agent, request payload hash, decision, reason, and policy version.

A production workflow

1. The agent asks Endram to evaluate a OpenRouter action before execution.
2. Endram matches the agent, delegated user, action, and target model.
3. Low-risk requests proceed; sensitive requests create a time-bound approval.
4. The approved request executes once, and its outcome is attached to the original decision.

A policy you can test

OpenRouter high-impact approval is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: openrouter-high-impact
match:
  tool: openrouter
  action: ["change_routing", "raise_spend_limit"]
  environment: production
decision: require_approval
approval:
  expires_in: 15m
  reviewers: ["security-on-call"]

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• A searchable record of attempted list_models and raise_spend_limit operations.
• The exact model and budget targeted by each request.
• Which policy version matched and why the request was allowed, denied, or escalated.
• Who approved the action, when approval expired, and whether execution succeeded.

Buyer checklist

• Which OpenRouter actions must never run without a human?
• Can policy restrict individual model or provider route or budget?
• How are user delegation and service credentials represented?
• What evidence will incident response need after an unexpected action?