Existing custom-agent deployment keys keep working. The Execution Fabric does not silently expand their authority.
Fabric key format
A Fabric key ispraxa_sk_ followed by 64 lowercase hexadecimal characters. Praxa generates 32 random bytes and returns the complete secret once.
Scopes
The initial key contract supports:
There is no webhook-specific scope literal. Bearer webhook reads use
runs:read; create, update, delete, and replay require both runs:read and
runs:write at the authoritative backend. The gateway pre-gates mutations with
runs:write. These routes are active for admitted personal tenants. The current
handler rejects request-level policy overrides.
Personal key console
The signed-in personal-workspace key console supports:- listing active, expired, and revoked keys;
- creating a named key with selected scopes and a 1–365 day expiry;
- showing the new secret once;
- rotating to a replacement secret;
- revoking one key without affecting other integrations;
- viewing the display suffix, creation, expiry, projection, and last-used timestamps.
https://platform.praxa.io routing fix is deployed. The portal accepts
email-link/OTP fragment callbacks, persists the resulting browser session, and
records legal acceptance durably. A production browser canary proved that the
authenticated session survives reload and retains platform.praxa.io through
the canonical aliases; read-only HTTP checks separately proved the nested key
route and the exact consumer-host deep-link return.
Storage and edge admission
Praxa stores:- the SHA-256 hash;
- the last four display characters;
- scopes and rate tier;
- expiry, projection, last-used, and revocation timestamps;
- the server-derived tenant and creator references.
no-store, and list responses never contain a hash or tenant id.
The public gateway reads a short-lived edge projection. That projection is an admission cache, not final authority. Before execution or mutation, the app and Postgres recheck the key id, hash, tenant, status, expiry, projection status, and required scope.
Rotation and revocation
Rotation uses a fail-safe order:- Prepare a replacement while the predecessor remains valid.
- Project the replacement to the edge directory.
- Mark the replacement projected.
- Revoke the predecessor in authoritative storage.
- Purge the predecessor’s edge projection.
Activation status
Personal tenant keys and the minimal durable/v1 boundary are active for
admitted partner-preview tenants. Automatic signed task webhooks and bearer
webhook management are active for the same cohort. This is not general
availability. Exact browser approval, cancellation final-status behavior, and
the broader webhook retry/dead-letter operations remain pending their own
canary gates. Cancellation final states and authenticated canonical-host/deep-
link behavior have passed their separate production canaries.
Best practices
- Keep keys in a server-side secrets manager.
- Never ship a key in browser or native app code.
- Use one key per integration.
- Choose the smallest scope set.
- Set an expiry and rotate before it.
- Revoke immediately after suspected exposure.
- Reuse one idempotency key for retries of the same logical action.