Eldarion keeps your client data safe with world-class security and data privacy measures.
Request the security whitepaperEvery account starts with no permissions and stays inactive until an administrator approves it. Three permission levels are enforced as a mandatory dependency on every endpoint, and administrator status is re-read from the database on every request — never trusted from the session token.
Model-generated code is untrusted by definition and never runs in the main application. It executes in its own container, reachable only from the internal network, with no public URL, no database access and no credentials — plus hard CPU, memory and wall-clock limits per call.
TLS 1.2 or higher on all web and API traffic, AES-256 at rest across all storage with keys managed by the cloud provider. Generated files are served only through short-lived HMAC-SHA256 signed links, bound to the identity that requested them.
Every administrative action is chained with SHA-256: each entry carries the hash of the one before it, so altering or deleting a historical record breaks the chain and is detectable. The log is append-only, and a CI check fails the build if an administrative operation ships without a trace.
Eldarion does not train or fine-tune models on customer data, builds no derived datasets from it, and never sells or hands that content to third parties. Model providers are used only through their commercial APIs, whose terms exclude API inputs and outputs from training.
Every URL a model reaches for passes an SSRF verifier that rejects private, loopback and cloud-metadata addresses. Model-generated SQL passes a read-only sanitiser over read-only credentials. Report content is sanitised on write and re-escaped on render, and third-party payloads are validated against a typed schema.
Eldarion runs an AI-assisted financial analysis platform for professional clients. Security is not a layer added on top: the threat model, the trust boundaries and the controls described here are part of the product's design and are reviewed continuously. The answers below are taken from our platform security and privacy whitepaper.
Request the security whitepaperCustomer data is everything a client entrusts to us or that is generated on their behalf while using the platform. We classify it in three categories, each with its own access level, retention rule and export rules: regulated personal data (account identity and the activity tied to a natural person), customer content (queries, conversations, documents, modelled portfolios, workflows and generated reports) and operational data (metrics and technical logs with no personal data).
What we deliberately do not store matters just as much: no payment or banking data, no real trading positions, orders or custody balances, no lists of our clients' own end clients or investors, and no special categories of personal data.
Through overlapping controls, so that one failing does not compromise the whole: encryption in transit (TLS 1.2+) and at rest (AES-256) across all storage; least-privilege access, with explicitly approved accounts, three mandatory permission levels per endpoint and every query filtered by the authenticated identity; isolated AI execution, with model-generated code running in a separate environment with no database or credential access, strict resource limits and no public exposure; input sanitisation against SSRF, SQL injection, stored XSS and active content in reports and email; credentials held in a secrets manager with scheduled rotation, plus automatic redaction of secrets in logs; downloads through signed links that expire and are bound to the requester's identity; and no trackers — the product sets no first-party cookies and loads no third-party analytics on authenticated routes.
The platform is hosted on Google Cloud, region europe-west1 (Belgium, European Union). Compute, the database, generated-file storage, the secrets manager and task scheduling all live there. Storage and ordinary processing of customer data happen in the EU.
The exception is language-model inference: query content is transmitted encrypted to our model providers, whose processing centres sit outside the EU, under the standard contractual clauses of their respective data processing agreements. That transfer happens only when a user runs a query; no other flow of customer data leaves the European region. We provide the full sub-processor list, with purpose and region, during vendor review, and give advance notice of any change.
Access control is enforced on the server, on every request — never in the interface. Signing up grants nothing: the account stays inactive until an administrator approves it, and suspension takes effect immediately. Permissions are checked through a mandatory dependency on every route across three levels — authenticated, approved, administrator — and privileges are re-read from the identity store on every request, so a revocation is effective on the next call.
Conversations, files, portfolios and workflows are always queried scoped to the requester's identity, and a signed download link presented by a different identity is rejected even when the signature is valid. Internal operations require administrator status, and it is not only changes that are recorded: reads of customer content are logged too, so every administrative access to a conversation, a user record or an execution trace leaves a named trace. For clients who need organisation-level isolation beyond per-user isolation, we offer a dedicated deployment.
Eldarion does not train or fine-tune models on customer data. We run no training, no fine-tuning and build no datasets derived from our clients' content, and we neither sell nor pass that content to third parties for any purpose.
As for the model providers, the platform consumes them exclusively through their commercial APIs, whose terms of service state that inputs and outputs sent via API are not used to train their models. This forms part of our sub-processor assessment, and we can provide each provider's applicable terms in writing during vendor review.
Internally the separation is structural: the environment that runs AI-generated code has no access to the database or to credentials, and the technical execution traces we keep for diagnostics are stored without message content and purged after 30 days. Product improvement rests on aggregated metrics and errors, not on conversation content.
Each entry records who (the administrator's identity and name, captured at the moment of the action), what (the action, drawn from a closed catalogue the system validates), on whom or on what, with what detail and when (UTC timestamp).
State-changing actions are recorded: account approval, suspension and deletion; granting and revoking administrator privileges; usage-limit changes; password resets; functional configuration changes; and user communications. So are staff reads of customer content — opening a user record, a conversation or an execution trace. That is deliberate, because the question a client needs to answer is not only "who changed this?" but "who has seen my data?".
Integrity comes from a SHA-256 chain: each record carries the hash of the previous one and writes are serialised to guarantee order, so altering or deleting a historical entry breaks the chain and is caught by a verification function available to the administrator. The log is append-only, and an automated CI check prevents a new administrative operation from shipping without its trace.
On a three-tier cadence. On every change: mandatory peer review, an automated test matrix across operating systems and language versions, automated policy checks and verification that every administrative operation leaves an audit trace — nothing reaches production without passing them. Continuously and on event: credential-leak scanning over the repository, triage of every dependency advisory (confirming whether the affected code path is actually reachable before deciding), and a public responsible-disclosure channel with committed timelines — acknowledgement in 5 business days, triage decision in 10, status updates every 14 until closure. Periodically: internal security review updating the STRIDE threat model by trust boundary and the accepted residual risk, review of the credential inventory and its scheduled rotation (90 days for signing material and internal integrations, 180 days for provider keys), and verification of the audit chain's integrity.
On external validation: formal third-party certifications of the SOC 2 kind are on our roadmap and have not yet been completed. The audit log has already been designed as evidence for those frameworks. We make the threat model and controls documentation available to your security team, and we coordinate penetration tests with clients who require them as part of vendor review.