ASTIS Documentation

Architecture Overview

ASTIS is a security layer, not a mail server. Your existing email provider handles delivery and storage. ASTIS adds:

• End-to-end encryption — messages are encrypted with OpenPGP before leaving your client
• Session key capsules (SKEY) — encrypted key material that controls access to each message
• Policy enforcement — TTL, sharing rules, and access requirements defined by the sender or organization
• Zero-knowledge for email content — ASTIS never sees or stores plaintext email content; session keys are stored as encrypted capsules (transient in-memory plaintext only during Key Rewrap)

OpenPGP (RFC 4880)

All messages are encrypted using OpenPGP. Each user has a public/private key pair. Public keys are discoverable via WKD (Web Key Directory) protocol.

Session Key Capsules (SKEY)

Each email is encrypted with a unique session key. The session key is then wrapped into an encrypted capsule:

• Capsule is encrypted to the recipient's public key
• Plaintext SKEY is never stored or logged by ASTIS
• TTL and policies are enforced at the capsule level

Key Discovery (WKD)

ASTIS uses the Web Key Directory protocol (RFC 8605) for automatic public key discovery. When you send an email, the recipient's public key is automatically retrieved via their email domain's WKD endpoint.

Organization Management

Business and Enterprise plans include organization-level controls:

• Roles — Admin, Auditor, Member roles with granular permissions
• Policies — Organization-wide TTL defaults, external sharing rules, access requirements
• Audit logs — Security-relevant events: policy changes, admin actions, access decisions
• Team key governance — Centralized key management across the organization

Licensing & Seats

• You only pay for users who send encrypted emails
• Receiving and reading emails is unlimited and free
• Per-seat price is locked for the full annual subscription term
• Seats can be added mid-term at the locked price
• Seat reductions take effect at next renewal

1Get a workload API key

In portal.astis.io → API Keys, create a workload key — bound to your cluster, namespace, service account, and approved image digest. Store it as a Secret in the pod's namespace:

kubectl -n my-ns create secret generic astis-api-key \
  --from-literal=api-key='astis_live_sk_…'

2Wire your pod

Your app declares no identity — the gateway derives it from your API key + the pod's ServiceAccount JWT. Mount four things into the pod:

/etc/astis/api-key                      workload API key (the Secret from step 1)
/var/run/secrets/astis-audience/token   projected SA token (audience: astis.io)
/etc/podinfo/{name,uid}                  pod identity (downward API)
/etc/astis-sealed/*                      your sealed secrets (ASTIS:v2 ciphertext)

Grab the full ready-to-apply Deployment from the Kubernetes recipes .

Where does the envelope come from?

openSecret() takes a string — the ASTIS:v2 ciphertext. Keep it anywhere config lives: a mounted Secret file, an env var, or an application.yaml / config property — it's ciphertext, so it's safe in all of them.

# the envelope is just a string — source it however you like (pick one):
wire = open("/etc/astis-sealed/db-password").read().strip()   # mounted Secret (file)
wire = os.environ["DB_PASSWORD_ENC"]                          # Secret exposed as env var
wire = settings["db_password_enc"]                            # any config object

secret = client.open_secret(wire)

Only the plaintext is sensitive — never write the decrypted value back into env or config.

Multiple secrets? One key, many envelopes.

A service usually needs several — DB1, DB2, an LLM API key. Seal each to the same workload, mount them as files, and decrypt each with the same client (one session is reused for all). Adding a secret never needs a new key, and each rotates independently.

/etc/astis-sealed/db1-password
/etc/astis-sealed/db2-password
/etc/astis-sealed/llm-api-key

client   = from_kubernetes()                    # one client, one workload session
db1      = client.open_secret(open("/etc/astis-sealed/db1-password").read().strip())
llm      = client.open_secret(open("/etc/astis-sealed/llm-api-key").read().strip())

With the Spring Boot starter or astis-exec, add one mapping line per secret — no code.

Do I need to change my email provider?

No. ASTIS is a security layer that works with your existing provider (Microsoft 365, Gmail, SMTP, etc.). Keep your current setup.

What happens if the recipient doesn't have ASTIS?

ASTIS supports secure escrow onboarding. The message stays encrypted, and once the recipient registers and publishes a public key, the capsule is re-wrapped to their key.

Does ASTIS store my emails?

No. ASTIS servers do not store your emails. Your email provider handles storage and delivery. Plaintext email content is handled only within the ASTIS client application on your device — it is never seen or stored by ASTIS servers.

What encryption standard does ASTIS use?

ASTIS uses AES-256-GCM for email content encryption and OpenPGP (RFC 4880) for session key (SKEY) capsule protection. Each message is encrypted with a unique session key, which is then wrapped into an OpenPGP capsule. Plaintext session keys are never stored.

Can I use ASTIS for my team?

Yes. Business plans support 15–2,000 senders with organization policies, audit logs, and team key governance. Enterprise plans are designed for larger organizations or regulated environments — they include HYOK CVS key custody, extended audit retention, dedicated onboarding, priority support, SLA options, and custom pricing. Contact sales for a tailored deployment.

What is TTL (Time-to-Live)?

TTL controls how long a recipient can decrypt a message. After the TTL expires, the session key capsule is no longer accessible. Free: up to 14 days. Plus: up to 90 days. Business/Enterprise: custom TTL.