Licensed to be used in conjunction with basebox, only.
// security
Storage
Applies to
Product: Demo · Cloud · Server · Audience: Security / Compliance reviewer
Where documents, embeddings, chat data, audit logs and secrets are stored – and how these locations are protected at rest. The operations view (volumes, storage classes, sizes) is under Storage; here the reviewers' question is addressed: Which data sits where, who can reach it, what happens in the backup?
What sits where
| Data | Location | Contains personal data? | Note |
|---|---|---|---|
| Users, organizations, roles, groups, settings | PostgreSQL aisrv-db |
Yes – names, e-mail addresses | Core of the application |
| Apps, app configuration, system prompt | aisrv-db |
Possibly (system prompt content) | – |
| Audit log | aisrv-db |
Yes – user identifier, timestamp, client address; at a high detail level additionally prompts, server-side and separate from the chat history | Retention configurable (Retention) |
| Connector credentials per user | aisrv-db, stored write-only |
Yes | Administrators do not see them; never in production logs |
| Chat history | Locally in the user's browser, not stored permanently on the server; no synchronization between devices (Chat history & data) | Yes – content | Sits with the user; administrators and basebox have no access to it |
| Document passages and embeddings of knowledge bases | PostgreSQL ragsrv-db (pgvector) |
Yes, if the documents contain any – embeddings are to be treated as derivable from the text | Grows with the number of documents |
| Uploaded files / media | Persistent volume AISRV_MEDIA_ROOT |
Yes, depending on content | Chat uploads and knowledge base files |
| Temporary RAG files | /tmp/ragsrv (shared volume) |
Yes, temporarily | Used during processing |
| Identities, realms, OIDC clients | PostgreSQL idp-db (Keycloak) |
Yes – accounts, possibly password hashes of local accounts | With LDAP federation, passwords stay in the directory |
| Model weights, caches | Volumes of inference and ragsrv-support | No | Recreatable |
| Secrets: database passwords, Keycloak admin, TLS keys, inference/registry keys | Kubernetes Secrets (etcd) | No, but security-critical | Access via Kubernetes RBAC |
Source for the mapping: basebox components → What is stored where.
Where these stores physically are
| Deployment | Physical location | Who has administrative access |
|---|---|---|
| basebox Cloud | basebox's own server in the Noris data center in Munich, inside your isolated environment | basebox operations as platform operator (Administrative access); you via the application |
| basebox Server | The dedicated server – in the customer's or basebox's data center | Your Platform Operator; basebox only when commissioned via Remote maintenance |
| Demo | Test infrastructure | No commitment; no real data |
On a server all the stores listed stay in the customer network; none of it is mirrored to basebox (telemetry disabled).
Protection at rest
The basebox application currently does not itself encrypt stored data – the Infrastructure policy and the Safety notice say so explicitly. Protection at rest comes from the layer below:
- Storage layer: encrypted disks or an encrypting storage class (Server: a matter for the Platform Operator; Cloud: basebox ).
- Access control: databases are reachable only inside the cluster, credentials sit in secrets; Kubernetes RBAC limits who may read secrets; etcd encryption is a cluster setting.
- Backups: contain the same data as the databases – dumps and object storage targets must be encrypted and access-restricted (Backup & restore).
Consequence for the review: include the storage layer in your security concept; it is the control that replaces the missing application-level encryption. Details: Encryption.
Special data categories
- Embeddings are not anonymization. From document passages and their vectors the content can be reconstructed or at least inferred; treat
ragsrv-dblike the documents themselves. - Knowledge bases have no per-user permission check: whoever may use the app can reach all its documents through the model (Knowledge bases). Sensitive content belongs behind a connector with personal credentials.
- Audit log with conversation content is the most sensitive table of the installation as soon as the detail level is set to questions or questions and answers – keep retention short, protect exports (Audit & logging).
- Connector credentials are stored write-only but are contained in database dumps – treat dumps accordingly.
What users see
Users see their own chats and uploads. Administrators see users, apps, knowledge bases and the audit log – not other users' chats, except via the explicitly configured recording in the audit log, which is then shown to all users in the chat (Where is my data?).
Next step: Encryption