Least privilege
Session-backed access and role permissions keep administrative, analysis, review, and client activities appropriately separated.
Operational status: BluQube is monitored continuously. To avoid exposing reconnaissance data, live infrastructure telemetry, version details, and incident diagnostics are shared only through authenticated customer and security-review channels.
Our security model
Layered safeguards for high-consequence work
Security in BluQube spans identity, tenant boundaries, evidence integrity, operational telemetry, and human review. Controls are designed to make sensitive actions attributable, reviewable, and difficult to perform accidentally.
Evidence traceability
Supported evidence workflows retain source metadata, provenance events, hashes, and audit context for professional review.
Defense in depth
Security headers, input validation, request limits, rate controls, path protections, and container isolation work together.
Human accountability
AI assists chronology, standards-of-care, deviation, and causation analysis; qualified professionals remain responsible for decisions.
Control inventory
How the safeguards work
The descriptions below separate controls implemented in the application from settings that must be verified in the environment where BluQube is deployed.
Identity, authentication, and access
Access decisions begin with an authenticated session and are narrowed by organization membership and role. Administrative actions are intentionally separated from ordinary analysis and review work.
Session managementSessions are stored with expiration and can be revoked on logout. Authenticated requests use the current session and organization context.
Role-based permissionsProgressively narrower roles separate case work, administration, billing, review, and client deliverables.
Password policyConfigurable password-strength and recovery controls support strong credentials without publishing deployment-specific thresholds.
MFA and recoveryTOTP multi-factor authentication, backup codes, enrollment, and disable flows are available; organizations decide whether MFA is optional or required.
Abuse resistanceLogin lockout and request rate limiting reduce brute-force and automated abuse. Thresholds are protected deployment settings.
Mutation safeguardsRequest parsing, payload-size limits, validation, sanitization, authorization checks, and audit events protect state-changing operations.
Data protection and privacy
BluQube is intended for controlled, authorized handling of case material. The application provides safeguards, but encryption, retention, and access obligations still depend on the selected deployment and operating procedures.
Encryption in transitThe production public endpoint is served through HTTPS/TLS. Private or self-hosted deployments must verify their own reverse proxy, certificate, and internal network paths.
Encryption at restStorage and backup encryption are supported through deployment configuration. Key ownership, rotation, KMS selection, and disk encryption remain environment responsibilities.
PHI handling boundaryBluQube does not automatically remove HIPAA identifiers. Operators must establish a lawful basis, minimize data, restrict access, and follow their retention and disclosure policies.
Storage isolationOrganization and case context are enforced through authenticated service operations; object storage, signed URLs, bucket privacy, and residency settings must be reviewed per deployment.
Secure deletion workflowDeletion and retention workflows account for manifests, audit records, and litigation holds where supported. Legal holds and final schedules require operator review.
Upload controlsEvidence uploads use content, path, and size validation. Limits are configurable deployment settings and are not published here.
Application and API security
The server applies browser and API defenses centrally so the public landing page, workbench, and service routes share a consistent baseline.
Browser security headersResponses include HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and a restrictive Content Security Policy.
Input and output handlingJSON payloads are size-limited and validated; XSS-oriented sanitization and controlled error responses reduce injection and information leakage risk.
Path and file protectionsStatic and document routes use allowlists and containment checks to prevent arbitrary file reads and directory traversal.
CORS and session boundariesCross-origin access is restricted by configured origins. Public health probes are intentionally narrow; operational and security APIs require authentication.
Webhook verificationSigned webhook verification, replay protection, and event deduplication help protect integrations from forged or repeated messages.
Runtime hardeningProduction deployments use container and host hardening appropriate to the deployment boundary. Detailed configuration is shared privately.
Auditability, evidence integrity, and AI governance
For legal-medical workflows, the record of what happened matters as much as the output. BluQube makes review context visible and treats AI output as assistive work product.
Audit trailSupported user, security, billing, export, and case operations create structured audit events with actor, action, timestamp, and resource context.
Evidence hashes and provenanceSupported evidence workflows record cryptographic hashes and provenance events so source identity and later handling can be reviewed.
Threat detectionAvailable monitoring looks for anomalous authentication, access, privilege, session, and integration activity.
Professional review boundaryAI output is assistive work product. Higher-risk analysis is intended for qualified professional review; the scope and attestation workflow are still being operationalized.
Model and prompt traceabilitySupported AI analysis records can retain model, prompt-version, source, and review-status metadata. End-to-end capture for every production output is In Development.
Export reviewReports, consolidated PDFs, and export packages are generated through controlled workflows so reviewers can validate the selected evidence and findings.
Operations, backup, and incident response
Availability and recovery depend on operating discipline as well as code. These are the areas where customers should request deployment-specific evidence.
Operational monitoringAvailability and security monitoring are reviewed internally. Sensitive diagnostics and infrastructure telemetry are not exposed on this public page.
Structured observabilityProtected logs and service metrics support investigation without exposing internal traces or implementation details to callers.
Backups and integrityBackup tooling supports encryption, rotation, checksum verification, and restore testing. Schedule, destination, keys, and drill evidence are deployment-specific.
Incident responseSecurity, privacy, availability, billing, and data-integrity events are triaged through an incident-response process with preservation, containment, notification, and lessons learned.
Vulnerability disclosureResearchers and customers can report suspected vulnerabilities privately to the security team or through the linked GitHub Security Advisory channel.
Change and dependency reviewDependency and static-analysis tooling are part of the security workflow; customers can request current release and assessment evidence.
Product and compliance workstream
Nexus Assurance
Human review is one control within a broader assurance architecture. For material output, BluQube is designed to make work product source-grounded, traceable, risk-classified, validated, reviewable, monitored, correctable, and reproducible.
How to read this section: “Implemented” describes a control with current code and evidence. “In Development” and “Planned” are roadmap states, not current production commitments. Confidence scores are routing signals, not accuracy guarantees.
| Assurance capability | Status | What exists today | What remains |
|---|---|---|---|
| Intended use and prohibited use | In Development | Public workflow boundaries and qualified-review limitations describe the intended assistive role. | A controlled intended-use register, prohibited-use rules, and evidence-backed acceptance gates across workflows are In Development. |
| AI system, vendor, and subprocessor inventory | Partial | Model registry, prompt configuration, version fields, deployment history, and provenance foundations exist. | Complete provider, hosting, subprocessor, retrieval, integration, and no-unregistered-model release controls are In Development. |
| Protected-data boundary, retention, and record separation | Partial | Security, access, tenant, encryption, HIPAA, and operational-record controls are described in this Trust Center. | AI-specific data-flow inventory, retention and legal-hold rules, work-product separation, and deployment-specific custody boundaries are In Development. |
| Source provenance and citation support | Implemented for supported workflows | Evidence hashes, provenance events, source evidence IDs, citation references, and citation validation are available for supported evidence and AI-analysis records. | Claim-level source spans, source-entailment checks, and broader workflow coverage are In Development. |
| Model, prompt, and workflow versioning | Partial | The model registry, prompt configuration registry, model versions, prompt identifiers, application version, and workflow-version fields provide traceability foundations. | Consistent end-to-end capture and reproducibility for every production output are In Development. |
| Automated validation and exception detection | Baseline implemented | Input/schema validation, citation checks, exception records, and unsupported-claim flags are available. | Clinical entailment, chronology contradiction checks, materiality rules, omission detection, and specialty validation are In Development. |
| Risk/confidence classification and routing | Control layer implemented | Risk-tier classification and Nexus Assurance routing support administrative, auto-validation, standard-review, and LNC-verification paths. | Full pipeline-wide enforcement and evidence that every material output follows the route are In Development. |
| Defined professional review | Partial | Review statuses, human-review fields, and professional-review boundaries exist in supported workflows. | Scoped attestation, correction capture, reviewer credentials, and unresolved-exception handling are In Development. |
| Production monitoring and sampling | Monitoring implemented | AI metrics, performance snapshots, alerts, health monitoring, and operational observability are available. | Systematic sampling of auto-approved output plus citation-support, omission, correction, and drift metrics are Planned. |
| Incident, pause, and rollback authority | Core controls implemented | Administrative pause/resume/maintenance controls, circuit-breaker auto-pause, status history, model deployment history, and rollback metadata exist. | Complete incident severity, re-release criteria, customer evidence, and end-to-end incident workflow are In Development. |
| Evidence Integrity Report | Customer artifact Planned | An internal generator, report schema, JSON/text export, CLI, and report-orchestration path exist. | A polished customer-facing report with clear validation, reviewer, model-usage, and exception presentation is Planned. |
| Independent challenge and release governance | Planned | Release-decision structures and governance-role concepts provide an initial foundation. | An operational independent challenge function, red-team/clinical challenge process, and evidence-backed release gate are Planned. |
Compliance references
Clear about what is—and is not—claimed
The following references describe internal mapping and implementation work. They are not independent audits, certifications, attestations, or a determination that a customer is compliant.
| Reference | Current status | What we can explain | What still requires review |
|---|---|---|---|
| HIPAA | Configuration reference | Safeguard mapping, access controls, auditability, integrity, and configuration guidance. | Covered-entity obligations, BAA terms, risk analysis, workforce, and deployment configuration. |
| SOC 2 | No attestation claimed | Internal Trust Services Criteria references and control descriptions; No independent SOC 2 certification or attestation is claimed. | Independent examination, auditor opinion, control period, and customer-specific reliance. |
| ISO 27001 | Internal mapping | Application-control mappings where relevant. | Certified ISMS scope, physical controls, organizational processes, and certification status. |
| NIST 800-53 | Internal mapping | Selected control references and implementation notes. | System security plan, authorization boundary, assessment results, and risk acceptance. |
Important: BluQube is a security-conscious application, not a substitute for a customer’s HIPAA risk analysis, legal review, security program, or contractual requirements. Ask us for a deployment-specific security packet before placing regulated data into any environment.
Shared responsibility
The application is one part of the control system
We document the boundary so teams can make informed decisions about hosted, private, or self-managed deployments.
BluQube provides
Application authentication and roles; session expiry and revocation; MFA capability; validation and request limits; browser security headers; audit and provenance records; evidence integrity metadata; webhook verification; security documentation; health probes; and incident/disclosure channels.
Your team verifies
Lawful data use and minimization; user provisioning and offboarding; MFA policy; TLS and network boundaries; storage encryption and key ownership; backups and restore drills; retention and litigation holds; endpoint security; physical access; workforce training; and required contractual terms.
Evidence room
Security documents
These documents provide implementation detail and review starting points. They are maintained as part of the product security workflow.
Security controls
Authentication, MFA, rate limits, headers, threat detection, webhooks, and PHI boundaries.
Policies and operating guidance
Policy index and the operational practices that support the application controls.
HIPAA configuration
Internal mapping and configuration guidance; no compliance certification claim.
Compliance mapping matrix
Cross-framework references for review by security, legal, and compliance teams.
Responsible disclosure
How to report suspected security vulnerabilities and what to include.
BAA template
Starting point for legal review when a business associate agreement is required.
Questions or review request?
Bring your security team into the conversation.
Request a security packet, deployment-specific answers, a BAA discussion, or a private vulnerability-reporting channel. We will tell you what is implemented, what is configurable, and what needs evidence from the operating environment.