OpenRouter Controls for QA Context

Review OpenRouter and provider logging, retention, ZDR, model routing, budgets, fallbacks, guardrails, and rejected-request behavior for QA workloads.

Editorial owner: ContextQA Documentation · Last updated: September 12, 2026

Quick answer

Approve a specific OpenRouter configuration, not the idea of model routing in general. Record the exact QA data sent, permitted models and provider endpoints, OpenRouter and downstream-provider policies, Zero Data Retention enforcement, budgets, fallback behavior, plugins/tools, and the expected result when no eligible route remains.

This is an independent architecture-evaluation guide. It does not claim that ContextQA currently provides a native OpenRouter integration. Verify the actual model path for your ContextQA deployment with the product and security owners.

Map the complete path

For each arrow, record authentication, data categories, region, logging, retention, training use, encryption, owner, and deletion path.

Classify QA context before routing

Data	Example	Default decision
Public	Public docs and synthetic examples	Eligible after policy review
Internal	Test names, non-public requirements, architecture	Restricted models/endpoints
Confidential	Source code, ticket text, logs, screenshots	Security approval and minimization
Secret	Tokens, passwords, cookies, private keys	Never include; use a secret reference
Regulated/personal	Customer or employee data	Exclude unless explicitly approved and controlled

Minimize the prompt before relying on routing controls. A secret should not enter the path merely because a downstream endpoint advertises limited retention.

Separate OpenRouter and provider policy

OpenRouter’s current documentation says individual provider endpoints can have different training, logging, and retention policies. It also documents account- and request-level filtering. Review the selected endpoint’s policy—not only the provider’s general policy—and retain the source and date.

The current ZDR documentation says ZDR routing can be enforced globally, by model group, guardrail, or request. It also states that ZDR routing does not automatically cover optional plugins and tools, which may have separate third-party policies.

Define enforceable routing controls

Control	Required value	Observed configuration	Negative test
Allowed models			Request a blocked model
Allowed providers			Request a blocked provider
ZDR by model group			Request a non-eligible endpoint
Budget			Reach a disposable low limit
Sensitive-data action	Block/redact/other		Send synthetic marker only
Plugin/tool policy	Disabled or reviewed		Attempt unavailable tool
Region			Inspect selected endpoint/metadata
Fallback	Explicit ordered policy or disabled		Make primary route unavailable

OpenRouter currently documents guardrails for budgets, model/provider allowlists, ZDR, and sensitive-information controls. Availability can depend on account type; verify in the target organization.

Test failure behavior

A controlled evaluation should prove:

• disallowed models/providers are rejected;
• sensitive synthetic markers are blocked or redacted as configured;
• budget exhaustion returns a visible failure rather than silently changing policy;
• fallback does not cross a prohibited provider, region, or retention boundary;
• no-eligible-provider produces an explicit unknown/error outcome; and
• downstream failures cannot turn an incomplete QA action into a passing verdict.

Create an approval record

Workload and owner:
Approved data classes:
Forbidden data:
OpenRouter workspace/key/guardrail:
Allowed models and provider endpoints:
Endpoint policy sources and access date:
ZDR and regional requirements:
Plugin/tool policy:
Budget and alert owner:
Fallback order and stop condition:
Negative-test evidence:
Approval, exceptions, and expiry:

Revalidate when a model, endpoint, provider policy, guardrail, plugin, or routing strategy changes.

Frequently asked questions

Does enabling Zero Data Retention make every route safe?

No. Verify that ZDR is enforced for the selected model group and provider endpoint, and separately review optional plugins, tools, fallbacks, and other subprocessors. Minimize the data before routing and test the no-eligible-provider outcome.

Can production test data be sent through a model router?

Only when the exact data classes, endpoint, provider, region, retention, access, and deletion controls have been explicitly approved. Prefer synthetic or minimized context and never include secrets directly in a prompt.

When must the routing approval be repeated?

Revalidate after a model, provider endpoint, fallback, guardrail, plugin, data classification, or provider policy changes. Use an expiry date even when no announced change occurs so quiet dependencies are reviewed periodically.

Primary references

• OpenRouter provider logging
• OpenRouter Zero Data Retention
• OpenRouter guardrails
• AI Testing Vendor Security Evidence

Review a model-routing boundary for a ContextQA evaluation → with the approved data classes, endpoint policies, negative tests, and security owner.