ELION is built so that each client's data is separate, credentials stay server-side, and status is always truthful.
#What ELION does
- Client isolation : data is scoped per organization at the database and API level, not just hidden in the interface.
- Server-side credentials - provider keys and OAuth tokens are stored and used server-side and are never sent to the browser.
- Role-based access : admin and client surfaces are separated, and client-facing routes only expose that client's data.
- No secrets in logs : execution logs record operational information and never API keys, passwords or tokens.
#Client isolation
Client A can never see Client B's conversations, credentials, workflows, configuration or results. Isolation is enforced by the database and the API layer: every query is scoped by the authenticated organization, so isolation holds even if the interface were bypassed.
#Server-side credentials
Google OAuth tokens, WhatsApp/API credentials and other provider secrets are stored on the server and referenced by the automation that needs them. Public APIs return connection state (connected, not configured) , never the credentials themselves.
#Authentication and roles
- authentication through the platform's managed auth,
- admin versus client role separation,
- client access limited to the client's own organization, and
- admin APIs that require admin authorization.
#What ELION does not claim
ELION does not claim security certifications, compliance standards or guarantees it has not earned. No certification claims (such as SOC 2 or ISO) are made unless independently verified and published. If you need a specific assurance for your procurement, ask during onboarding : ELION will answer truthfully about what the architecture actually provides.