Trust

Security claims should be verifiable too.

Last updated: September 2026

Acadex handles research conversations, documents, saved context, and account data.

We therefore try to describe our security and privacy measures the same way we describe research results: concretely enough that you can understand what is actually happening.

This page describes the current state of Acadex.

Where something depends on configuration, we say so.

Where something is not yet implemented, we say that too.

Core infrastructure in Germany.

Acadex’s central application infrastructure runs in Germany.

Our primary PostgreSQL database and the backups managed by Acadex are also hosted or stored in Germany.

Our current infrastructure provider is STRATO GmbH.

This does not mean that every external service Acadex may use processes every category of data exclusively in Germany or the EU.

Model-provider processing is a separate part of the system and depends on the processing profile configured for the account.

External Services & Sub-processors →

Sensitive content is encrypted before it reaches the database.

Data sent between your browser and Acadex is protected in transit using TLS.

For particularly sensitive stored content, Acadex also applies field-level encryption using AES-256-GCM.

This includes content such as:

• conversations,
• saved memories,
• uploaded documents,
• chat titles,
• stored request content.

The encryption key is kept separately from the application database.

Passwords are not stored in plaintext. Password hashes are generated using Argon2id.

One important exception: searchable memory.

Some saved context needs to remain searchable so Acadex can retrieve relevant information later.

The text used for semantic memory search therefore cannot be protected with the same field-level encryption while it remains actively searchable.

We document this exception rather than describing all stored content as encrypted in exactly the same way.

Embeddings used for this search are generated locally by Acadex.

We do not send memory text to a separate external embedding provider for that purpose.

Administrative access is deliberately narrow.

Production access is limited to authorised administrative personnel.

Administrative systems such as our hosting environment and source-code infrastructure are protected with multi-factor authentication.

Production SSH access uses cryptographic keys rather than password authentication.

Administrative accounts are individual accounts.

We do not intend to use shared administrator credentials.

Secrets are kept outside the codebase.

API keys, database credentials, encryption keys, and comparable secrets are not stored in the application source code.

They are maintained in a dedicated encrypted password-management system.

Production secrets are provided to the application at runtime.

Access is currently limited to the technical administration of Acadex.

Secrets are rotated periodically and additionally when there is reason to suspect that a credential may have been exposed.

The encryption material used for protected database fields is kept separately from the database itself.

Development is separated from production.

Development and testing environments are separated from the production environment.

Production data is not routinely copied into development or testing systems.

Acadex is developed in a version-controlled monorepository.

Changes are developed through separate branches and reviewed before they reach production.

Automated tests are part of the development process, supplemented by manual acceptance testing where appropriate.

The application is deployed in containers.

Production deployments are currently performed by the technical lead.

We do not use your research content to train Acadex.

Acadex does not use your conversations, uploaded documents, saved memories, or research work to train its own models.

We also do not use that content for advertising profiles or behavioural product analytics.

Where Acadex sends content to an external model provider in order to answer a request, the handling of that content depends on the provider and the processing profile in use.

For institutional accounts, those profiles can be restricted.

Product metrics are not content analytics.

We need to understand whether Acadex is being used and whether the product is technically and economically viable.

For that purpose, we collect a small number of first-party operational and product metrics.

These can include things such as registrations, activation, plan status, cancellations, credit usage, and aggregated page views.

We do not use the following for product analytics:

conversation content, prompts, answers, uploaded document content, saved memories, research interests, research topics, or bibliographic search queries.

Our principle is:

We measure events, not behaviour.

Or more simply:

We want to know whether Acadex is being used — not what people are researching.

No external behavioural analytics.

Acadex does not currently use services such as Google Analytics, Mixpanel, Amplitude, Meta Pixel, LinkedIn Insight Tag, or session-recording platforms.

Website statistics are generated server-side on our own infrastructure.

They are designed to tell us things such as how often selected pages are viewed.

We do not create a persistent analytics visitor identifier, fingerprint browsers, or build cross-site profiles.

Full IP addresses are not kept as long-term analytics identifiers.

URL query strings, search terms, and complete referring URLs are not collected for this purpose.

Because this analytics design does not require an optional analytics cookie or comparable browser storage, we do not use a cookie-consent banner solely for these statistics.

Necessary storage for functions such as authentication, language, or appearance settings is treated separately.

Model providers are controlled separately from Acadex infrastructure.

Acadex can work with models from different providers.

A provider being technically integrated does not mean that it processes data from every account.

We distinguish between:

a supported provider,
a provider approved for a particular account,
and a provider that actually receives data for a particular request.

For institutions, permitted processing paths can be restricted at the account level.

That restriction is enforced by Acadex rather than being left to each individual user.

A model name does not define the full processing path.

The same model family can sometimes be reached through different technical infrastructure.

Those paths can differ in processing region, retention, available privacy controls, and contractual relationships.

Acadex therefore treats the processing profile — not merely the model name — as the relevant unit for institutional configuration.

Where an institution requires research content to be processed within the EU, only processing profiles that have been implemented, reviewed, and approved for that requirement should be made available to the account.

We do not describe a planned regional route as available before it has actually been implemented and verified.

Internal search stays internal where possible.

Acadex uses internal search and vector infrastructure to support features such as retrieval and semantic memory.

Embeddings used for these internal functions are generated locally.

Derived search indexes and vector databases are treated differently from the primary application database because they can be reconstructed from their source data where necessary.

The primary PostgreSQL database remains the authoritative store for user data that cannot simply be reproduced from public sources.

Logs are for operations, not research profiling.

Operational logs are necessary to diagnose failures, detect abuse, and protect the service.

Conversation content is not written to application logs.

Logs may contain technical information such as user identifiers needed for diagnosis and IP addresses used for security controls such as rate limiting.

Local operational logs are retained for a limited period.

Older logs can be compressed and encrypted before being transferred to a separate archive system, where they are retained only for the defined operational period.

Access is restricted to administration.

Logging is not used to reconstruct what individual users are researching.

You can delete your data.

Users can delete conversations, memories, and uploaded documents from Acadex.

They can also delete their account.

Our database structure uses cascading relationships where appropriate so that associated user data is removed together.

We also use automated schema checks intended to identify tables containing user-linked information that are not covered by the expected deletion logic.

Deletion from active systems does not necessarily mean that every historic backup copy disappears at the same instant.

Deleted data can remain in existing backups until those backups reach the end of their retention period.

Product metrics follow the account where they are still personal.

Account-linked product metrics are generally removed when the account is deleted unless another legal retention obligation applies.

Statistics that have already been genuinely aggregated or anonymised may remain where they can no longer be linked back to an identifiable account.

Backups focus on data that cannot simply be reconstructed.

Not all data in Acadex has the same backup value.

User accounts, conversations, memories, documents, and other primary application data require direct protection.

Other datasets — such as public bibliographic data, derived search indexes, or vector indexes — can often be reconstructed from their source data.

Our backup strategy therefore distinguishes between primary data and reconstructable data rather than treating every terabyte identically.

Backups managed by Acadex are stored in Germany.

During Early Access, we are still formalising parts of the backup and restore-testing schedule.

The concrete PostgreSQL backup interval, retention period, and regular restore-test cadence are documented in our Technical and Organisational Measures once finalised.

We would rather leave those values explicitly open than publish a schedule that is not yet operationally established.

Availability has limits.

Acadex currently runs as a single application instance.

It is not yet deployed as a high-availability multi-instance system.

That means we do not claim seamless failover or uninterrupted availability.

The architecture can evolve toward multiple instances later, but we do not describe that future state as if it were already deployed.

We also do not currently offer a general uptime SLA.

Monitoring is still developing.

System health and production operation are currently monitored administratively.

We do not yet operate the kind of fully developed external monitoring and alerting infrastructure that we ultimately want for broader institutional deployment.

Additional monitoring infrastructure is planned.

Until it is actually running, we do not describe Acadex as being subject to continuous automated 24/7 monitoring.

Security incidents follow a defined response path.

If we identify a suspected security incident, our response is based on a simple sequence:

identify → contain → investigate → assess → document → communicate → improve

Depending on the incident, this can include revoking affected credentials, preserving relevant logs, determining which systems or data may have been affected, assessing notification obligations, informing affected customers or controllers, and implementing follow-up measures.

Technical incident handling and external communication are separated so that both can happen deliberately rather than ad hoc.

Institutional controls can be stricter than the default account.

Institutional deployments can require additional restrictions around which model providers may be used and where research content may be processed.

These restrictions can be enforced at the account level.

Institutions can also receive documentation covering our Technical and Organisational Measures, subprocessors, provider configuration, and data-processing arrangements.

Acadex for Institutions →

What Acadex does not currently have.

We think it is useful to state this explicitly.

Acadex currently does not have:

individual-user multi-factor authentication, institutional SSO, ISO 27001 certification, a SOC 2 report, a completed external penetration test, a general uptime SLA, or a fully redundant high-availability deployment.

Some of these are likely to become relevant as institutional use grows.

They are not current capabilities simply because they appear on an enterprise-security checklist.

Security changes over time.

Security is not a document that becomes finished once it has been published.

We review technical controls as the system changes and update our documentation when the actual implementation changes.

Our Technical and Organisational Measures are versioned so that institutional customers can see which state of the system a document describes.

Some formal review intervals are still being established during Early Access.

Found a security issue?

If you believe you have found a security vulnerability or privacy issue in Acadex, please contact:

info@acadex.io

Please include enough information for us to understand and reproduce the issue where possible.

We do not currently operate a formal public bug-bounty programme or publish a broad vulnerability-research safe-harbour policy.

If that changes, we will document the scope explicitly rather than implying protection that has not been defined.

Further documentation

Technical and Organisational Measures →

External Services & Sub-processors →

Privacy Policy →

Data Processing Agreement →

Acadex for Institutions →