Licensed to be used in conjunction with basebox, only.
// security
Infra Policy
- As of: October 2025
- Issuer: basebox GmbH
- Address: Bahnhofplatz 3, 86919 Utting am Ammersee, Germany
- Contact: datenschutz@basebox.ai
1. Purpose and scope
This document describes the technical and organisational measures (TOMs), governance structures and security mechanisms of the basebox AI Management System (basebox Server).
It serves as evidence of the implementation of the obligations under the EU AI Act (Regulation (EU) 2024/1689) and relevant data protection requirements (GDPR).
The information applies exclusively to basebox Server (dedicated installation at the customer).
basebox Cloud is a separate product and has no technical connection to basebox Server installations.
2. System architecture
2.1 Provisioning
- Operation exclusively on a dedicated server of the customer (basebox Server).
- basebox has no control over the operating environment or connected models.
- Maintenance access takes place exclusively via VPN/PAM, time-limited and approved by the customer.
- Air-gapped option supported by default.
2.2 Containerisation
- Installation via Docker or Kubernetes (k8s), according to customer preference.
- Hybrid setups possible: e.g. LLM on a Docker server, RAG + management system on a separate k8s cluster.
- Container images are provided by basebox; operation and orchestration are the customer's responsibility.
2.3 Component overview
| Component | Function |
|---|---|
| Management Core | Central interface for model, user and permission management |
| RAG Engine | Processing of local knowledge sources (retrieval-augmented generation) |
| REST API | Integration of external systems and apps |
| Model Runtime Layer | Local execution of quantised LLMs (e.g. Llama 3.3 70B) |
| Identity Provider (Keycloak) | Local user and token management (OIDC-compatible) |
2.4 Multi-tenancy
- The system supports several separate projects/tenants per installation (e.g. departments, organisational units).
3. Role and permission management
- Two active roles:
Admin: creates API keys, manages models, data sources and users. User: uses provided apps and models without being able to change the system configuration. - Authentication via username/password or OIDC/Keycloak.
- API access only via API keys generated by the admin.
4. Logging & monitoring
| Aspect | Status | Description |
|---|---|---|
| System logging | Implemented | Recording of technical events (system status, runtime errors, requests) |
| Prompt/response logging | Optional (trace level) | Only with active debug level; disabled by default |
| Log access | Admin only | Only with shell access to the server |
| Log storage | Customer-dependent | Use of syslog or systemd-journal; no separate retention by basebox |
| Export function | Planned | Future REST interface for audit export |
5. Security & updates
| Measure | Status | Description |
|---|---|---|
| Integrity check (signatures) | Not yet implemented | SHA256 signatures for container images in preparation |
| Security updates | Implemented | Announcement by e-mail + release notes |
| Access control | Implemented | Username/password, API keys, Keycloak (OIDC) |
| Process stop / kill switch | Partial | Possible manually at shell level, no UI switch |
6. Data protection & data flow
| Aspect | Status | Description |
|---|---|---|
| Telemetry | Disabled | No data transfer to basebox or third parties (air-gapped) |
| Data storage | Local | All files, embeddings and knowledge sources remain in the customer network |
| Deletability | Implemented | Users/admins can delete locally stored content (history, RAG files) |
| Encryption at rest | Not yet implemented | Currently TLS encryption for data in transit only |
7. Oversight & audit
| Aspect | Status | Description |
|---|---|---|
| Manual review function | Not implemented | No internal pre-review of AI outputs |
| Support/incident reporting | Implemented | Integrated ticket function for reporting errors or risks |
| Release documentation | Implemented | Release notes + changelog for every version, distributed by e-mail |
| Security tests before release | Implemented | Static code analysis, dependency scan, CVE check, unit tests, test installation and manual QA |
8. Governance & responsibilities
| Role | Responsibility |
|---|---|
| basebox GmbH (supplier) | Development, technical provisioning, maintenance, security reviews |
| Customer (deployer) | Operation, data processing, risk analysis, transparency, human oversight |
| Customer administrator | Management of local users, API access, models and knowledge sources |
9. Changes and versioning
- Every new version receives its own release notes and a version number.
- The code base is versioned internally (Git) and released under the four-eyes principle.
- Security-relevant updates are prioritised and actively communicated to customers.
10. Summary (compliance status)
| Category | Assessment |
|---|---|
| Infrastructure & access | Fully implemented |
| Logging & monitoring | Basically in place, audit export planned |
| Security & updates | Partially implemented, signatures pending |
| Data protection | Air-gapped, TLS active, encryption at rest planned |
| Oversight & audit | Support / testing active, manual review planned |
basebox GmbH
Bahnhofplatz 3
86919 Utting am Ammersee
Germany
E-mail: datenschutz@basebox.ai
*This document describes the current technical state of the basebox Server edition of the basebox AI Management System.
It serves as evidence of the measures implemented under the EU AI Act (Regulation (EU) 2024/1689) and can be used for internal or external audits.*