How we protect your maintenance data, your team's conversations, and your OEM knowledge base.
Infrastructure
Containerized, isolated workloads. Every service runs in its own Docker container with a pinned image version, named networks, and no host networking. Containers cannot reach each other unless explicitly bridged.
NeonDB on AWS us-east-1. Tenant data lives in NeonDB (Postgres 16), hosted on AWS us-east-1. Connections require SSL (sslmode=require). NeonDB handles automated backups with point-in-time restore.
Secrets via Doppler — never in git. All credentials, API keys, and signing secrets are stored in Doppler and injected at runtime. No secrets in .env files, Dockerfiles, or source code.
Principle of least privilege. Service accounts hold only the permissions they need. The application DB role (factorylm_app) cannot bypass row-level security. neondb_owner is never used from application code.
Data protection
Encryption in transit — TLS everywhere. All external traffic is encrypted via TLS 1.2+. Internal service-to-service traffic uses named Docker networks (not exposed to the public internet).
Encryption at rest. NeonDB encrypts data at rest using AES-256. Uploaded documents (OEM manuals, images) stored in the knowledge base are encrypted at the object level.
PII is sanitized before every LLM call. The inference router automatically strips IPv4 addresses, MAC addresses, and serial numbers before sending any message to an external AI provider. This runs by default on every request — no opt-in required.
Your data is never used to train external models. MIRA uses Groq, Cerebras, and Gemini via inference-only API endpoints. We do not consent to training-data usage in any of these agreements. Your diagnostic conversations and OEM documents stay yours.
Data export on request. Active tenants can download a full export of their work orders, assets, schedules, and knowledge base at any time from the Hub dashboard.
Authentication & access control
Magic-link authentication — no passwords to steal. Sign-in is handled via time-limited, single-use email tokens. There are no passwords stored in our database. Magic links expire in 15 minutes and are consumed on first use.
Row-level security enforces tenant isolation. PostgreSQL RLS policies enforce that every query returns only the requesting tenant's data. Application code cannot disable this — the DB role used by the app has BYPASSRLS=false.
Short-lived JWTs with tenant claim. Session tokens are JWTs signed with a rotating secret (PLG_JWT_SECRET). Every token contains a tenant_id claim. Tokens expire in 7 days and are not refreshable without re-authentication.
Admin endpoints require a separate bearer token. Operational endpoints (activation health, queue management) are gated behind a separate PLG_ADMIN_TOKEN header — not the user JWT. Admin access is not derivable from a user session.
AI safety guardrails
Safety-critical queries escalate — they never get an AI answer. LOTO procedures, arc flash, confined space entry, and 18 other high-consequence keywords trigger an immediate escalation to your designated safety contact. MIRA does not produce step-by-step answers for life-safety scenarios.
No autonomous actions — MIRA asks before it acts. MIRA creates work order drafts and PM suggestions, but always requires explicit human confirmation before writing anything to your CMMS. There are no automated write-backs.
Inference cascade is deterministic and auditable. The provider cascade (Groq → Cerebras → Gemini) is configured in code, not learned. Every LLM call logs the provider used, token count, and latency to structured logs.
Source citations are required on every diagnostic answer. MIRA's RAG pipeline must cite the source chunk (OEM manual section, fault history entry) that grounds each claim. Uncited speculative answers are blocked at the guardrail layer.
Compliance & certifications
Multi-tenant RLS isolation — implemented and active. PostgreSQL row-level security is live in production. Tenants cannot read each other's data even if application-level bugs exist.
Vulnerability disclosure. Found a security issue? Email security@factorylm.com. We commit to acknowledging reports within 48 hours and disclosing fixes publicly after a 90-day window.
SOC 2 Type II audit — planned Q3 2026.Planned We are pre-revenue and pre-audit. SOC 2 Type II readiness work is in progress (access controls, logging, change management). We do not claim SOC 2 compliance today.
GDPR Data Processing Agreement available. A standard DPA is available at factorylm.com/legal/dpa for EU customers.
Annual penetration test — planned Q3 2026.Planned Third-party penetration testing is planned to coincide with the SOC 2 audit window.