CrestBid AI — Security Whitepaper

1. Executive summary

CrestBid AI is a bid-intelligence platform built on a single architectural commitment: your bid data never leaves your machine. Documents, extracted questions, generated drafts, knowledge bases, embeddings, and chat history are processed and stored entirely on infrastructure you control. There is no CrestBid cloud that receives customer content — by design, not by configuration.

This paper describes the security architecture, data flows, threat model, and operational controls, and states plainly what the platform does not yet do. It is written for security reviewers evaluating CrestBid AI for regulated environments (defense and government contractors, healthcare, financial services).

2. Deployment architecture

CrestBid AI ships as a set of containers orchestrated by Docker Compose on a single host (Windows via WSL2, or Linux):

• •Single ingress. Only the application port is published. The database, model servers, queue, and license server are reachable exclusively on the private compose network; they cannot be addressed from the LAN or the host.
• •No inbound cloud dependency at runtime. After installation, the platform operates with zero external network calls in its default configuration. It runs air-gapped.
• •AI models are local files. GGUF model weights live on the host disk and are executed by llama.cpp inside the orchestrator container. Prompts and documents are never transmitted to a third-party model API unless an operator explicitly opts in (Section 6).

3. Data at rest

Full-disk or volume-level encryption is inherited from the host platform (BitLocker, LUKS, or equivalent) and is recommended in the deployment checklist. CrestBid AI does not currently implement application-level encryption of database contents (see Section 9).

4. Data in transit

• •All inter-service traffic remains on the private, single-host compose network and never crosses a physical network interface.
• •The browser ↔ application connection is localhost HTTP by default. For multi-user LAN deployments the operations guide documents fronting the app with a TLS-terminating reverse proxy; strict transport headers are already emitted by the application.
• •Response headers enforce a defense-in-depth baseline on every request: Content-Security-Policy (self-scoped sources, frame-ancestors none, object-src none), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict Referrer-Policy, and a restrictive Permissions-Policy. CORS is disabled by default (same-origin only) and must be explicitly enabled by an operator.

5. Licensing — verified offline, never phoning home

License keys are signed tokens verified offline with a bundled Ed25519 public key. The platform never contacts a licensing server at runtime to validate; the public key can verify but not mint keys. Entitlement is enforced server-side at the API layer: when a license or trial lapses, value-delivering operations (generation, chat, extraction, export) return HTTP 402 and stop, while customer data remains fully viewable — the application fails closed for spend, open for access to your own data.

6. AI processing and the cloud opt-in

Default: all inference (drafting, chat, question extraction, embeddings) runs on local models. Two explicit, operator-controlled exceptions exist:

• •A cloud LLM provider can be configured with a customer-supplied API endpoint and customer-supplied key for generation and chat.
• •The orchestrator can be pointed at a remote OpenAI-compatible inference host (for example, a GPU server elsewhere on your own network).

Both are off by default, require editing the server-side configuration, and are documented with an explicit warning that enabling them transmits prompt content to the configured endpoint. There is no silent fallback to cloud.

7. Identity, tenancy, and audit

• •The shipped appliance runs single-tenant per organization with role-based access control (owner / admin / member) enforced in the API layer; membership checks gate every organization- and project-scoped route.
• •Seat counts are license-enforced.
• •An audit table records administrative and content-lifecycle events; generation results retain source citations, giving reviewable provenance for AI-drafted content.
• •Optional hosted authentication is available for multi-user web deployments; the local appliance intentionally keeps authentication optional so evaluation requires no identity infrastructure.

8. Supply chain and update integrity

• •Container images are published from tagged CI builds; every image bakes in its git commit and version, and the running application reports them at /api/version — operators can verify exactly what code is running with one request.
• •Dependency posture: automated audit in the release process; at the time of writing the production dependency tree has zero high or critical advisories (moderate/low items are tracked in the release notes).
• •The installer verifies GPU passthrough, generates per-install secrets, and never downloads code outside the pinned registry images and (optionally) model weights — both over TLS. Air-gapped installs can pre-stage images and model files entirely offline.
• •Uploaded custom models are validated by magic bytes (GGUF), stored under a dedicated directory with path-traversal-safe naming, and cannot overwrite models assigned to active roles.

9. Honest limitations and hardening roadmap

We believe security reviews go faster when the vendor states the gaps:

10. Compliance posture

CrestBid AI's local-first architecture means customer content is governed by your existing controls — the platform introduces no new data processor, no cross-border transfer, and no third-party model provider by default. This materially simplifies HIPAA, GDPR, and DFARS/ITAR analyses: the data never leaves the boundary you already certify. CrestBid AI itself is not separately certified against these frameworks; it is designed to inherit your environment's compliance rather than expand its scope.

11. Security contact

Report vulnerabilities to [email protected]. We commit to acknowledgment within 2 business days and coordinated disclosure.

This document is generated from the audited 1.1.10 codebase. Statements about network exposure, gating, headers, and licensing are verifiable in the compose file and application source shipped with every installation.