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.

AuthN

Authentication. 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.

AuthZ

Authorization (RBAC). Role-based access control with granular permissions per resource and operation. Every mutation endpoint is gated by authorization middleware.

Rate

Rate limiting. Multi-tier rate limiting protects against abuse and brute-force attacks. Stricter limits on sensitive operations like key generation and account changes.

Input

Input validation. Schema-based validation on all mutation endpoints. Unknown fields are stripped. System-managed fields cannot be modified through public API calls.

Audit

Audit logging. Every mutation and authentication event is logged with actor identity, action, timestamp, and request metadata. Logs are tenant-scoped and queryable by workspace admins.

Tenant

Tenant isolation. Multi-tenant data isolation enforced at the authentication, query, and authorization layers. Cross-tenant access is architecturally prevented.

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 agent clients 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.

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.

PKCE, mandatory. The authorization-code flow requires PKCE (S256) for every client; public clients like IDE agents never hold a client secret.

S256

Rotating refresh tokens. 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.

Standards-based discovery. Clients locate the authorization server through protected resource metadata and authorization-server metadata. Self-hosted deployments route the same discovery to the customer's identity provider (e.g. Keycloak); one code path, no SaaS dependency.

RFC 9728 · 8414

Audience-bound tokens. Access tokens carry a resource audience validated by the API, so a token minted for the MCP endpoint cannot be replayed elsewhere.

RFC 8707

Proper 401 challenges. Expired or malformed bearer tokens receive a challenge pointing at the discovery document, so well-behaved clients silently refresh and retry instead of failing.

RFC 6750

Client registration. Third-party connectors self-register via Dynamic Client Registration and are tenant-bound only when a human authorizes them. First-party clients are pre-registered with an exact-match redirect; they cannot be impersonated by a dynamically registered client.

RFC 7591

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.

SOC 2 Type IIReadyRBAC, audit logging, change management via TDD workflow, encryption at rest and in transit

FedRAMP ModerateReadyArchitecture aligned to NIST 800-53 controls. GovCloud deployment and FIPS 140-2 support for self-hosted customers

HIPAAReadySelf-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.

Security & Supply Chain →

Need the full security architecture?

Detailed documentation including control mappings, communication channel analysis, and incident response procedures is available to enterprise customers and compliance auditors under NDA.

Contact sales →