Security overview
AfterAI is built for platform teams who need auditability and a defensible posture. The same security model applies whether you use the console, the API, or the SDK.
Metadata-First Approach
AfterAI does not require prompt or output capture to function. By default, the system operates on metadata — model identifiers, versioning, timestamps, and change deltas. Prompt and output capture is opt-in, sampled, and fully controllable via redaction and retention policies.
- No prompt capture by default
- Optional, sampled output logging
- Redaction + retention policy controls
Out-of-Band Telemetry
AfterAI never sits in your inference path. There is no proxy, no traffic interception, and no request routing. Telemetry is asynchronous and designed to fail open — if AfterAI is unavailable, your inference continues unaffected.
- Zero inference-path instrumentation
- No hot-path traffic logging
- Asynchronous, fail-open design
Unified Identity
The same authentication and access model applies across console, API, and SDK. The console uses session JWTs in httpOnly cookies. The API accepts API keys or Bearer JWTs. Credentials are hashed at rest; no secrets are embedded in images or source.
- httpOnly session cookies (console)
- API key + Bearer JWT (API / SDK)
- Credentials hashed at rest
Enterprise Isolation
Enterprise deployments run on single-tenant eval compute with full network isolation. Optional customer-managed keys (BYOK) and full audit logs are available. Retention policies and immutable PACR records satisfy compliance requirements.
- Single-tenant eval compute
- Optional BYOK (customer-managed keys)
- Full audit logs + immutable PACRs
Operational security
Secrets and configuration are supplied via environment variables. The application fails fast on misconfiguration — incomplete or insecure deployments do not start. Required configuration is validated at startup. We are committed to further hardening as we scale, including rate limiting, DDoS protection, and WAF where appropriate.