Security

How Antara keeps your identity safe

Antara ID (slug-based identity)

Each app receives a unique, 128-bit random slug — your Antara ID for that integration only. Slugs are cryptographically random and cannot be correlated across apps. There is no shared user ID, no email, and no phone number visible to applications through standard OAuth or API-token flows.

No Cross-App Tracking

Per-app slugs are isolated by design: App A cannot derive App B's identifier for the same person, which limits cross-app profiling and re-identification via Antara.

Encryption Model

• Email at rest — encrypted with AES-256-GCM using envelope encryption. Each record has a unique data encryption key (DEK), itself encrypted by a key-encryption key (KEK).
• Email lookup — uses a SHA-256 hash for matching. The plaintext email is never stored unencrypted.
• Tokens — all session and API tokens use opaque, high-entropy random values. No JWTs containing user data are sent to clients.

Authentication

• Passwordless — magic link authentication only. No password database to breach.
• OAuth 2.0 + PKCE — apps authenticate users via the Authorization Code flow with Proof Key for Code Exchange (S256). No client secrets required.
• Session tokens — short-lived access tokens (5 min) + rotating refresh tokens. Refresh token reuse revokes the entire session chain.

API messaging & capability tokens

The label <slug>@useantara.com identifies a recipient in HTTPS APIs — it is not an SMTP inbox. Messages are accepted only with valid credentials (app access tokens or short-lived capability tokens you issue). Tokens can bind to scopes, expiry, optional origins or sender emails, and are rate limited. Invalid or abusive use increases abuse signals; message bodies are not fully logged in audit trails.

Machine & AI API

Server-to-server access uses scoped API keys exchanged for short-lived tokens. Dedicated scopes such as identity.read, messages.send, and ai.chat are enforced at the edge with rate limits and moderation gates. Never embed API secrets in public clients.

Structured Email Channels

Outbound mail is sent from role addresses including no-reply@useantara.com, support@useantara.com, security@useantara.com, and abuse@useantara.com. Cloudflare Workers call a dedicated HTTPS email gateway (not raw SMTP from the edge); the gateway relays using Zoho Mail SMTP (for example on sahaj.tools). TLS is used between our worker and the gateway and between the gateway and the mail provider where supported. Message bodies follow documented templates; delivery timing and inbox placement are not guaranteed.

API Security

• Token exchange — API keys are never used directly. They are exchanged for short-lived access tokens (5 min TTL).
• Rate limiting — dual-layer: KV-based soft limits for general traffic, Durable Object hard limits for critical endpoints (token exchange, OAuth).
• Webhook signatures — all webhook payloads are signed with HMAC-SHA256. Constant-time comparison prevents timing attacks.

Infrastructure

• Runs on Cloudflare Workers — edge-native, no single point of failure
• D1 database with tenant-isolated queries
• Strict Content Security Policy (CSP) on every response
• All secrets stored as Cloudflare secrets (never in code)

Trust Governance

Security in Antara includes ecosystem governance:

• Every app has a trust level and dynamic trust score
• Moderation states escalate from warn → restrict → disabled based on safety signals
• Users can review trust factors directly in dashboard before interacting with apps

Read the full framework in Trust Model.

Reporting a Vulnerability

Found something? Email security@useantara.com. We triage every report; for critical issues we aim for initial response within 48 hours, and for other security topics we aim to respond within a reasonable timeframe (typically 3–7 business days).