Principles
- Closed by default. A new server answers only its own computer. Serving a network needs two independent things: a paid licence (the server may serve) and at least one API key (who may call). Without a key a network bind falls back to this computer only; an explicit network address refuses to start.
- No content at rest. Prompts, documents and answers live in memory for the length of a request. They are not written to logs, usage records, audit files or telemetry.
- Fail safe on tampering, keep serving through our outages. A forged or altered licence is rejected; an unreachable licence service does not stop a licensed server.
Authentication
- API keys are random secrets shown once. The server stores a salted PBKDF2-SHA256 hash (100,000 iterations, 16-byte salt), never the key.
- Keys are accepted in
Authorization: Bearer,api-keyorx-api-key. On the live-transcription WebSocket only,?key=is accepted because browsers cannot set headers there; the server never logs it. - Repeated wrong keys from one source are throttled, so guessing is impractical and does not burn server CPU.
- AI Suite apps on the same computer are recognised by a signed request delivered over the loopback interface. This grants no access from the network and is not an API key.
Authorisation
| Layer | Controls |
|---|---|
| Key scope | Model allowlist, endpoint categories (chat, models, embeddings, images, audio, vision, pull), expiry, per-key rate |
| Administration right | Usage for all keys, audit export, request activity, metrics and gateway status need a key with Allow server administration; new keys do not have it |
| Unknown endpoints | Any /v1 or /api path without a category is treated as restricted and counted, never as free and open |
| Governance (Commercial) | Rate limits, quotas, budgets, lifecycle (approve, deprecate, block), content rules, moderation, curated mode |
In a gateway farm clients hold only gateway keys and the gateway holds per-worker keys, so a client key is worthless against a worker.
Transport
- HTTPS with a built-in self-signed certificate (pinned by AI Suite apps on first use) or your own certificate; or TLS terminated at your proxy.
- If HTTPS was requested and the certificate cannot be loaded, a network-bound server stops instead of falling back to HTTP.
- On a server bound to its own computer, requests addressed to any other host name are refused — this blocks DNS-rebinding attacks from web pages.
- Forwarded client addresses are trusted only when an operator says so, and only from the proxy addresses they list.
- Browser origins must be allowed explicitly (CORS), including for the WebSocket.
Licensing integrity
- Activation returns a lease signed with ECDSA P-256 (ES256). The server verifies it against public keys compiled into the product, so a different licence server can only relay leases we signed, never mint one.
- Leases expire after 7 days with 7 days' grace, and the server detects clocks set backwards.
- An invalid, revoked or expired key stops the server instead of silently serving less.
Audit
- Every request produces a content-free audit record: time, endpoint, model, key id, app, status, latency and token counts.
- Exports are signed with ES256 and verifiable offline with the CLI or any ECDSA tooling; signing keys rotate with history kept; RFC 3161 timestamps are optional.
- Daily files can be shipped to your SIEM; retention follows your region policy.
Secrets at rest
| Secret | Protection |
|---|---|
| API keys | Salted PBKDF2-SHA256 hashes only |
| Cloud provider credentials | Encrypted at rest with AES-256-GCM |
| Licence key | Supplied as a file or app setting; never logged |
| Audit signing key, gateway worker keys | In the data folder; owner-only file permissions on Linux; keep in secret storage |
Logs pass through a redaction step that removes keys and secrets, including values in query strings.
Process isolation
- The Windows service runs as its own virtual account,
NT SERVICE\AISuiteServer, with access to AI Server's folders only. If that account cannot start, the installer falls back to LocalSystem and records why. - Container images run as a non-root user (UID 1654), drop all Linux capabilities in the Helm chart, and keep state in
/data. - The Windows app is distributed as a signed Microsoft Store package.
Data inventory
| Data | Kept where | Leaves the server? |
|---|---|---|
| Prompts, documents, media, answers | Memory, during the request | Only to a cloud provider an operator configured and a user chose |
| Usage and audit records (content-free) | Data folder | Only signed exports you request, or your configured SIEM |
| Live request activity (includes client address) | Memory, 15 minutes | No; shown to the local operator only |
| API key hashes, settings, governance | Data folder | No |
| Licence lease and activation ids | Data folder | Activation and renewal only |
Outbound connections
| Destination | When | What is sent |
|---|---|---|
Software Tailor licence service (registration.softwaretailor.com) | Activation, then about every two days | Licence key, random installation and machine ids, node name, OS family, gateway role |
| Model and engine sources (for example Hugging Face and GitHub releases) | When a model or engine is downloaded or updated | Download requests only |
| Software Tailor telemetry service | Only with consent and where regional rules allow | Content-free counts and versions |
| Cloud AI providers | Only if an operator configures one | The requests users send to those models |
| External moderation endpoint, SIEM, timestamp authority | Only if configured | Text to be checked; audit files; export hashes |
| Microsoft Store | Updates of the Windows app | Handled by Windows |
Ask support for the full host list for your firewall.
Reporting a vulnerability
Report security issues privately through the trust centre. Please do not open a public issue.