Skip to main content

​
Transport security

All production traffic must use HTTPS (TLS 1.2+). The API rejects plain HTTP in production environments.

​
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

Every API request is scoped to a tenant via the X-MeshQu-Tenant-Id header. Data from one tenant is never accessible to another. The API key must belong to the specified tenant.

​
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

Every evaluation returns a cryptographic receipt binding the verdict to the exact policy snapshot. The integrity_hash (SHA-256 over canonical JSON) covers the context, decision, and snapshot. When a signing key is configured, MeshQu signs the integrity hash with Ed25519. Auditors verify receipts using the public key alone — no shared secret exchange is needed. Key IDs (msk_v1 format) identify which key signed a receipt, and key rotation is supported via a previous-key grace period.

​
Verifying a receipt signature

Receipts include three signature fields when signing is enabled:
FieldDescription
signatureBase64url-encoded Ed25519 signature over the integrity_hash.
signature_kidKey ID (e.g. msk_v1) identifying which key signed.
signature_algorithmAlways ed25519.
To verify:
  1. Obtain the Ed25519 public key corresponding to signature_kid (provided during onboarding).
  2. Base64url-decode the signature field.
  3. Verify the signature over the hex-encoded integrity_hash using the public key.
import { verify, createPublicKey } from 'node:crypto';

function verifyReceipt(
  integrityHash: string,
  signatureBase64url: string,
  publicKeyBase64: string,
): boolean {
  const publicKey = createPublicKey({
    key: Buffer.from(publicKeyBase64, 'base64'),
    format: 'der',
    type: 'spki',
  });
  const data = Buffer.from(integrityHash, 'hex');
  const sig = Buffer.from(signatureBase64url, 'base64url');
  return verify(null, data, publicKey, sig);
}
Unsigned receipts (signature: null) remain valid — the integrity_hash can still be verified by recomputing it from the context, decision, and snapshot.

​
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 request is assigned a correlation_id returned in the response body and as the x-correlation-id header. Use this for tracing and when contacting support.

​
Trust model

  • MeshQu assumes the caller controls the decision context payload.
  • MeshQu guarantees deterministic evaluation against an immutable 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 the principle of data minimisation: send only the fields your policies need to make a decision. Avoid sending sensitive personally identifiable information unless required by your policies. Use opaque identifiers (account IDs, order IDs) rather than raw personal data where possible.

​
What MeshQu stores

  • Evaluate (/v1/decisions/evaluate): Nothing is persisted. The evaluation is stateless.
  • Record (/v1/decisions/record): The decision context, decision, violations, and metadata are stored for audit.
Retention periods are tenant-configurable and can be aligned with regulatory requirements.

​
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.