Skip to main content

​
Transport security

Use HTTPS for all production client traffic. TLS is enforced by the deployment ingress; the API application can receive HTTP on the private side of TLS termination.

​
Authentication

  • API keys are transmitted via the Authorization: Bearer header.
  • Keys are hashed before storage — MeshQu never stores plaintext keys.
  • Keys support expiry and revocation. Revoked keys are rejected immediately.
  • See Authentication for details.

​
Multi-tenant isolation

Authenticated tenant-scoped API calls require X-MeshQu-Tenant-Id, and an API key cannot access a tenant for which it is not authorised. Public receipt, chain, and form endpoints use resource identifiers instead of an API key and tenant header; treat those identifiers as access capabilities. See Authentication.

​
Scoped access

API keys carry explicit scopes that limit what operations they can perform. Follow the principle of least privilege: issue keys with only the scopes each service needs.

​
Webhook security

  • Webhook payloads are signed with HMAC-SHA256.
  • Signatures include a timestamp for replay protection (5-minute window).
  • Webhook delivery follows redirects cautiously to mitigate SSRF risks.
  • See Webhooks for verification details.

​
Decision receipt integrity

POST /v1/decisions/evaluate returns an unsigned, unrecorded preview. Its integrity_hash can be recomputed, but the response is not a Decision Receipt and does not attest that MeshQu recorded the decision. POST /v1/decisions/record persists the decision and returns a Decision Receipt. In production, receipts are signed with Ed25519. Verification checks both the recomputed integrity hash and the signature against a trusted public key. The bytes signed depend on the receipt schema version: v1 signs the hash string; v2 signs a canonical envelope. See the Receipt Reference for the exact payloads and Verifying offline for a supported workflow. An unsigned receipt produced outside production can be checked for internal hash consistency, but that check does not establish who issued it.

​
Audit trail

All significant actions (policy changes, decision recordings, key operations) are logged to an append-only audit trail. Audit events can be verified for integrity via the API.

​
Rate limiting

Two-tier rate limiting protects against abuse:
  • Pre-authentication: IP-based limits prevent brute-force attempts.
  • Post-authentication: Per-tenant limits ensure fair usage.

​
Correlation IDs

Every response carries an x-correlation-id header. Error bodies and some successful JSON responses also include correlation_id. Use the header for tracing and support requests.

​
Trust model

  • MeshQu assumes the caller controls the decision context payload.
  • MeshQu evaluates deterministically against a recorded policy snapshot.
  • MeshQu does not attest to the correctness of upstream data — only that evaluation followed policy as defined.
This separation allows independent verification without access to application code or models.

​
Data you send to MeshQu

Decision contexts (fields, metadata, evidence) are sent by your application. You control what data is included. Follow data minimisation: send only fields required for policy evaluation. Avoid sending sensitive personal data unless policy requirements make it necessary. Prefer opaque identifiers (for example, account IDs or order IDs) over raw personal data.

​
What MeshQu stores

  • Evaluate (/v1/decisions/evaluate): No decision is recorded — the decision context, decision and violations are not stored, no decision id is returned, and nothing is retrievable as a decision afterwards. Resolving the active policies may, however, create or reuse an immutable policy snapshot, identified in the response by policy_snapshot_id. The snapshot holds the frozen policy rules and their version attribution — never any part of the decision context you sent.
  • Record (/v1/decisions/record): The decision context, decision, violations, and metadata are stored for audit.
Retention depends on the data type and the deployment arrangement. A configured source-byte retention window records how long a tenant asks MeshQu to keep uploaded source bytes; the current release does not automatically delete those objects when the window elapses. Do not treat that setting as a deletion guarantee. Contact MeshQu to establish the applicable retention and erasure arrangements for decision records, audit logs, and uploaded material.

​
Data usage

MeshQu does not train models or derive secondary data from customer decision contexts.

​
Responsible disclosure

If you discover a security vulnerability, contact security@meshqu.com. Do not disclose publicly until a fix is available.