Security at MeshQu

MeshQu is governance infrastructure. We were designed around evidentiary integrity before compliance certification: every recorded decision has a signed receipt, and every audit row is append-only. Where export is enabled for your deployment, a reviewer with independently trusted signing keys can check a receipt without access to MeshQu.

How MeshQu protects your data

• Cryptographically verifiable decisions. Every governed decision is hashed and signed (Ed25519). Where export is enabled for your deployment, a receipt can be checked offline with the necessary verification material and independently trusted keys. Where transparency anchoring is enabled for a deployment, receipts are additionally anchored to the public Sigstore Rekor log; anchoring failures are non-fatal and a receipt remains signed and verifiable even if the log is briefly unreachable.
• Tenant isolation in four layers. Every request carries a tenant id; the API rejects mismatches at the boundary; Postgres row-level security (RLS) enforces isolation per query; a runtime invariant check fails the request if the database session falls back to a role that bypasses RLS.
• Append-only audit chain. The audit log is database-immutable (trigger-enforced) with a per-tenant hash chain. Once written, a row cannot be altered without breaking the chain. An external auditor given access to the chain can check this for themselves; how that access is arranged is agreed per engagement.
• AI-assisted authoring is opt-in and minimised. AI-assisted authoring is opt-in per tenant. When enabled, OpenAI requests opt out of training and long-term retention via store:false. A short OpenAI abuse-monitoring window (currently 30 days, per their docs) may still apply unless the deployment is on an approved Zero Data Retention project. The OpenAI subprocessor and the live state of these controls are documented in our privacy notice.

What each level of assurance proves (opens in a new tab) · Transport, webhooks and the audit trail in detail (opens in a new tab)

Compliance roadmap

We publish progress on our compliance and trust workstreams openly. Each row below is tracked in our SOC2 readiness harness and gated by specific controls. We do not claim a certification we don’t hold.

• SOC2 Type II (In progress): Trust & Compliance Controls workstream in progress. Phase 1 covers retention policy, data inventory, incident response, disaster recovery, secret rotation, and governance controls. Phase 2 covers RBAC, MFA/SSO, DSAR, erasure, deploy pipeline, image signing, and DR drills.
• GDPR / UK GDPR (In progress): Privacy notice and subprocessor list are public. DSAR export and erasure endpoints are scheduled for Phase 2. Lawful basis is documented per data class.
• Evidentiary Integrity Guarantees (In progress): KMS-backed signing, BYOK column-level encryption, offline verifier CLI, vendor-exit data export. These are the controls a regulator-grade buyer asks for that go beyond SOC2.
• ISO 27001 (Planned): Targeted once SOC2 Type II opinion is held.

Subprocessors & data flow

The third parties that process data on behalf of MeshQu when you use the platform are listed in our privacy notice. Each entry includes purpose, processing region, and a link to the relevant Data Processing Addendum.

We will give at least 30 days’ notice before adding a new subprocessor that materially changes the data flow.

Verifying a MeshQu receipt independently

Every receipt MeshQu issues is signed with Ed25519. Where transparency anchoring is enabled for a deployment, receipts are additionally anchored to the public Sigstore Rekor transparency log. Where export is enabled for your deployment, a receipt can be checked with independently trusted keys, without making any API call to MeshQu:

• The signed envelope contains a key id (kid) referring to the Ed25519 signing key that issued it.
• The receipt’s integrity hash binds the policy snapshot and evidence manifest digests, so policy logic cannot be retroactively rewritten.
• Where transparency anchoring is enabled for a deployment, a receipt’s Rekor entry can be checked offline against the log’s pinned public key (its Signed Entry Timestamp), without contacting MeshQu or the log. Checking that the entry exists in the public log is an online lookup, not an inclusion proof; online inclusion-proof verification against a co-signed witness is planned. Anchoring is not on by default in production.

An offline verifier CLI is on the public roadmap so that customers can verify proofs even after a vendor exit. Talk to us if you need an early version for a procurement review.

Reporting a vulnerability

Email security@meshqu.com with details, including a description of the issue and its potential impact, reproduction steps where applicable, and the affected version or commit.

Disclosure policy

• Scope. The MeshQu marketing site, the hosted receipt verifier, the MeshQu API and tenant Console, and the MeshQu verifier and client packages once they are published.
• Response. We acknowledge reports within 2 business days, provide an initial assessment within 5 business days, and aim to resolve confirmed issues within 90 days of acknowledgement.
• Safe harbour. We will not pursue legal action or contact law enforcement against researchers who make a good-faith effort to avoid privacy violations, data destruction and service disruption, who interact only with their own accounts or test accounts they own, and who give us a reasonable opportunity to resolve the issue before public disclosure.

Questions

For procurement, security questionnaires, or DPA requests, email security@meshqu.com.