Skip to main content
Status: Planned and unavailable. Do not paste a provider credential into the developer portal or send one to /v1/execute; no public BYO enrollment, storage, routing, rotation, revocation, usage, or fee contract is active.
The live personal partner preview uses Praxa’s bundled inference supply. The public request cannot choose a provider, model, credential, or funding mode.

​
Intended use cases

A future BYO option may help customers that have provider committed spend, provider-specific procurement terms, a DPA, regional requirements, or a fine-tuned deployment under their own account. Those motivations do not make the capability available today.

​
Required security properties

Before BYO can activate, its implementation must prove:
  • application-layer envelope encryption at rest;
  • runtime-only decryption and strict tenant binding;
  • no plaintext in logs, errors, gateway state, analytics, or API responses;
  • one-time write-only enrollment and safe metadata-only readback;
  • rotation that activates the replacement before revoking the predecessor;
  • immediate authoritative revocation and bounded cache propagation;
  • provider/model failover constrained to the tenant’s funded lanes;
  • billing and usage separation between bundled and tenant-funded calls;
  • cross-tenant negative tests and operational key-loss/recovery procedures.
Because a provider credential must later be used, it requires reversible encryption—not the SHA-256 verification hash used for praxa_sk_ API keys.

​
Intended economics

The design direction is a platform fee on routed BYO spend plus a per-run fabric fee rather than Praxa’s bundled token margin. Prior documents have discussed a 5–10% target. That is a proposal, not a quote, entitlement, or implemented meter. Provider charges would remain on the customer’s provider account.

​
Intended routing behavior

A future BYO run should never silently borrow Praxa’s or another tenant’s credential. If no authorized funded lane is healthy, execution should fail closed. Caller model/provider pinning and request-level policy are also unavailable today, so no current request example can demonstrate this behavior.

​
What to do now

Use the bundled personal partner preview, keep provider credentials in your own secret manager, and continue direct provider integration when exact provider, model, or contractual routing is required. Wait for an explicit status change and a security-reviewed enrollment flow before migrating a credential.

​
See also

Last modified on August 14, 2026