01
Bot-user auth, not credential scraping
Praxa never asks for a real human's password, OAuth refresh token, or session cookie. Each integration is installed as its own Praxa-provisioned bot user with explicit, scoped permissions. When a person leaves the company, no Praxa-side credential needs to be rotated; their bot remains, the human is gone.
02
BYOK LLM, customer-owned keys
Customers paste their Anthropic, AWS Bedrock, or GCP Vertex credentials. Keys are encrypted at rest with a workspace-scoped key (AES-256-GCM, 96-bit IV per ciphertext, AAD-bound to workspace + provider). The workspace key is itself encrypted via a tenant-scoped KMS data key. Praxa cannot decrypt keys outside a runtime invocation.
03
Tenant isolation enforced in code
Every database row, object key, and memory fact carries a workspace_id. Cross-tenant reads are blocked at the query layer with a typed WorkspaceScopeError. Enterprise customers receive a dedicated tenant where this isolation is at the infrastructure layer (separate Postgres database, separate KMS key, separate object store bucket).
04
Audit log on every action
Every Skill action records input → reasoning → considered alternatives → confidence → output. The audit log is append-only, integrity-protected, and queryable by the customer for the full retention window (90 days standard, contracted on Enterprise). You can replay any decision the Skill made.
05
Architectural enforcement, not policy
Constraints — tool allowlist, trigger source, memory namespace, sub-agent dispatch — live in the runtime middleware, not in prompts or docs. Violations throw typed errors before the LLM is ever called. Prompts can be wrong; middleware refuses.
06
Self-pausing on quality regression
Every Skill carries a published acceptance rate threshold. If the rolling rate drops below it, the Skill pauses itself and notifies the configured channel — Slack, email, or PagerDuty. A human must review and explicitly resume.