Licensed to be used in conjunction with basebox, only.
// security
Server
Applies to
Product: Server · Audience: Security / Compliance reviewer
A dedicated physical server for one customer – FAST LTA or customer hardware, in the customer's data center or basebox's, operated by the customer or contractually by basebox. Hosting at basebox does not turn it into Cloud. This page is the security view; the technical description is under Deployment models and basebox Server.
In one paragraph
On a basebox Server, platform, service models and inference run on hardware that belongs to or is dedicated to one customer. All data – users, chats, documents, embeddings, audit log – sit on this server in the customer network; telemetry to basebox is disabled; without a commission basebox has no access. If basebox is commissioned with installation or operation, access is via PAM/VPN, time-limited, approved by the customer, logged and revocable. The server can be operated air-gapped.
Three properties, no product change
| Property | Options | What changes security-wise |
|---|---|---|
| Hardware source | FAST LTA / supplied by basebox · customer-owned | Nothing in the software; supply chain and hardware support |
| Location | Customer data center · basebox data center | Who controls physical access and the surrounding network – Customer data center · Hosting at basebox |
| Operator | Customer · basebox when commissioned | Whether basebox has a maintenance access – Remote maintenance |
In every combination it remains one customer, one physical machine, no shared use (Dedicated hardware).
Security properties
| Property | Server | Details |
|---|---|---|
| Data storage | Local – all files, embeddings, knowledge sources and chats stay on the server in the customer network | Storage |
| Telemetry | Disabled; no data transfer to basebox or third parties | Infrastructure policy |
| Inference | On the server or a customer-controlled GPU host; optionally external models purchased separately by the customer | Model providers |
| Encryption | TLS in transit (ingress, AISRV↔inference across hosts, LDAPS, SMTP); at rest not by the application today – the customer's storage layer | Encryption |
| Access by basebox | Only when commissioned; PAM/VPN, time-limited, approved, logged, revocable | Remote maintenance |
| Air-gapped operation | Supported; web search and online model download are unavailable | Air-gapped environments |
| Outbound connections | Only what the Platform Operator allows: registry for images/charts, model downloads, web search provider, connector target systems, SMTP, directory | Networking |
| Logs | System and application logs with the customer; prompt/response content only at trace level, off by default | Audit & logging |
| Updates | Applied by the customer or by basebox under an operations contract; security updates are announced by e-mail and release notes | Updates |
| Backup | Responsibility of the operator; CloudNativePG backups or dumps, media, secrets | Backup & restore |
| Data protection role | Customer controller; basebox without access is not a processor – under an operations contract the role is regulated contractually | GDPR |
What is not yet implemented
The Infrastructure policy (as of October 2025) openly names what is missing: encryption at rest by the application, signatures for container images, a kill switch in the interface (today manual at shell level), a manual pre-review of AI outputs. Plan for these points in your security concept via the storage or operations layer.
For your security concept
On a server, most controls sit with you. The usual questions and where the answer is:
- Who may access the server? Your access concept; for basebox Remote maintenance.
- What goes out? Your firewall – list of paths under Networking; without internet Air-gapped environments.
- How is data protected? Storage and Encryption; encryption at rest via your storage layer.
- What is logged? Audit & logging; SIEM connection under SIEM integration.
- Who does what? Shared responsibility.
Next step: Shared responsibility