Status: The personal partner-preview gateway, API-key authority, strict minimal task boundary, tenant-bound run/usage reads, and server-owned billing admission are live. Unified policy, BYO credentials, organization execution, and mature receipts are unavailable.
Trust boundaries
Client. Holds a credential and requests an operation. It cannot assign its own identity, tenant, roles, billing account, tools, model, policy authority, or approval. Gateway. Validates protocol/method/path, bearer key admission, endpoint scope, request/body limits, and CORS, then strips external authorization state before private service-binding dispatch. Gateway admission is necessary but not final point-of-effect authority. Runtime and database authority. Re-resolve the key, tenant, actor, resource ownership, scopes, funding, current state, and mutation invariants. Privileged provider, connector, webhook-signing, and database credentials remain inside this boundary.Current client constraints
- no request
userId, tenant assignment, or organization execution; task.agentId,context,tools,policy, anddeliveryare rejected;- exact four-value key scope enum;
- foreign/unknown resources are not projected;
- cancellation is cooperative and cannot assert rollback;
- usage is customer-safe evidence, not authority to change billing.
API-key handling
Praxa creates 32 random bytes and returns thepraxa_sk_ secret once. It stores
a SHA-256 hash plus safe lifecycle metadata, not recoverable plaintext. Create
and rotate responses are no-store; list responses never expose the hash or
tenant id. Rotation and revocation recheck authoritative storage even while an
edge projection propagates.
Existing custom-agent deployment keys remain a separate credential family.