How we protect your maintenance data, your team's conversations, and your OEM knowledge base.
What matters, in plain terms
Your plant data is isolated by tenant. Row-level security means one customer can never read another's data — enforced in the database, not just the app.
Your manuals never train external models. We use Groq, Cerebras, and Gemini inference-only; your documents and conversations stay yours.
Safety-critical questions are flagged. LOTO, arc flash, and confined-space questions come with a safety warning. For that work, follow your site procedure. Don't use any AI tool for it.
Answers from your manuals show the page. When an answer comes from your manual, MIRA shows the manual and the page, so a technician can check it before touching the machine.
We're honest about the roadmap. We are not SOC 2 certified yet; readiness work is underway. The technical detail below says exactly where we stand.
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
Google, magic-link, or password sign-in. Sign in with Google, a time-limited single-use email link, or a password. Passwords are stored only as salted bcrypt hashes, never in plain text. 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 questions are flagged — MIRA is not a safety system. Questions that mention lockout/tagout, arc flash, confined space entry, or other high-consequence hazards are answered with a safety warning. For that work, follow your site's procedures and qualified people. Don't use MIRA, or any AI tool, for it.
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.
Answers from your documents show their source. When an answer comes from an OEM manual or a document you uploaded, MIRA shows the document and page it used. Not every answer has a document behind it, so check the citation before you act.
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.