Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.meshqu.com/llms.txt

Use this file to discover all available pages before exploring further.

​
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 tenant-scoped via the X-MeshQu-Tenant-Id header. Tenant boundaries are enforced on every request. If the API key and tenant do not match, the request is rejected.

​
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 that binds the verdict to the exact policy snapshot. The integrity_hash (SHA-256 over canonical JSON) covers the context, decision, and snapshot. When signing is enabled, MeshQu signs the integrity hash with Ed25519. Auditors verify receipts with the public key alone — no shared secret exchange is required. Key IDs (msk_v1 format) identify which key signed a receipt, and key rotation is supported.

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

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