Trust & Security
Security
Compliance-Ready Architecture. This page explains design principles for how MedicalBot is designed to support secure operation. It is not an audit report, BAA, or certification badge wall.
MedicalBot communicates security and governance capabilities based on documented architecture, implementation scope, and verified agreements. Certification or regulatory status is presented only when formally established.
Architecture
Security architecture principles
Where an item depends on customer deployment or future implementation, we use “designed to support” rather than asserting live control coverage.
Environment separation
Public marketing, labeled product demos, and future secured product environments are designed as distinct planes with different data classes and threat models.
Encryption expectations
Product direction is designed to support encryption in transit (TLS) and encryption at rest for secured workloads. Exact cipher suites and key management are deployment-dependent.
Secrets management
API keys and credentials are designed to live in a secrets manager or environment store — never in client bundles or public repositories. No PHI belongs in secrets stores.
MFA for staff / admin access
Secured product environments are designed to support multi-factor authentication for staff and administrative access, including organisational SSO where configured.
Role-based access control (RBAC)
Permissions are intended to map to organisational roles (operator, reviewer, admin, etc.) so users receive only the capabilities their role requires.
Least privilege
Default posture: grant the minimum access needed for a task, isolate tenants by organisation, and separate public surfaces from sensitive processing.
Logging
Security- and oversight-relevant events are designed to support structured logging and review in secured environments. Public pages do not publish log schemas or detection rules.
Backup and recovery
Secured deployments are designed to support backup, restoration testing, and recovery objectives defined with the customer. Targets are not published as SLAs on this site.
Vulnerability management
Dependency review, patch cadence, and responsibly disclosed issues are designed to support an ongoing vulnerability management practice. Pen-test summaries appear only when documents exist.
Secure development lifecycle
Changes affecting security or AI behaviour are designed to support review, testing, and controlled release — including evaluation before meaningful model or workflow changes.
What this page is not
- Not a claim that MedicalBot is HIPAA compliant, GDPR certified, SOC 2 certified, ISO certified, or FDA approved.
- Not a substitute for customer security questionnaires answered under NDA with verified evidence.
- Not a public catalog of exploitation details, network diagrams, or detection signatures.
SOC reports, penetration-test summaries, and certifications will be listed only when verified documents exist. Contact us for current information.
See MedicalBot in a guided demo
Book a product walkthrough with our team. We discuss architecture, governance patterns, and fit for your organization — without collecting PHI.
Do not submit protected health information (PHI) on this website.