The Security Model

Individual guides cover each control where it lives; this page is the map a reviewer reads first: the boundaries, what enforces each one, and how they compose into postures. The architecture starts from a structural advantage: everything, models, documents, memory, indexes, runs on hardware you control, so the problem is not "what does the vendor see" (nothing; Where Data Lives is the inventory) but the classic one: who can reach the server, what may they do, and what does it record. The same boundaries walked adversary by adversary are The Threat Model; their mapping onto the vocabulary a procurement review speaks is Passing the Security Review.

1The boundaries, mapped#

2Identity: keys, owners, and the local convenience#

Three facts define the identity design:

• Keys are hashed at rest. A key's token is stored as a SHA-256 hash; the plaintext exists once, at creation, and the panel thereafter shows only a redacted prefix. A leaked settings backup does not leak usable credentials.
• Settings secrets are encrypted at rest. Certificate passwords, database connection strings, and cloud keys persist in appsettings.json as enc:v1: values that only the installation's keyring (in the state directory, owner-only permissions) can open, so the settings file on its own reveals no credential. The keyring travels with the state directory: a whole-directory backup restores intact, while a settings file copied alone reads those values as unset and the log names what to re-enter. Config exports mask them as **** either way. Operator account passwords go further and are never stored, only PBKDF2 hashes.
• The owner is the isolation boundary, and it is deliberate. Every key carries an owner id; jobs, in-flight ceilings, and per-key data scoping key off the OWNER, not the token. Regenerating a compromised token preserves the owner, so rotation never orphans data; several keys may deliberately share one owner when two services must see the same resources. Least privilege on Search is explicit: new keys mint with access to NO clusters, and grants are added per key.
• Anonymous-local is a posture, not a hole. A fresh install accepts keyless calls from the same machine so the first ten minutes need no ceremony; the moment the server is exposed, Going Live walks turning identity on. The admin surface additionally supports an explicit open-on-loopback development mode, which is exactly as safe as the machine it runs on.

3Capability: policy lives in policies, never in prompts#

The design rule across the agentic surface: an agent definition is a convenience bundle and holds NO permissions. What a request may actually do is decided by operator policy, each with its own guide:

• Tools are individually enabled, each labeled with its declared side effect, with per-tool options; a disabled tool is refused by the runtime, and the refusal is narrated to the model rather than silently skipped.
• Egress is a mode: web-reaching tools run wide open, against an allowlist, or not at all; nothing else initiates outbound traffic (the exhaustive list).
• Skills load only from the operator's directory, optionally narrowed by an allowlist; sources install declaratively but never overwrite local state.
• File access for tools opens only through configured roots; nothing exposes arbitrary paths or process execution at all.
• Web areas (docs, guides, playground, training, MCP page) are each independently: off, public, or admin-gated, and the MCP protocol endpoint itself sits under the same key policy as the API.

The composition is defense in depth with one direction: every layer can only NARROW. A request can name any tool it likes; policy decides what runs.

4The admin plane#

Operating the server is a separate identity domain from calling it: an admin session (password, or OIDC SSO with domain, group, and email allowlists, with password login optionally disabled outright) gates the console and every configuration write. The plane hardens independently of the data plane: HTTPS can be required for admin routes specifically, the IP allowlist narrows admin reachability, and admin actions like job cancellation override key scoping deliberately and only there. Data-plane keys can never reconfigure the server: a leaked API key is a data-access incident, not a takeover.

5Audit: bounded by design#

The request trail records every exchange with timing, outcome, and attributed failure cause; body capture is leading-bytes-bounded and can be disabled, so the audit trail cannot itself become an unbounded copy of your documents. Logs have a write floor rather than a display filter. Memory is inspectable and deletable per fact. The audit surface answers "what happened" without quietly becoming a second data store to protect.

6Three postures#

• Workstation (the default): loopback, keyless local calls, everything else off or local. Safe because unreachable.
• Team server: keys required, areas set deliberately (playground and training admin-gated or off), egress on allowlist, search grants per key, HTTPS on: Going Live is the checklist.
• Exposed service: the team posture plus TLS everywhere, admin IP allowlist, named operator accounts with roles and second factors, SSO for operators, and the audit trail feeding your monitoring through telemetry export. How the owner boundary and the grants compose into serving several teams from one server is One Server, Many Teams.

7Stated plainly#

• The boundaries are separable: network, identity, capability, isolation, administration, audit, and each can be reviewed and hardened on its own.
• Credentials are hashed, owners not tokens scope data, new keys start with no search access, and policy, never a prompt, decides what tools run.
• The default posture is safe by unreachability; the guides named above turn each dial deliberately when the audience grows.