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

# Security & Data Handling

> Transport security, webhooks, and audit trail

## 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](../getting-started/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](../guides/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:

| Field                 | Description                                                    |
| --------------------- | -------------------------------------------------------------- |
| `signature`           | Base64url-encoded Ed25519 signature over the `integrity_hash`. |
| `signature_kid`       | Key ID (e.g. `msk_v1`) identifying which key signed.           |
| `signature_algorithm` | Always `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.

```typescript theme={null}
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](mailto:security@meshqu.com). Do not disclose publicly until a fix is available.