Aeion AI Security Architecture
Where provider credentials live, what gets logged, how tenants stay isolated, and what each compliance framework actually requires of an AI gateway. A credential-locality model that gives SOC 2, ISO 27001, HIPAA, GDPR, and FedRAMP audits a defensible answer to "where do the AI provider keys live?"
Standards Compliance Inventory
Encryption at rest
AES-256-GCM, with a dedicated encryption key scoped to the AI layer, for provider API keys
Encryption in transit
TLS 1.2+ to all 57 provider endpoints; TLS 1.3 preferred
Audit log standard
Full prompt + response in `ai_usage_logs`; per-call timestamp + cost + tenant + user
Retention
Retained indefinitely today (no automated purge yet) — same for every tenant, no tier gating
Multi-tenant isolation
Per-tenant provider config; cross-tenant queries impossible at the platform layer
PII handling
Configurable redaction in audit log — exclude PII fields before logging, available to every tenant
Prompt injection defense
Pluggable filter hooks before each provider call
Data residency
Provider choice gates residency (e.g., US-only providers vs. EU providers per tenant)
Credential Locality — The Big Differentiator
Where your provider API keys live is the single biggest compliance question for an AI gateway.
What Gets Audited — Per-Call Granularity
Every AI call (LLM, image, voice, embedding, anything) lands in ai_usage_logs with full context.
Per-Tenant Isolation
Every provider config is tenant-scoped. The platform's tenant resolution applies to AI calls the same way it applies to every other request.
Compliance Mapping
What this architecture proves to which auditor.
Prompt Injection Defense
Prompt injection is the #1 application-layer risk for AI deployments. Aeion provides three layers: