Security architecture overview

Overview

Bastion is built with security as a foundational principle. We employ defense-in-depth strategies to protect your digital assets and ensure the integrity of every transaction. This document provides an overview of our security architecture.

Architecture

Defense in depth

Bastion’s infrastructure implements multiple layers of security controls:

Network Isolation: All services operate within isolated network segments with strict ingress controls
Authentication Gateway: Every API request is authenticated before reaching any backend system
Least Privilege: Each component operates with minimal permissions required for its function

Request flow

┌──────────┐         ┌─────────────────┐         ┌───────────────┐
│  Your    │  TLS    │  API Gateway    │  Auth   │   Bastion     │
│  App     │────────▶│  + Auth Layer   │────────▶│   Platform    │
└──────────┘         └─────────────────┘         └───────────────┘

All API requests pass through our authentication layer before any processing occurs. Unauthenticated or unauthorized requests are rejected at the gateway—they never reach backend systems.

Infrastructure security

Bastion runs on AWS with enterprise-grade security controls:

VPC Isolation: Services run in private subnets with no direct internet access
WAF Protection: Web Application Firewall blocks common attack patterns
DDoS Mitigation: AWS Shield protects against volumetric attacks
Container Hardening: All services run as non-root with read-only filesystems

Secure hardware

AWS Nitro Enclaves

Bastion’s signing operations run inside AWS Nitro Enclaves, providing hardware-enforced isolation for cryptographic operations. What are Nitro Enclaves? Nitro Enclaves are isolated compute environments with:

No persistent storage — Secrets exist only in volatile memory
No interactive access — No SSH, no shell, no debugging access—even for Bastion engineers
No external networking — Access to the enclave is limited to secure virtual socket interface
Cryptographic attestation — Hardware-signed proof that the enclave is running verified code

Why this matters for you: Your private keys are generated and used inside this isolated environment. The keys cannot be extracted, copied, or accessed—even by Bastion. Only the enclave has access to the cryptographic material needed to sign transactions on your behalf.

Hardware-level guarantees

Property	Guarantee
Isolation	Signing runs in a separate virtual machine with its own kernel
Attestation	AWS provides cryptographic proof of enclave integrity
No Persistence	Keys exist only in memory during operation
Tamper Evidence	Any modification to the enclave code invalidates attestation

Wallet key security

Key derivation

Bastion uses a hierarchical deterministic key derivation scheme. Private keys are never stored—they are mathematically derived on-demand from a master secret secured in AWS Key Management Service (KMS).

┌─────────────────────────────────────────────────────────────┐
│                       AWS KMS                               │
│         Hardware Security Module (FIPS 140-2 Level 3)       │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                   Nitro Enclave                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  Shard Key (derived from KMS, in-memory only)         │  │
│  │             │                                         │  │
│  │             ▼                                         │  │
│  │  Account Private Key (derived per-request)            │  │
│  │             │                                         │  │
│  │             ▼                                         │  │
│  │  Signed Transaction                                   │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

Key security properties

Property	Description
No Key Storage	Private keys are derived on-demand, never written to disk
KMS-Backed	Root secrets protected by FIPS 140-2 Level 3 certified HSMs
Memory Protection	Cryptographic material is zeroed immediately after use
Deterministic	Same wallet address is always derived from the same account

Supported cryptography

Chain Family	Algorithm	Chains
EVM	secp256k1 ECDSA	Ethereum, Polygon, Arbitrum, Base, Optimism
SVM	Ed25519 EdDSA	Solana

API authentication

API keys

Bastion uses high-entropy API keys for authentication:

Authorization: Bearer bas_XXXXXXXXXX...

Security Properties:

Property	Description
Secure Entropy	Keys generated using secure high-entropy randomness
One-Time Display	The full key is shown only at creation—it cannot be retrieved later
Secure Storage	Keys are securely hashed before storage; plaintext keys are never stored
Instant Revocation	Revoked keys are immediately rejected

Best practices

Do	Don’t
Store keys in a secrets manager	Commit keys to version control
Use separate keys for development and production	Share keys between environments
Rotate keys periodically	Use long-lived keys without rotation
Revoke unused or compromised keys immediately	Leave old keys active

Request signing (enhanced security)

For high-security use cases, Bastion supports ECDSA request signing:

Generate a key pair: Create an ECDSA P-256 key pair
Register your public key: Associate it with your API key via the Dashboard
Sign each request: Include a signature header with your requests

When request signing is enabled, every API call must include a valid signature. This protects against API key theft and provides request authenticity.

POST /v2/crypto/transfers
Authorization: Bearer bas_XXXXXXXXXX...
Bastion-Signature: <ecdsa-signature>

Data protection

Encryption at rest

All sensitive data is encrypted using AES-256 with keys managed through AWS KMS.

Encryption in transit

All communications are protected with modern TLS.

Summary

Layer	Protection
Infrastructure	VPC isolation, WAF, DDoS protection, hardened containers
Signing	AWS Nitro Enclaves with hardware-level isolation
Keys	Never stored; derived on-demand; KMS-backed
Authentication	High-entropy API keys; optional ECDSA request signing
Data	AES-256 at rest; modern TLS in transit

Getting Started

Concepts

Quickstarts

Compliance

Security

Bastion Dashboard

LLMs and MCP Server

Security architecture overview

Overview

Architecture

Defense in depth

Request flow

Infrastructure security

Secure hardware

AWS Nitro Enclaves

Hardware-level guarantees

Wallet key security

Key derivation

Key security properties

Supported cryptography

API authentication

API keys

Best practices

Request signing (enhanced security)

Data protection

Encryption at rest

Encryption in transit

Summary

​Overview

​Architecture

​Defense in depth

​Request flow

​Infrastructure security

​Secure hardware

​AWS Nitro Enclaves

​Hardware-level guarantees

​Wallet key security

​Key derivation

​Key security properties

​Supported cryptography

​API authentication

​API keys

​Best practices

​Request signing (enhanced security)

​Data protection

​Encryption at rest

​Encryption in transit

​Summary

Overview

Architecture

Defense in depth

Request flow

Infrastructure security

Secure hardware

AWS Nitro Enclaves

Hardware-level guarantees

Wallet key security

Key derivation

Key security properties

Supported cryptography

API authentication

API keys

Best practices

Request signing (enhanced security)

Data protection

Encryption at rest

Encryption in transit

Summary