API & MCP Security
Security is enforced at the platform level, not the client. Every request — whether from the web app, an MCP server, Claude Desktop, or a direct API call — passes through the same security controls.
Defense in Depth
Elixium uses a layered security model. No single control is relied upon in isolation. Authentication verifies identity. Authorization enforces what that identity can do. Rate limiting prevents abuse. Input validation rejects malformed data. Audit logging creates an immutable record. Each layer is independent — compromising one does not compromise the others.
Core Principles
Secure by Default
Zero-configuration deployments are secure. Encryption, access controls, and rate limiting are enabled out of the box — not something you opt into.
Server-Side Enforcement
All security controls live in the backend API. The MCP server, web app, and IDE extensions are convenience layers — they cannot bypass platform security.
Least Privilege
Role-based access control with multiple tiers. API keys can be scoped to limit permissions. Service accounts use short-lived tokens that expire automatically.
Fail Closed
When in doubt, deny. Authentication errors reject the request. Validation errors reject the request. Missing permissions reject the request. No silent failures.
Security Layers
OAuth 2.1 authorization (authorization code with mandatory PKCE, rotating refresh tokens) alongside identity-provider tokens and scoped API keys for legacy and service-account use — all with short-lived access tokens.
Role-based access control with granular permissions per resource and operation. Every mutation endpoint is gated by authorization middleware.
Multi-tier rate limiting protects against abuse and brute-force attacks. Stricter limits on sensitive operations like key generation and account changes.
Schema-based validation on all mutation endpoints. Unknown fields are stripped. System-managed fields cannot be modified through public API calls.
Every mutation and authentication event is logged with actor identity, action, timestamp, and request metadata. Logs are tenant-scoped and queryable by workspace admins.
Multi-tenant data isolation enforced at the authentication, query, and authorization layers. Cross-tenant access is architecturally prevented.
MCP & OAuth 2.1 Authorization
The hosted MCP endpoint is a standards-based OAuth 2.1 resource server. Agents connect by signing in as you— no long-lived secret is copied into a config file.
The authorization-code flow requires PKCE (S256) for every client — public clients like IDE extensions never hold a client secret.
Refresh tokens are single-use and rotate on every renewal. Reusing a spent refresh token is treated as a compromise signal: the entire token chain is revoked immediately.
Clients locate the authorization server through the endpoint's own protected resource metadata (RFC 9728) and authorization-server metadata (RFC 8414). Self-hosted deployments route the same discovery to the customer's identity provider (e.g. Keycloak) — one code path, no SaaS dependency.
Access tokens carry a resource audience (RFC 8707) validated by the API, so a token minted for the MCP endpoint cannot be replayed elsewhere.
Expired or malformed bearer tokens receive an RFC 6750 challenge pointing at the discovery document, so well-behaved clients silently refresh and retry instead of failing.
Third-party connectors self-register via Dynamic Client Registration (RFC 7591) and are tenant-bound only when a human authorizes them. First-party clients (the VS Code extension) are pre-registered with an exact-match redirect — they cannot be impersonated by a dynamically registered client.
Every OAuth connection is scoped to the single workspace the signing-in user picks, carries that user's own permission level, and can be revoked at any time. Scoped API keys remain supported for legacy and service-account integrations.
Encryption Everywhere
In Transit
All communication between clients and the API is encrypted via TLS. HSTS with preload is enforced to prevent protocol downgrade attacks. Database connections use authenticated, encrypted tunnels.
At Rest
Credentials and secrets are hashed or encrypted before storage. Database volumes use transparent data encryption. API keys are never stored in plaintext.
Built for Compliance
Elixium is architected to meet the requirements of major compliance frameworks. Our security controls are designed with these standards in mind from day one — not bolted on after the fact.
RBAC, audit logging, change management via TDD workflow, encryption at rest and in transit
Architecture aligned to NIST 800-53 controls. GovCloud deployment and FIPS 140-2 support for self-hosted customers
Self-hosted deployment with encryption, access controls, and audit trails designed to support BAA requirements
Self-hosted deployments on AWS GovCloud are designed to support FedRAMP High, DoD IL4-IL6, and air-gapped environments. Contact sales for compliance roadmap details and security architecture review.
How the images themselves are built & trusted
The controls above govern the running platform. The container supply chain underneath — hardened, signed, SBOM'd, and FIPS-mode — is built and maintained in-house. See how Elixium is assembled and verified, offline included.
Need the Full Security Architecture?
Detailed security documentation including control mappings, communication channel analysis, and incident response procedures is available to enterprise customers and compliance auditors under NDA.
Contact Sales