> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/planning-and-decision-guides/openrouter-controls-for-qa-context.md).

# 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.

{% hint style="warning" %}
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.
{% endhint %}

## Map the complete path

```mermaid
flowchart LR
    A[QA source data] --> B[Your client or service]
    B --> C[OpenRouter]
    C --> D[Selected provider endpoint]
    D --> E[Model response]
    E --> F[Test or release workflow]
    C --> G[Optional plugin or tool]
```

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](https://openrouter.ai/docs/guides/privacy/provider-logging)
* [OpenRouter Zero Data Retention](https://openrouter.ai/docs/guides/features/zdr)
* [OpenRouter guardrails](https://openrouter.ai/docs/guides/features/guardrails/overview)
* [AI Testing Vendor Security Evidence](/planning-and-decision-guides/ai-testing-vendor-security-evidence.md)

{% hint style="info" %}
[**Review a model-routing boundary for a ContextQA evaluation →**](https://contextqa.com/book-a-demo/?utm_source=learning.contextqa.com\&utm_medium=referral\&utm_campaign=docs_demand_gen\&utm_content=openrouter_qa_controls) with the approved data classes, endpoint policies, negative tests, and security owner.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://learning.contextqa.com/planning-and-decision-guides/openrouter-controls-for-qa-context.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.