Security

This page shows how KYA Pro protects your data at the API boundary. If you need a signed compliance document (SOC2, ISO27001) covering the whole platform, contact [email protected].

Workspace isolation

Every KYA Pro resource is scoped to a workspace. A workspace is created for you automatically when you sign up. The API filters every query by workspace, and the workspace it uses comes from your bearer token — not from anything the client sends.

kya_live_ tokens are tied to a workspace

Every kya_live_ token maps to exactly one workspace, and the server derives the workspace from the token — no request field can override it. If you send a tenant_id in the body while using a kya_live_ token, we ignore it. Cross-workspace leaks with kya_live_ tokens are structurally impossible.

Ingress tokens: two modes

• Scoped ingress tokens map one token to one workspace. Same guarantee as kya_live_ — the token IS the workspace. Prefer this mode.
• Fallback ingress token is a shared token where the caller MUST include tenant_id in the body. Use it only when a scoped token isn't practical (for example, a single collector rotating through many small workspaces). The fallback requires trust in the collector — anyone with the fallback token can write to any workspace they name.

Guidance: set up a scoped token per workspace whenever you can. Save the fallback for controlled internal collectors. Self-hosted operators set both up in the deployment runbook.

Signed evidence chain

Every state-changing action (grant, cancel, sweep, approval step, handoff proof) writes an evidence-chain row with a tamper-proof signature over its contents, so any edit after the fact is easy to detect.

Cloud customers don't manage signing keys — KYA does it for you, including rotation. Self-hosted operators can request the key-management + rotation runbook from [email protected].

Independent verification

Compliance packs are signed so anyone can check them with the public key — no login needed. A regulator can verify a pack against the public key at /.well-known/pack-verification-keys.json without any KYA credentials.

Automatic PII redaction

When an action includes a tool_input (or prompt / response / context) field, KYA scans the content for PII before it's saved. Matches are replaced with typed placeholders — the original content is never written to disk when PII is found. Your audit trail records what type of PII showed up without exposing the value.

Common financial + personal identifiers are covered by default (cards, IBAN, emails, phones, SSNs, IPs, names, locations). Contact [email protected] for custom entity types.

Rate limits

Some endpoints are rate-limited to protect the platform. Hitting a limit returns 429 with a Retry-After header (seconds to wait). Clients should honor that header.

Per-tier caps

Every account belongs to a plan tier that sets its API limits. Your current caps are always available at GET /api/v1/accounts/me under quotas and features.

Hitting a cap returns 402 with error: "account_gated" (see Errors › Account gated).

Transport security

Modern TLS required in production. HSTS enabled. Credentials over plain HTTP are rejected before the body is read.