Security

1. Principles

Security is built into the architecture of our systems, not added afterwards. We design with least privilege and zero trust: several layers of authentication and authorisation stand before any access is granted, and if one layer fails the others still protect sensitive systems and data.

2. Where the software runs

Customer-controlled environments

For enterprise deployments, Nibelung software can run entirely inside the customer's own cloud (AWS, Azure, GCP) or on-premises infrastructure. The customer then controls data location, infrastructure management and access policies.

Isolated infrastructure

On infrastructure operated by Nibelung, each customer runs in its own isolated environment. Compute, database instances and storage are not shared between customers.

No cross-tenant data

By design, data from one customer never mixes with data from another, at every level: compute, storage, network and database. Shared components such as load balancers handle traffic only, not customer data.

3. Data protection

In transit

All data to and from Nibelung services is encrypted with TLS 1.2 or higher. Certificates are issued by trusted authorities and renewed automatically.

At rest

Sensitive data at rest is encrypted with industry-standard algorithms (AES-256 or equivalent). Keys are managed separately from the data they protect and are rotated.

Keys and secrets

Keys and secrets live in a dedicated secrets manager, never in code, logs or chat. Access to them is restricted to authorised people and audited.

4. Access and logging

Access to Nibelung systems follows least privilege:

• multi-factor authentication is required for administrative access
• role-based access control limits each role to what it needs
• every API call is authenticated
• sessions expire and unattended systems log out

Access to production systems and sensitive data is logged: who, what, when and from where. Logs are retained and reviewed, and unusual access patterns raise an alert.

5. Separation of duties

Critical operations need more than one person:

• deployments and infrastructure changes go through code review before they are applied
• access to sensitive data needs an independent approval
• key operations and backups need an independent authorisation
• incident response involves more than one team member

6. Incidents

Security incidents are detected through monitoring, user reports and threat intelligence. A designated responder coordinates the response, affected customers are informed promptly when their data is involved, the root cause is investigated, and every incident ends with a review of what has to change.

7. Shared responsibility

Ours

• infrastructure security and availability
• protection of our systems against unauthorised access
• encryption and secure data handling
• response to security incidents
• secure APIs and authentication

Yours

• safe handling of credentials and API keys
• access controls in your own infrastructure
• validation and protection of the data you provide
• keeping your software and systems up to date
• prompt reports of vulnerabilities or suspicious activity

8. Your data is not used to prepare our models

By default, customer data provided to Nibelung services is used only to provide the requested service. Preparing or improving models with your data requires your explicit consent and a separate agreement. Where models are prepared on aggregated or anonymised data, that data is subject to strict governance and access control.

9. Vulnerabilities

• code and dependencies are scanned automatically for known vulnerabilities
• third-party penetration testing is planned as we grow; the Compliance page states the current certification status
• critical vulnerabilities are patched first
• we work with vendors and open-source maintainers on issues we find

To report a vulnerability, write to info@nibelung.io with the subject Security. We acknowledge reports within 48 hours and follow responsible disclosure.