The AI Server security model: what fails closed and where each key lives
Most of an AI Server deployment's security is default behavior rather than configuration. This is the posture a customer's security review reads: what fails closed, where each credential lives, and what crosses which boundary.
Binding an AI Server beyond loopback requires a Pro entitlement and at least one API key, or the daemon refuses to start [1]. A misconfigured box cannot serve openly by accident. That fail-closed default is the first line of a posture whose parts are worth stating plainly, because the work of a security review here is understanding the behavior, not configuring it.
Keys are hashed, and rotate without a restart
The server stores each API key hashed with PBKDF2-SHA256 and a per-key salt; it can verify a key but never reveal it, and the raw key is shown once at issuance [2]. Rotation is issue a new key, update clients, revoke the old one, with no restart. Generic third-party clients are metered on the free tier, so an open port is never a free-for-all, while first-party and keyed traffic is unlimited.
Two credential tiers in a farm
In a gateway farm, clients hold one gateway key and the gateway holds a separate key per worker [3]. A client key never reaches a worker, so compromising a client credential exposes the gateway surface rather than the farm's boxes. Caller identity is pseudonymous and forwarded: apps declare app, install, and machine identifiers, never usernames or emails, and the gateway forwards them so per-caller accounting works fleet-wide. All monitoring and audit data is content-free; prompts and outputs are never persisted server-side.
Nothing impersonates the endpoint
Apps pin a server's fingerprint on first connect and warn if it changes, so a swapped endpoint cannot silently impersonate the real one [1]. The anonymous surface is deliberately minimal and inert: health probes, version, the policy descriptor, and a static dashboard shell that carries no data. Everything informative needs the key.
Private TLS to workers
Worker links can run over HTTPS with an internal CA or self-signed certificates, so the farm's internal traffic is encrypted without a public certificate authority in the loop [2]. Every recipe that serves beyond loopback inherits this model, which is why it is the recipe a security team reads before the others.
References
- Software Tailor. "AI Server — product page." softwaretailor.com/ai-server.htm. Accessed 2026-07-22.
- Software Tailor. "AI Server documentation — Licensing." softwaretailor.com/docs/ai-server/licensing.htm. Accessed 2026-07-22.
- Software Tailor. "AI Server documentation — Operations." softwaretailor.com/docs/ai-server/operations.htm. Accessed 2026-07-22.
- Microsoft. "AI Server on the Microsoft Store." apps.microsoft.com/detail/9P42956WBWCL. Accessed 2026-07-22.
Related articles
Answer the security row with receipts.
Fail-closed serving, hashed keys, forwarded pseudonymous identity, private TLS. Get it on Windows from the Microsoft Store, or read the feature tour first.