Trust center · Updated October 2026

AetherGate security architecture

This page documents security controls that are currently implemented in the AetherGate gateway and orchestration control plane. It intentionally separates technical safeguards from certifications or attestations AetherGate has not earned.

Implemented controls

Provider credential custody

Provider API keys are encrypted before database storage using AES-256-GCM. Raw provider credentials are not returned to the browser after storage. Applications call AetherGate with scoped gateway credentials instead of embedding every upstream provider key.

  • AES-256-GCM encryption before provider credentials are persisted.
  • Raw provider credentials are treated as write-only after storage.
  • Customer applications use AetherGate gateway credentials rather than direct provider secrets.

Gateway keys and application access

AetherGate gateway API keys are stored as hashes rather than plaintext secrets. Keys can be revoked and constrained with request-rate and dollar-spend limits, reducing the blast radius of a leaked application credential.

  • Hashed gateway-key storage.
  • Per-key rate limits.
  • Per-key spend caps.
  • Revocable application-facing credentials.

Outbound request and SSRF protections

The gateway validates upstream targets immediately before dispatch. DNS-aware checks block private and internal network destinations, redirects are disabled for upstream fetches, and request timeouts are bounded.

  • Public-target validation immediately before outbound dispatch.
  • Private/internal IP destinations are blocked.
  • Redirect following is disabled for upstream model calls.
  • Bounded network timeouts reduce hanging requests and retry amplification.

Request logging and sensitive-data handling

AetherGate records request telemetry so operators can understand routing, cost, latency and failures. Prompt previews are redacted for common PII and secret patterns before being written to request logs.

  • Redaction is applied before prompt previews are written to telemetry.
  • Operational metadata can include requested model, served model, provider, cost, latency, retries and fallback state.
  • AetherGate does not currently claim a universal Zero Data Retention mode.
  • The connected upstream model provider still has its own retention and training terms.

Authenticated mutations and session protection

Authenticated write routes validate trusted request origins to reduce cross-site request forgery risk. Production sessions use HTTPOnly Secure cookies so browser JavaScript cannot directly read the session cookie.

  • Trusted-origin checks on authenticated mutation routes.
  • HTTPOnly session cookies.
  • Secure cookies in production.

Durable mission execution

Long-running multi-model missions are persisted instead of relying only on process memory. Mission workers use leases, checkpoints, bounded retries and explicit review/verification stages, reducing duplicate execution and making recovery behavior observable.

  • Persistent mission/task state in PostgreSQL.
  • Worker leases and heartbeats.
  • Checkpointed specialist outputs.
  • Bounded retry behavior.
  • Adversarial review and separate final verification phases.

Shared responsibility

AetherGate can secure the gateway layer, but it cannot replace the security controls of the upstream model provider or the customer application. Customers remain responsible for provider-account policy, data classification, least-privilege application access, provider retention settings and regulatory fit.

Claims boundary

AetherGate does not currently claim SOC 2, ISO 27001, HIPAA, FedRAMP or another formal compliance certification. Technical controls such as encryption or redaction should not be interpreted as an attestation or guarantee that a workload is compliant.

Security evaluation resources