The Threat Model

The Security Model maps the trust boundaries; this page walks the same ground from the other side, adversary by adversary, for the security engineer doing the design review. Each section states the adversary's capability, what the product contains, and what remains the operator's job. The last section lists what the server explicitly does not defend against, because a threat model that claims to cover everything covers nothing.

1The network attacker#

Capability. A host on the same network probes for open ports, unauthenticated endpoints, and plaintext traffic.

Contained by. The default posture is unreachability: the server binds loopback only until the operator deliberately changes the Network setting. In the Network posture every API call requires a key: there is no configuration in which the server is both reachable from the network and callable without a credential (Going Live). The compatibility dialects widen no gap: the OpenAI, Anthropic, and Ollama surfaces all sit behind the same key gate, Bearer authentication on every dialect (API Compatibility). TLS is provisioned out of the box (self-signed, OS-trusted where possible) with ACME for public names; the admin console can be restricted to HTTPS-only and narrowed by an IP allowlist. Each human-facing web surface (the API reference, the guides, the Playground, the training console, the MCP guide) is individually served or not, public or admin-gated.

Yours. Firewalling, network segmentation, and the correctness of any reverse proxy in front (Behind a Reverse Proxy). The server cannot know that a proxy forwards traffic it should not.

2The credential holder#

Capability. An attacker holds a valid API key: leaked from a client's configuration, a CI log, or an over-broad grant.

Contained by. The blast radius of a key is the sum of its grants, and every control narrows (Keys and Authentication). A new key reaches no Search clusters and no tenants until granted; tool grants can only narrow the server's tool policy, never widen it; a read-only key is confined to safe HTTP methods and cannot trigger inference or change state. Keys are stored as SHA-256 hashes, so a stolen settings backup yields no usable credentials. Rotation is non-destructive: Regenerate kills the old token immediately while the key's identity, and therefore its data, persists. Revoked, expired, and unknown keys fail closed everywhere, including mid-flight. Above all, the data plane cannot reach the control plane: a key can never reconfigure the server, so a leaked key is a data-access incident, not a takeover.

Yours. One key per service, grants at minimum, expiries on anything temporary, and rotation when a client is decommissioned. The product enforces least privilege at the mint; keeping it least-privileged over time is operations.

3Prompt injection through documents and retrieved content#

Capability. An attacker plants instructions inside content the model will read: an uploaded document, a page a web tool fetches, or a passage retrieval surfaces from the index. The model may then act on those instructions as if they came from the user.

Contained by. Treat prompt injection as unsolved in principle and contained in practice: no model reliably distinguishes instructions from data, so the design assumes the model can be steered and bounds what steering can reach. The layers:

• Policy lives in policies, never in prompts. An agent definition carries no permissions; what a request may do is decided by the operator's tool policy and the key's grants (Tools and Egress). Injected text can change what the model asks for, not what the server permits.
• The egress gate bounds where a steered model can send or fetch. Web-reaching tools run wide open, against an allowlist, or not at all, and in every mode the gate refuses hosts that resolve to private, loopback, or link-local addresses; the only names that may resolve internally are intranet exceptions the operator lists explicitly, so injected content cannot silently turn the model into a probe of your own network.
• Grounded answering constrains the output side. Grounded Answers cite the spans an answer rests on and refuse when the corpus does not support one, which keeps a poisoned passage visible in the citation trail rather than silently absorbed.
• The tool loop is bounded and audited. max_tool_calls caps what one steered turn can spend, tool activity is summarized per exchange (Agent Operations), and the request trail records the exchange (Observability), so "what did the injected content make it do" is a lookup. On MCP, the session guidance states the rule to the consuming model directly: text extracted from documents is untrusted content, to be reported and never obeyed.

Yours. Keys that process untrusted documents should carry the narrowest tool grants you can tolerate, egress should be on an allowlist wherever the input is hostile (public uploads, inbound mail), and the request trail should be reviewed as the detection surface it is.

4Tool abuse by a steered model#

Capability. Given tools, a steered model attempts actions its operator did not intend: fetching internal hosts, reading files, flooding calls.

Contained by. Server-executed tools are opt-in per tool, each labeled with its declared side effect; a disabled tool is refused by the runtime and the refusal is narrated to the model. File access opens only through the operator's configured ingest roots; nothing exposing arbitrary paths or process execution is served at all. Per-key grants narrow the policy further. The MCP endpoint adds an audience without adding an exception: off by default, serving the recommended set rather than the whole catalog, with a risk ceiling that excludes whole classes of tool, per-call cost ceilings, session caps, and the same keys and egress gate as every other surface.

Yours. MCP approval hints are advisory by protocol design: the server can ask, only the client can prompt its user. Connectors you attach as tool providers receive whatever arguments the exchange produces; attach only endpoints you trust with that (Tools and Function Calling).

5Malicious uploaded documents#

Capability. A crafted file targets the parser itself: malformed PDF structures, decompression bombs, or exploit payloads aimed at document engines.

Contained by. Documents are parsed locally, in the server's own process, by its embedded engines; nothing is forwarded to a third party and uploaded bytes are never executed. Uploads are swept on a short default retention, and the audit trail captures leading bytes of textual content only, so a hostile file is never mirrored into a second store (Where Data Lives). On the MCP surface, per-call ceilings bound what one parse may cost (The MCP Server).

Yours. The server does not claim a per-document sandbox, so treat the parser as code-adjacent attack surface and contain it at the OS level: run the service under a dedicated least-privileged account, containerize where the input is hostile (Running in Containers), and keep the server current.

6Cross-tenant reach#

Capability. A legitimate caller in a shared deployment tries to read another team's documents, indexes, or job results.

Contained by. The owner on a key is the isolation boundary: uploads, jobs, MCP sessions, and artifacts are scoped to the owner, and two keys never share reach by accident. Search access is grant-based with no ownership shortcut: a key reaches a tenant only through an explicit grant, knowing a tenant's GUID confers nothing, a denied cluster answers exactly like one that does not exist, and on PostgreSQL the grant check is enforced a second time by row-level security in the database itself (Access Model). Discovery endpoints list only the caller's own reach, never the server's topology.

Yours. Boundary placement. The tenant is the smallest unit you will ever grant or revoke independently; metadata filters are caller-supplied conveniences and never a security boundary. Serving several teams from one server is One Server, Many Teams.

7Admin-plane compromise#

Capability. An attacker seeks the console: the identity that mints keys, changes policy, and reads everything.

Contained by. The admin plane is a separate identity domain from the API, hardened independently: password, SSO with domain, group, and email allowlists (password login can then be disabled outright), and two-factor authentication, all in the Security section. HTTPS can be required for admin routes specifically, and the IP allowlist narrows who may even reach the login. No API key, however scoped, can cross into this plane.

Yours. Set the password before the server leaves loopback (it is on Going Live's pre-exposure checklist), turn on 2FA or SSO for anything shared, and treat the admin credential with the care the plane's reach implies.

8Model supply chain#

Capability. A tampered or unvetted model file arrives on the server: weights that misbehave, or a file crafted against the inference engine's loader.

Contained by. Model weights load as data into the inference engine; they are not executables. The built-in catalog is the curated source, fetched from its hosting repository over one of the five explicit egress channels. Imports are probed first and refused when they cannot serve, and the operator can disable custom models entirely, pinning the server to the catalog (Choosing and Operating Models). Air-gapped deployments pre-place files instead of downloading (Air-Gapped Deployment).

Yours. The import probe is a serving check, not a security scan. A model's behavior is part of your trust surface: source custom weights and fine-tunes as you would source dependencies, from parties you trust, over channels you control.

9What this server does not defend against#

The honest residue, stated so a reviewer can quote it:

• A compromised operating system. The server trusts its host. Root or Administrator on the box reads the state directory, the settings, and everything in flight; no application-level control survives that.
• Physical access. Disks are not encrypted by the application; use OS or volume encryption where the threat model includes theft.
• A malicious administrator. The admin plane is total by design, and the audit trail is bounded and admin-controlled. Insider risk on the operator is organizational, not technical.
• Credential handling on the caller's side. The token exists in plaintext wherever the client stores it; the server's hashing protects its own store, not yours.
• Model behavior itself. No local model is guaranteed to resist injection or to answer faithfully; the layers above bound consequences, not cognition.
• Data after permitted egress. Once a tool, connector, or telemetry export the operator enabled sends bytes out, their fate belongs to the destination.

Mapping these boundaries onto procurement vocabulary is Passing the Security Review.

10Stated plainly#

• Every adversary meets the same pattern: default-closed posture, explicit narrow grants, and an audit trail; nothing a caller carries can widen what policy allows.
• Prompt injection is assumed to succeed at the model and contained at the server: policy, the egress gate, bounded tool loops, and grounding limit what a steered model can reach.
• Document parsing is local and in-process; containment beyond that is OS-level and the operator's to provide.
• The server defends its own boundaries, not a compromised host, a stolen disk, or its own administrator.