Verification Center · Updated October 2026

Don't trust a feature list. Reproduce the control.

This page separates AetherGate controls that can be reproduced today from controls that are partial or not implemented. A green status means the behavior is enforced in the product path described below—not that AetherGate holds a compliance certification.

BYOK-only operation

Bearer gateway-key traffic requires customer-supplied provider credentials. Server-owned provider credentials are not eligible for those requests.

Verified behavior

Evidence in the current implementation

  • • Gateway-key requests pass requireByok=true into the gateway engine.
  • • Credential resolution disables server-environment credentials when requireByok is set.
  • • Missing customer credentials produce a terminal/missing-credential attempt rather than silently switching to a server-owned key.
  • • Attempt traces expose the credential source for successful attempts.

Reproduce it

  1. 1. Create a gateway API key.
  2. 2. Connect one customer provider credential and configure a fallback chain.
  3. 3. Disable or invalidate the primary customer credential.
  4. 4. Send a request with the gateway API key.
  5. 5. Inspect aethergate_telemetry.attempt_trace and confirm every successful attempt reports credentialSource=byok_vault.
Boundary: Dashboard/session traffic can still use deployment-owned credentials only when the deployment explicitly enables them. The BYOK-only guarantee here applies to authenticated bearer gateway-key traffic.

Policy-preserving failover

A gateway API key model allowlist is evaluated against the entire resolved candidate chain, including routing-rule and smart-router expansion, before any provider dispatch occurs.

Verified behavior

Evidence in the current implementation

  • • Routing aliases are expanded before policy evaluation.
  • • Every resolved candidate is checked against the gateway-key allowlist.
  • • If any candidate violates policy, the request is blocked before upstream dispatch with POLICY_BLOCKED.
  • • Telemetry includes the resolved candidates and effective policy.

Reproduce it

  1. 1. Create a gateway API key limited to a small model allowlist.
  2. 2. Configure a routing rule whose fallback contains a model outside that allowlist.
  3. 3. Call the routing-rule alias with the restricted gateway key.
  4. 4. Confirm the request returns POLICY_BLOCKED and no provider attempt is made.
Boundary: This control currently governs model allowlists. Dedicated provider, region and organization-role policies are not yet implemented as separate policy dimensions.

API-key spend cap

AetherGate reserves a conservative catalog-estimated maximum request cost before provider dispatch and atomically rejects a request when that reservation would exceed the API-key spend cap.

Verified behavior

Evidence in the current implementation

  • • Reservation is performed with a conditional atomic database update before upstream dispatch.
  • • Concurrent requests compete against the same stored spend value rather than relying only on a post-request dashboard check.
  • • The reservation is reconciled to actual catalog-estimated cost after completion, or released on failure.
  • • A failed reservation returns SPEND_CAP_RESERVATION_FAILED before provider dispatch.

Reproduce it

  1. 1. Create an API key with a small spend cap.
  2. 2. Send concurrent requests whose combined conservative reservations exceed the remaining cap.
  3. 3. Confirm only requests that fit within the atomic reservation budget are dispatched.
  4. 4. Compare spentUsd after completion with request telemetry.
Boundary: This is a hard cap against AetherGate's catalog-estimated request cost, not a contractual guarantee that an upstream provider invoice can never differ because of provider-side pricing changes, rounding, or unmodeled billing behavior.

Administrative RBAC

AetherGate does not currently claim a multi-role administrative RBAC system.

Not implemented

Evidence in the current implementation

  • • Authenticated workspace mutation routes currently authorize the signed-in workspace user rather than a role matrix.

Reproduce it

  1. 1. Not applicable until multiple administrative roles and explicit permissions are implemented.
Boundary: Gateway API keys have application-facing restrictions, but those are not the same thing as administrator RBAC.

Administrative audit log

AetherGate does not currently claim a complete actor-attributed administrative change ledger with before/after values.

Not implemented

Evidence in the current implementation

  • • Request telemetry records runtime gateway behavior, but configuration mutations are not yet written to a dedicated immutable administrative event stream.

Reproduce it

  1. 1. Not applicable until an administrative event catalog and persistence layer are implemented.
Boundary: Runtime request traces must not be described as equivalent to administrative audit logs.

Retention and export

AetherGate stores operational request telemetry, but does not yet publish a complete retention/deletion/export contract for all runtime and administrative records.

Partial

Evidence in the current implementation

  • • Request telemetry is persisted in PostgreSQL.
  • • No universal Zero Data Retention mode is claimed.

Reproduce it

  1. 1. Current request records can be inspected in the product, but a formal retention/export verification suite is not yet available.
Boundary: Upstream provider retention remains controlled by the customer's provider account and contract.

Tamper protection

AetherGate does not currently claim cryptographic tamper-evidence or immutable administrative logs.

Not implemented

Evidence in the current implementation

  • • No hash chain, append-only external sink, signature scheme or WORM storage guarantee is currently claimed.

Reproduce it

  1. 1. Not applicable until a tamper-evident logging mechanism is implemented.
Boundary: Database authorization and application security are not equivalent to cryptographic tamper evidence.