What BYOK means here

Bring-your-own-key (BYOK) on ToRun is not just a textbox where you paste an API key. It is a vault with three responsibilities: store credentials encrypted, resolve them on every call without exposing them to application code, and emit an audit entry every time a credential is read.

Encryption at rest

BYOK credentials live in the AiProviderCredential entity, encrypted with envelope encryption: the data key is sealed by a tenant-scoped KMS-style key that lives outside the application boundary. The application never sees the raw provider key in memory — the runtime decrypts inside a HSM-style sidecar service and injects it directly into the outbound HTTP client.

Scoped credentials

A single credential can be scoped to: one provider, one model family, one capability, one mode, one team within an organization, or even one workflow. The scope is enforced at resolution time, so an attempt to call "Anthropic via a credential bound only to OpenAI" returns an error before the request is sent.

Three billing tiers

KatmanA: full platform features at full cost. KatmanB: discounted platform fees in exchange for routing through your own provider account. KatmanC: enterprise tier with negotiated rates, audit retention, and SOC2-aligned controls.

Audit trail you can inspect

Every credential resolution writes a CredentialResolutionAudit row: who, when, what scope, which call ID. You can replay the full lifecycle of any credential and demonstrate which calls it served, without ever exposing the key value.

What this is not

This is not a replacement for your own secret manager. If you operate on a regulated workload, mirror your credentials into your own KMS too. ToRun's vault is a runtime injection layer, not a primary secret store.