Docs

Overview

Encryption Gateway keeps customer data in your control plane while giving each customer a cryptographic kill switch. Each customer's data is protected by a key they control in AWS KMS, Google Cloud KMS, or Azure Key Vault.

By disabling that key, a customer can cut off access to their data—even if your cloud is compromised. Your application never receives their cloud credentials or raw key material. This is BYOK: bring your own key.

Data reaches Encryption Gateway three ways: your backend calling the Encrypt/Decrypt API, a Key attached to a resource in alien.ts, or an AWS resource using a Virtual Key through KMS. All three use one encryption root, protected by the AWS, Google Cloud, or Azure key the customer connected.

Your control plane still stores and serves the data. The customer-held key controls whether it can be read, turning trust in your access into a control the customer can exercise without your cooperation.

Pick a path

There are three ways to use Encryption Gateway. Which one fits depends on what holds the data.

If the data lives inUseWhat your application changes
Records your own application storesEncrypt/Decrypt APICalls Alien before writing and after reading
A resource Alien built, such as StorageNative resource encryptionNothing — the key is declared in alien.ts
An AWS resource in your own account — S3, Aurora, EBSAlien Virtual KeyNothing — it passes an ordinary KMS key ARN

All three end in the same place: an encryption root protected by the key that customer connected.

Encrypt application records

Your backend sends data to the Encrypt/Decrypt API. Alien encrypts it under a root protected by that customer's KMS key.

const encrypted = await fetch("https://encryption.alien.dev/v1/encrypt", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.ALIEN_ENCRYPTION_KEY}`,
    "X-Alien-External-ID": customer.id, 
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    key: { keyId: "customer-data" }, 
    plaintext: Buffer.from(value).toString("base64"),
  }),
}).then(response => response.json())

Use this for fields, documents, credentials, or other data your application stores itself. X-Alien-External-ID selects whose key protects the value, and keyId names the cryptographic context it belongs to.

Encrypt a resource built with Alien

Attach a Key to a supported resource in alien.ts. Alien carries the relationship into every customer deployment.

alien.ts
import * as alien from "@alienplatform/core"

const customerKey = new alien.Key("customer-key").build()
const data = new alien.Storage("customer-data")
  .encryptionKey(customerKey) 
  .build()

export default new alien.Stack("app")
  .add(customerKey, "frozen", { remoteAccess: true })
  .add(data, "frozen")
  .build()

See Native resource encryption.

Encrypt AWS resources with an Alien Virtual Key

For S3, Aurora, EBS, and other AWS services running in your own AWS account, create an ordinary AWS KMS key backed by Alien's External Key Store integration. The resource uses that KMS key ARN as usual, and your application keeps using the AWS SDK.

Nothing moves into the customer's cloud on this path. Your infrastructure stays where it is; the customer holds only the key that makes their data readable. Their key does not have to live in AWS either — the S3 bucket you run for them can be encrypted under a key they hold in Google Cloud KMS or Azure Key Vault. See Alien Virtual Keys.

Use this when AWS already knows how to encrypt the resource and you do not want your application calling a separate encryption API.

Latency

Encryption sits in the path of every read and write of a protected field, so the cost has to stay small.

Alien loads a customer's encryption root through their cloud KMS once, then caches it for five minutes. Encrypt and decrypt calls made against a loaded root do not reach the customer's cloud at all — they are local AES-GCM operations inside the gateway. Your steady-state cost is one HTTPS round trip to Alien, not a round trip to the customer's KMS.

That cache is also why revocation is not instantaneous. The same design that keeps per-record encryption affordable is the reason a disabled key can take up to five minutes to take effect.

For Alien Virtual Keys the shape is different — AWS KMS calls Alien on the encryption path, and AWS asks that external key stores sit within about 35 ms of the Region. AWS services request a data key and reuse it while the resource is in use, so that cost lands on resource start-up rather than on every query.

On this page