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. A compromised database or 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 encrypted with AES-256-GCM before being written to the database. The encryption key is never stored alongside the data. A database backup or SQL injection attack yields only ciphertext.

Encryption at rest is layered, not uniform: this application-layer AES-256-GCM 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 (PMEK) | 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