Security practices you can inspect.

All API traffic is encrypted in transit with TLS, terminated at our gateway. Plain-HTTP API requests are not accepted. Traffic between the gateway and nodes runs over a private network that is not reachable from the internet.

On eligible dedicated deployments, a private tunnel (for example site-to-site VPN or WireGuard) can be used in addition to, or instead of, the public TLS endpoint.

• Bearer-token API keys on every request; unauthenticated requests are rejected at the gateway.
• Multiple keys per account, so you can separate environments and services.
• Rotation: issue a new key, deploy it, then revoke the old one — without downtime.
• Revocation takes effect at the gateway; a revoked key can no longer be used.
• Per-key rate limits to contain the impact of a leaked key.

Keep keys server-side. Never embed them in browser or mobile clients. See the documentation for recommended handling.

• Private AI Nodes are dedicated: the physical node serves one customer only.
• Dedicated nodes are isolated from other tenants at the network level.
• IP allowlisting restricts a dedicated endpoint to your source addresses.
• VPN connectivity is available on eligible Private AI Node and High Availability plans.
• Shared Managed AI API plans are separated per customer at the API layer: authentication, rate limits and request isolation.

• Administrative access to infrastructure is limited to named engineers.
• Key-based authentication for administrative access; no shared accounts or password logins.
• Least privilege: engineers receive only the access their role requires, reviewed when roles change.
• Administrative access is logged.
• Access is removed promptly when it is no longer needed.

Hardware, runtimes and endpoints are monitored continuously, with alerts routed to the engineers who operate the platform. Service status is published on our status page.

If we become aware of a security incident affecting customer data, we notify affected customers without undue delay, share what we know as we learn it, and support you in meeting your own notification obligations. The process, including the information we provide, is described in the Data Processing Agreement.

• Lirux does not train models on customer prompts, responses or files.
• Requests are processed in memory to produce a response.
• Request metadata (timestamp, model, token counts, status code) is logged for billing, rate limiting and operations.
• Content logging is configurable on dedicated deployments, including switching it off.
• Retention is configurable on dedicated deployments; defaults are defined in the DPA.

For roles, international transfers and a data classification guide, see Data processing.

Compute runs in Georgia on hardware we operate ourselves. Physical access to the hardware is limited to authorised personnel, and customer endpoints are reached only through our gateway or a private tunnel.

We do not publish the facility address or rack-level details, and we do not claim facility certifications. Further detail on physical and environmental controls can be provided under NDA during procurement.

If you believe you have found a security vulnerability in our website, API or infrastructure, email [email protected] with a description, the steps to reproduce and any proof of concept. Please give us reasonable time to investigate and fix the issue before disclosing it publicly.

Act in good faith: do not access, modify or delete data that is not yours, do not degrade the service for others, and do not use social engineering or physical attacks. We will acknowledge your report and keep you informed. We do not currently run a paid bug bounty.

Contact: mailto:[email protected]
Preferred-Languages: en, de
Policy: https://lirux.ai/security#disclosure

In the meantime we describe our controls on this page, provide a Data Processing Agreement with technical and organisational measures, and share further documentation under NDA. Send questionnaires to [email protected].