Appearance
Authentication and keys
Service credentials belong on your server. A valid service key authorizes only its tenant, environment, actor, and explicit scopes. It is not proof that an end user is allowed to access a resource.
Issue and protect a key
Human console sessions are the only key-issuance route in the pilot. Public API management credentials can list and revoke permitted keys; they cannot create or rotate keys. MFA, current role, environment readiness, and the scope ceiling are checked together.
Fresh issuance returns the secret once with Cache-Control: no-store. Mystro stores a hash and metadata. An idempotency replay returns metadata with secret_available: false, never the secret again. If the original response is lost, revoke that orphaned key and issue a fresh one.
Default expiry is 90 days; maximum is 365 days. Scopes are immutable. Rotation preserves the service actor and workspace: it creates a new key with the same tenant/environment/scopes. Keep the old key until you have safely stored and tested the new one, then retire it immediately or schedule retirement after 24 hours. A family has at most two active versions. Losing the new response must not retire the old key.
Revocation takes effect at the next request/tool check, invalidates derived actor leases, and closes streams within 15 seconds. External operations already accepted by your endpoint may finish; retain and reconcile their receipts.
Scope templates
| Template | Intended use | Explicit exclusions |
|---|---|---|
| Sandbox server integration | Own workspace, conversations, runs, files, own usage | Tenant administration, delegation, connection administration, key issuance |
| Application users | User/workspace provisioning plus delegated user execution | Human approval delegation unless separately granted |
| Approval integration | Server verifies a human decision and submits it for that user | Autonomous service-actor approval |
| Advanced management | Explicit configuration, list, and revoke scopes | Public key minting |
identity:delegate is trusted backend impersonation authority. Keep it separate from ordinary run credentials. approval:delegate is a separate authority and requires a verified human action in your app. Owners select these privileges explicitly with fresh MFA.
End-user authorization
Your server authenticates the user, resolves its environment-specific user/workspace, then requests an actor session with identity:delegate. An opaque short-lived token lasts five minutes and is bounded to actor, workspace, scopes, and authorization epoch. Mystro rechecks current ownership on every resource/tool request and during streams. Service actors cannot use user-owned connections or approve writes.
Send Authorization: Bearer $MYSTRO_API_KEY for server calls or the actor token for bounded user calls. Never store either in the docs explorer. The console uses opaque HttpOnly cookies, CSRF protection, and managed login; console sessions and API keys are different credentials.
Request tokens and admitted work
The five-minute actor token authorizes new requests. Admission separately grants a run up to 15 minutes of durable execution authorization, including queue and approval waits. The run retains the original opaque lease ID, user epoch, workspace and scopes; it does not retain a raw actor token. Expiring the request token alone does not interrupt accepted work or grant new API access.
Every new dispatch still checks the current parent key, current user status and ownership, revocation, and the current tenant/environment cell generation. Disabling the user, revoking the parent key, deleting the workspace, or exhausting the authorization deadline prevents new work. Active execution remains capped at five minutes; a human approval lasts at most ten minutes and never extends the 15-minute run authorization deadline. Obtain a fresh request token to inspect or cancel work after your old token expires.