Model and provider policy
Can administrators allow, deny or constrain models and providers before traffic leaves the application?
AI gateway governance
How to evaluate an AI gateway for policy, access and audit control
A gateway is not governed merely because it routes requests. Serious evaluation requires knowing who can call which models, which providers are permitted, what gets logged, how failover behaves, how spend is constrained and where data travels.
Access control
Can access be scoped by key, user, workspace or application rather than sharing one upstream credential?
Auditability
Can operators reconstruct which model/provider served a request, what fallback occurred, and what it cost?
Spend control
Can teams cap or observe spend at the application or credential layer?
Data handling
What is logged by the gateway, what reaches the provider, and what retention terms apply to each layer?
Failover policy
Can reliability rules preserve governance requirements instead of failing over to any available provider?
Regional requirements
Does the product actually guarantee regional processing, or only host part of the control plane in-region?
AetherGate's current boundary
AetherGate currently provides encrypted provider-key custody, hashed gateway keys, rate/spend constraints, configurable routing and failover, request telemetry, and redaction of common PII/secret patterns before request previews are logged. It does not claim SOC 2, ISO 27001, HIPAA, FedRAMP, universal zero-data-retention, formal enterprise RBAC, or guaranteed EU-only processing.
That distinction matters: technical safeguards are not the same thing as compliance attestations, and a gateway cannot override the retention or geographic behavior of an upstream model provider.