Boring security choices. Documented, not implied.

Tenant isolation ​

Every multi-tenant table has an org_id column and a database-enforced policy that filters every query by it. Application code sets the active organisation as a session variable; the database refuses to return cross-tenant rows even if the application code has a bug.

This is different from the "we'll filter in the WHERE clause" approach common in early-stage RMMs, where one missed WHERE org_id = ? is a cross-tenant leak.

Secrets & encryption ​

Encrypted at rest, not plaintext columns.

• Sensitive secrets (API keys, integration tokens, agent registration secrets) are encrypted at rest with AES-256-GCM.
• The encryption key is derived (HKDF-SHA256) from a master key loaded into the application at process boot.
• The master key lives outside the application database — a database dump alone is not enough to read secrets.

Master-key rotation tooling, and an envelope scheme with independently-rotatable per-row data keys, are on the post-beta hardening backlog. We've documented it openly because we'd rather ship the rotation right than ship it now.

Authentication & authorisation ​

• Operator login with email + password + TOTP MFA. WebAuthn on the roadmap.
• Role-based access control with permission constants checked at the API layer.
• Permission backfill migrations for every new role-bearing feature — no silent 403s when you upgrade.
• Audit log of consequential actions (asset deletion, invoice void, role changes, secret reads) with operator + IP + timestamp.

Agent trust model ​

Per-agent credentials, not shared secrets. At registration each agent generates its own cryptographic identity (an NKey keypair) and is issued a unique, subject-scoped credential on the message bus — so an agent can only publish and subscribe on the subjects belonging to its own tenant. The trust database stores each agent's public identity. Agent-to-server traffic flows over a TLS-encrypted message bus.

Registration tokens authorise onboarding and can be single-use or shared for mass deployment; the per-agent identity is minted during registration, not carried in the token. Per-agent message-bus credentials are live across all customer regions.

Data residency — region-based ​

Your data lives in the region it was provisioned in.

• EU region — live. Account database, agent telemetry, ticket attachments and email gateway traffic stay on EU infrastructure. Object storage on an EU endpoint. Outbound transactional email via an EU-based provider. Inbound mail via our own gateway.
• US region — live. Same stack, US infrastructure, US object storage endpoint, US email gateway. Customers signing up with country=United States are provisioned into the US region and their data never leaves it.
• AP region — on the roadmap, sequenced next.

Each region is independent — its own application stack, its own database, its own object storage, its own email gateway. Customer data does not cross region boundaries. First-party, EU-hosted product analytics — no Google Analytics, no Segment, no Mixpanel — covers all regions.

A managed edge / DDoS layer fronts the public-facing surface but does not store application data at rest. Sub-processor names are listed in our Privacy Policy — we keep that as the single source of truth so it stays in sync with our DPA.

PCI scope ​

We never see card data. Card payments are handled by a PCI-DSS Level 1 processor via hosted checkout sessions and payment links. The card flow happens entirely on the processor's domain. OpsMerge stores customer IDs and payment status — never PANs, never CVVs.

Compliance posture ​

• GDPR & UK DPA — registered data controller, EU-region processing for EU-region tenants, DPA available on request.
• SOC 2 Type 1 — not yet. Roadmap item once revenue justifies the audit cost. We'd rather build the controls before paying for the certificate.
• Cyber Essentials Plus — Brindleford Technologies application in progress.
• ISO 27001 — long-term, post-GA.

We're being explicit because "SOC 2 ready" without an actual report is meaningless and we'd rather not pretend.

Vulnerability disclosure ​

Email [email protected]. We acknowledge within 48 hours UK business time. No bug-bounty programme yet — we'll pay for severity-significant reports informally during beta and formalise post-GA.