Trust Center
Security, privacy and compliance documentation for Compass Platform, for customers, partners and reviewers.
1. Architecture and hosting
Compass Platform is deployed on the customer’s own infrastructure as a Docker Compose stack: a TLS edge (Traefik), the web application, the API, a job queue, GPU compute workers, an image processor, PostgreSQL 16, MinIO object storage and Prometheus/Grafana monitoring. Slide images remain on the customer’s storage mount; compute workers read them read-only. The only external services are AWS Cognito for authentication (eu-west-2), Let’s Encrypt for certificates and a model registry for weights.
2. Identity and access
Authentication by AWS Cognito with JWT validation on every request; invitations issue temporary passwords that must be changed at first sign-in; Google sign-in optional. Authorisation is group-based with read, write and owner levels and optional expiry; deleting requires owner; sharing, membership and revocation are administrator-only, implementing segregation of duties. Per-user algorithm entitlements. Accounts can be disabled instantly and optionally auto-disabled after inactivity.
3. Audit and monitoring
27 audit event types are recorded with user, IP address, user agent and timestamp, including slide access and deletion, analyses, every export and every permission, group and account change. Prometheus scrapes every service; Grafana dashboards are available to administrators with a 15-minute session. Health checks cover every container.
4. Data protection
Private object storage by default; only the public demo slides are readable anonymously. Storage paths are validated against the mount root; filenames are sanitised; document uploads are checked by content type and capped at 10 MB. Public endpoints are rate-limited. Uploaded slides must be anonymised by the licensee.
5. Transport security
TLS on all connections with HTTP redirected to HTTPS; HSTS for one year with preload; nosniff, referrer and permissions policies; Content Security Policy; CORS limited to the site domain; 30-minute proxy timeouts.
6. Secure development
Every change follows issue → branch → pull request → CI → review → merge → tag. Branch protection forbids direct pushes; code owners cover authentication, RBAC, inference, schema and CI. Every release tag produces test reports, coverage, a CycloneDX SBOM, a SOUP list and a CVE scan per component. Practices are mapped to IEC 62304 (5.1.1, 5.1.11, 5.5.3, 5.5.5, 8.1.2), ISO 13485 (4.2.4, 4.2.5, 7.3.2, 7.3.5–7.3.7) and ISO 27001:2022 (A.5.15–18, A.8.2, A.8.3, A.8.8, A.8.27, A.8.32, A.5.37).
7. Vulnerability disclosure
Report to security@octopath.ai; do not open public issues. Acknowledgement within 2 business days and assessment within 5. Fix targets: Critical 48 hours; High 7 days; Medium 30 days; Low next release.
8. Certifications and status
ISO 13485: [status]. ISO 27001: [status]. NHS DSPT: [status]. Regulatory status by product: see Validation & regulatory. Backup and disaster-recovery arrangements: [to be documented].
9. Request documentation
Architecture notes, the current SBOMs, penetration test summaries and data processing terms are available to customers and partners under NDA: contact security@octopath.ai.
Contact
Questions about this document: info@octopath.ai. Data protection: privacy@octopath.ai. Security: security@octopath.ai.