CrestBid AI — Security Whitepaper

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).

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).

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).

• 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.

Licence keys are generated by Mobiprise and delivered by email. Each key is a signed licence key, verified offline against a bundled public key — the platform never contacts us to check it, so it works on an air-gapped machine, and the public key can verify a key but not mint one. Entitlement is enforced locally, inside the application: when a licence or evaluation key lapses, value-delivering operations (generation, chat, extraction, export) stop, while customer data remains fully viewable — the application fails closed for spend, open for access to your own data.

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.

• 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.

• Container images are published from a controlled build process, and the running application reports exactly what it's running at /api/version — operators can verify with one request.
• Dependency posture: dependencies are audited automatically as part of every release, and any findings are tracked and addressed.
• 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.

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

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.

Report vulnerabilities to sales@mobiprise.com. We commit to acknowledgment quickly and coordinated disclosure.

Statements about network exposure, gating, headers, and licensing are verifiable in the compose file and application source shipped with every installation.