Security Overview

For: Platform engineers and security teams evaluating or operating Axemere Gateway.

Axemere Gateway applies security at four layers. Understanding how they compose helps you reason about the attack surface and configure each layer appropriately.

Table of Contents

• Security Layers
• Layer 1 — Transport: Gateway-to-CP mTLS
• Layer 2 — Policy Integrity: Bundle Signing
• Layer 3 — Credential Protection: Envelope Encryption
• Layer 4 — Audit Integrity: Merkle Ledger
• What Each Layer Does and Does Not Protect
• See Also

Security Layers

Standards used: Ed25519 (RFC 8032) · AES-256-GCM (NIST SP 800-38D) · RFC 3161 TSA · JCS (RFC 8785)

Layer 1 — Transport: Gateway-to-CP mTLS

Every self-hosted gateway authenticates to the control plane using a certificate issued by the Axemere CA. The private key is generated on the gateway and never transmitted; the control plane only ever receives a CSR.

Certificates are issued automatically during bootstrap and renewed automatically when within 14 days of expiry.

→ Gateway-to-CP mTLS

Layer 2 — Policy Integrity: Bundle Signing

The control plane signs every policy bundle with a dedicated Ed25519 key before serving it to gateways. Gateways verify the signature before activating the bundle. This alone protects the bundle from the moment it's signed through delivery, but it doesn't cover the policy source data in Postgres before that point: a direct database tamper of a base bundle, an org or node overlay, or the addon catalog would just get faithfully signed and served as if legitimate.

A separate, complementary mechanism closes that gap. Every write to the underlying policy tables, the base bundle, organization and node overlays, and the add-on catalog, is protected by a keyed HMAC-SHA256, computed at write time and verified at every read that feeds an effective bundle. The key is a purpose-specific subkey held only in the control plane's process memory, never written to the database, so a database-only attacker can tamper the content but cannot recompute a valid MAC; the tamper is detected and the read denied on the next fetch. Together with bundle signing, a compromised database or a MITM on the gRPC connection cannot inject unauthorized policy.

→ Bundle Signing

Layer 3 — Credential Protection: Envelope Encryption

AI provider API keys stored in inline mode are protected with genuine envelope encryption: a fresh key is generated for every credential and encrypted locally with AES-256-GCM, then that key is wrapped by a dedicated Cloud KMS key that never leaves KMS. A database backup or SQL injection attack yields only ciphertext and a wrapped key, and unwrapping it requires a live, audited call to Cloud KMS, not just database access.

Encryption at rest is layered, not uniform: this envelope-encryption step applies specifically to stored credential secrets. All other platform data (execution-record metadata, quarantine entries, usage and cost data) relies on the database's standard disk-level encryption at rest (managed-Postgres/Cloud SQL encryption), not a separate application-layer step. Both are real encryption; they operate at different layers, and this doc calls out which layer protects what rather than collapsing them into one blanket claim.

→ Credential Encryption | Choosing a Credential Mode

Layer 4 — Audit Integrity: Merkle Ledger

Every execution record is hashed, submitted to an append-only ledger, and periodically batched into a Merkle tree. The Merkle root is anchored to an external timestamp authority (RFC 3161). Customers can independently verify that a record has not been modified after the fact.

→ Merkle Proof Verification

What Each Layer Does and Does Not Protect

See Also

• Glossary