BYOK
Inbyok mode the runtime resolves each provider key in order: provider env var → .zap/credentials.json → device-auth tokens in .zap/device-auth.json → an injected vault resolver. If nothing resolves, the run fails closed with KEY_MISSING. Usage is recorded to a local ledger at .zap/ledger.jsonl. zap login --provider <id> runs the provider’s own device-auth flow (OpenAI/Codex auth and Claude Code auth are supported) and writes tokens with file mode 0600.
Managed payments (x402 v2 and MPP)
Managed mode settles through the Zap Cloud payment gate. Two protocols are accepted:- x402 v2 (
Coinbase’s payment protocol) — the client sends
PAYMENT-SIGNATURE; the gate verifies and settles via a facilitator and returnsPAYMENT-RESPONSE. The legacy v1X-PAYMENTheader is rejected unless the deployment setsZAP_X402_V1_SHIM=1. - MPP — the client sends
Authorization: Payment ...; the gate returnsPayment-Receipt.
402 with both a PAYMENT-REQUIRED challenge and WWW-Authenticate: Payment, so either protocol can respond.
Replay protection: every settlement consumes its x402 nonce or MPP challenge ID exactly once; a replayed credential gets 402 and no second receipt. The payTo address is always Zap’s treasury or a verified tenant wallet — never taken from the request. Zap holds no user funds and no custodial keys.
Client-side caps
The runtime payment client refuses to sign any payment above the session cap:zap pay login --managed authenticates your wallet and issues a scoped session key: a spend cap (default $5), a single target, and a 24-hour expiry, stored at .zap/auth.json with mode 0600. Zap never holds your primary wallet key. Auth files readable by group or world are rejected with AUTH_FILE_INSECURE.
CLI
--json.