Security & Compliance

Under BYOK, API keys live in gateway memory only — never persisted or transmitted.

Requests route through the gateway straight to vendor APIs; data stays within your private network end to end.

GateLLM itself does not store, train on, or cache request content.

TLS 1.3 end to end.

Keys in memory only; on restart, injected from your secrets — never on disk.

Client admission control: gate by User-Agent with differentiated policies.

GDPR / CCPA / DPA ready.

SOC 2 Type II / ISO 27001 controls aligned (certification in preparation).

SSO (OIDC: Azure AD / Okta / generic, plus SAML 2.0 + SCIM 2.0).

Request-level audit logs, exportable to internal ops and billing systems.

Crash-safe billing: pre-deduct → settle → refund; billing stays correct across process crashes via an in-flight ledger and per-request audit.

Management API to programmatically manage quotas, budgets, usage, and cost.

Network layer: the gateway process is deployed within your VPC / on-premises data center; inbound/outbound traffic is controlled by the security groups / network policies you configure; requests go directly to downstream model providers' official APIs, without passing through any Processor relay server.

Gateway process layer: stateless design; keys are loaded from encrypted configuration into memory and never persisted; any replica can serve any request, supporting horizontal scaling and instant failover; on restart, keys are re-injected from your secrets.

Key layer: BYOK model-provider keys live only in the gateway process memory, are never written to persistent storage, and cannot be read in plaintext by operations personnel; client admission control gates by User-Agent with differentiated policies.

Data layer: runtime prompts / completions are not persisted in the Processor's systems (forwarded in memory, not persisted); account and license data at rest is AES-256 encrypted; the audit-log retention policy is determined by your operations team.

Billing layer: crash-safe billing (pre-deduct → settle → refund), stays correct across process crashes via an in-flight ledger and per-request audit.

Excessive AI access concerns: GateLLM addresses this with fully self-hosted deployment + BYOK — keys and prompts never leave your network boundary; you fully control which models to use and which provider to route to, with no shadow AI and no hidden sub-processors (see the Sub-processor List).

Data used for training: the Processor does not come into contact with prompt data; whether a downstream model provider trains is determined by its policy, which you can review in the data-use matrix on the Sub-processor List before onboarding — entirely opt-in.

Cross-border compliance: Processor account data is transferred cross-border via SCCs / IDTA; cross-border transfers to downstream providers are engaged directly by you with appropriate safeguards (DPA Section 11).

Key leakage: keys live in memory only, are never persisted or transmitted; SSO delegates MFA and session management to your existing IdP, so credentials are not fragmented.

Independent third-party penetration testing of GateLLM is in preparation (scope and rules of engagement are ready), covering the gateway process, authentication & authorization, Edge Functions, API gateway, and key-handling paths; a summary will be published in Section 7 of the Vulnerability Disclosure Policy once completed.

Responsible vulnerability disclosure policy: report via security@gatellm.io (PGP supported), acknowledged within 24 hours, remediated by CVSS severity (Critical 7 days / High 30 days / Medium 60 days / Low 90 days).

A Software Bill of Materials (SBOM) is provided; dependencies are regularly scanned for known vulnerabilities, and security patches are annotated with CVE IDs in the changelog.