One API Key for All LLMs
Unify the Interface, Not the Secrets一个 API 密钥访问所有 LLM：统一接口，不共享上游密钥

TL;DR

What one key should and should not mean“一个密钥”应与不应意味着什么

One app key simplifies client configuration and centralizes governance. It should not become a broad shared secret with permanent access to every provider, model and environment.

一个应用密钥可以简化客户端配置并集中治理，但它不应变成永久访问所有供应商、模型和环境的宽泛共享密钥。

Treat “one key” as one stable application identity, not one credential copied across systems. The application authenticates once to the gateway; the gateway evaluates who is calling, from which environment, for which workload and under which budget. Only then does it select an eligible model route and obtain the matching upstream credential inside the trusted boundary.

应把“一个密钥”理解为一个稳定的应用身份，而不是在多个系统之间复制同一份凭证。应用只向网关认证一次，网关随后判断调用者身份、所属环境、目标工作负载和可用预算，再选择符合条件的模型路由，并在可信边界内取得对应的上游凭证。

The gateway maps the authenticated principal to a versioned policy. Provider adapters use separate credentials with the least scope available. Rotation or provider changes do not require distributing new secrets to every application.

网关将经过认证的主体映射到版本化策略；供应商适配器使用权限尽可能小的独立凭证。轮换凭证或更换供应商时，无需向每个应用重新分发密钥。

This abstraction also limits blast radius. A leaked application key can be revoked for one tenant or environment without disabling every upstream account. A provider credential can be rotated after an incident without changing client configuration. The design fails, however, if all virtual keys resolve to the same unrestricted provider secret or if production and test traffic share one policy.

这种抽象还能缩小故障与泄露的影响范围。某个应用密钥泄露时，可以只吊销对应租户或环境，而不必停用全部上游账户；供应商凭证发生事故后也能独立轮换，不影响客户端配置。如果所有虚拟密钥最终都指向同一份无限制供应商密钥，或生产流量与测试流量共用同一策略，这套设计就失去了意义。

Unified credential patterns统一凭证模式

Policy attached to the key密钥绑定的策略

Red-team unified access红队测试统一访问

A happy-path model response proves only that routing works. Security testing must prove that the gateway rejects requests when identity, scope, lifecycle state or policy does not match. Run these tests against the same authentication path and policy store used by production, not a simplified mock.

一次正常返回的模型响应只能证明路由可用。安全测试还必须证明：当身份、权限范围、生命周期状态或策略不匹配时，网关能够拒绝请求。测试应使用与生产环境相同的认证路径和策略存储，而不是经过简化的模拟实现。

• Attempt wrong-tenant, wrong-model, expired and revoked-key requests.
• Verify provider secrets never enter responses, logs, traces or client bundles.
• Rotate every upstream credential while applications keep their virtual key.
• Test policy rollback, budget exhaustion and a compromised-key kill switch.

• 尝试跨租户、未授权模型、过期密钥和已吊销密钥请求。
• 确认供应商密钥不会进入响应、日志、调用链或客户端资源包。
• 轮换所有上游凭证，同时保持应用侧虚拟密钥不变。
• 测试策略回滚、预算耗尽和密钥泄露后的紧急停用机制。

Also test concurrency and replay behavior. A key with a monthly budget can still cause an incident if thousands of requests arrive before spend counters converge. Use atomic reservations or bounded local allowances, define idempotency behavior for retries, and verify that a revoked key stops new requests within the documented propagation window.

还要测试并发与重放行为。即使密钥设置了月度预算，如果数千个请求在支出计数收敛前同时到达，仍可能造成事故。应采用原子预算预留或受限的本地额度，明确重试时的幂等规则，并验证密钥被吊销后，新请求能在承诺的传播时间内停止。

Resolve one key into many isolated credentials将一个密钥解析为多个隔离凭证

The gateway authenticates the application virtual key, resolves an internal principal and evaluates workload policy. A capability router selects an approved adapter. The adapter retrieves only the matching provider credential from a vault, executes the call and returns normalized output plus native evidence.

网关验证应用虚拟密钥、解析内部主体并评估工作负载策略；能力路由器选择获批适配器；适配器只从密钥库获取当前供应商所需的凭证，执行调用后返回标准化输出和原生证据。

Keep the request lifecycle observable. The audit record should identify the application principal, policy version, requested capability, candidate routes, selected provider, provider-native request ID, token usage, cost and final status. It should record which policy allowed the call without recording the provider secret itself. This makes a single-key experience easier for developers without creating a single point of audit ambiguity.

请求生命周期必须可观测。审计记录应包含应用主体、策略版本、请求能力、候选路由、所选供应商、供应商原生请求 ID、Token 用量、成本和最终状态；同时记录是哪条策略允许了调用，但绝不能记录供应商密钥本身。这样既能让开发者获得单密钥体验，也不会形成审计盲区。

Separate the control plane from the request path. Key creation, ownership changes, policy updates, rotation and revocation belong to a versioned control plane with approvals. Runtime validation should use a cached, bounded copy of that policy so a temporary control-plane outage does not automatically expose unrestricted access or stop every healthy inference request.

控制面与请求路径也应分离。密钥创建、所有者变更、策略更新、轮换和吊销属于带审批与版本控制的控制面；运行时验证则使用有边界的策略缓存。这样控制面短暂故障时，既不会意外放开无限制访问，也不会让所有健康的推理请求同时中断。

Use separate scopes for inference and tools为推理与工具使用独立权限范围

The model gateway uses the virtual key for inference policy. QVeris governs external APIs, tools, services and live data through Discover → Inspect → Call. Bind both to the same principal when useful, but keep credentials, budgets and audit trails separate.

模型网关使用虚拟密钥执行推理策略；QVeris 通过“发现 → 检查 → 调用”治理外部 API、工具、服务和实时数据。两者可以绑定同一应用主体，但凭证、预算与审计记录应保持分离。

Inference permission does not imply action permission. An application allowed to use a reasoning model may still be prohibited from sending email, placing an order, querying regulated data or retrieving customer records. Give tool scopes explicit capability names, argument constraints, data classifications and approval requirements rather than inheriting the broad model scope.

拥有推理权限并不等于拥有执行权限。某个应用即使可以使用推理模型，也可能无权发送邮件、提交订单、查询受监管数据或读取客户记录。工具权限应明确指定能力名称、参数约束、数据分类和审批要求，而不能直接继承宽泛的模型权限。

Keep cost controls independent as well. Model spend is usually measured in tokens, while tools may charge by request, record, document, data entitlement or downstream transaction. Joining both totals under one dashboard is useful, but independent budgets prevent a burst of tool calls from consuming the inference allowance or hiding an expensive external action inside a cheap model request.

成本控制同样需要分开。模型通常按 Token 计费，而工具可能按请求、记录、文档、数据权限或下游交易收费。把两类成本汇总到同一仪表盘有助于观察整体支出，但独立预算可以防止工具调用突增挤占推理额度，也能避免昂贵的外部动作被隐藏在一次廉价模型请求中。

FAQ

Official sources and further reading官方资料与延伸阅读