Existing APIs only
Every Alumio request uses an existing API endpoint and the API credentials stored for that environment.
Security at Alumio Labs
The features are beta.
The safeguards are not.
Labs connects to Alumio through authenticated APIs with read-only access by default. API credentials and protected feature data are encrypted before storage, and write actions require separate authorization and safeguards.
Platform boundaries
Controlled access to your environment.
Labs connects to Alumio through authenticated APIs. Access uses an API key you provide. Revoking or replacing that key prevents subsequent Labs requests from using it.
Read-only by default
Labs uses read-only API access by default. Write actions use a separate, explicitly authorized path.
Write methods blocked by default
Labs explicitly blocks PUT, PATCH, and DELETE requests in its read-only API path. Only approved read-only POST endpoints are allowed.
Safeguarded write actions
Allowed write actions require explicit authorization and safeguards defined for that action before they can run.
Existing state protected
When an action can replace existing configuration, Labs validates the change and captures the current state before applying it.
Identity and access
Verified identity, scoped access.
A verified identity does not automatically grant organization access. Auth0 verifies identity. Active Alumio membership determines which organizations you can access, and database-level security protects user-scoped requests.
Auth0 sign-in
You sign in through Auth0. Labs then links your verified email to synchronized Alumio organization memberships.
Verified email only
Only verified email addresses can be used to create or link an account.
Database-level security
Database-level security limits user-scoped requests to organizations where you have an active membership.
HTTPS in production
The production Labs app and its configured service endpoints use HTTPS.
Data protection
Encrypted before storage, verified before use.
API credentials and protected feature payloads are encrypted before storage. Decryption happens in server-only code. Protected payload content is not sent to the browser.
AES-256-GCM encryption
AES-256-GCM encrypts Alumio API keys and protected feature payloads before storage.
Encrypted credentials
Your Alumio API keys remain encrypted at rest and are decrypted only on the server when needed.
Payload integrity checked twice
Encrypted feature payloads include SHA-256 hashes for the encrypted and plaintext data. Labs verifies both before using the payload.
Private payload storage
Encrypted feature payloads are stored in a private bucket. Storage policies deny direct browser access.
Secrets stay server-side
Encryption keys and the privileged database credential are accessed only from server-only modules and are not exposed to client code.
Payload metadata only
For encrypted feature payloads, the browser receives metadata such as timestamps, sizes, and hashes. Payload content stays on the server.
Labs features can change.
Their safeguards don't.
Questions about how Labs accesses your environment or protects stored data are always welcome. Review the controls before you connect.