Tenant isolation
Klyniq treats the practice boundary as a security boundary. Authenticated identity and practice membership are resolved separately, and tenant-scoped operations verify access before sensitive reads or writes.
- Do not trust a client-supplied tenant identifier as authorization by itself.
- Resolve credentials and provider mappings from trusted server-side context.
- Scope durable records to the tenant that owns the workflow.
- Fail closed when tenant context or membership cannot be established.
The model does not hold authority
Language-model output is treated as untrusted intent. Klyniq uses deterministic policy, workflow state, tool registration, server-side identities, and confirmation bindings to decide whether an action may execute.
- Unknown tools and missing policies deny by default.
- Side-effect tools may require current human confirmation.
- Confirmation is bound to the reviewed action rather than a vague prior yes.
- A model cannot choose arbitrary credentials or elevate its own role.
Evidence and replay safety
For real-world side effects, a successful model response is not enough. Klyniq records executions and events and, where supported, verifies important outcomes against the authoritative provider.
- Use idempotency keys for retryable side effects.
- Treat ambiguous provider outcomes as reconciliation work, not success.
- Preserve execution evidence for operator review.
- Escalate when verification cannot establish the final state.
Security contact
For security questions or responsible disclosure, contact security@klyniq.xyz. Do not include patient information, production credentials, or live secrets in the initial report.