Agent-native key management
Agent-native key management
2026-05-13 · v0.5.7.0 · feature
Agent-native key management
2026-05-13 · v0.5.7.0 · feature
sk_svc_…) can now mint, rotate, and revoke API keys via POST /v1/keys. Your agent manages its own credentials with full audit lineage.v0.5.7.0 ships agent-native key management: a portal-bootstrapped service key (prefix sk_svc_…) can now mint, list, update, rotate, and revoke child API keys via POST /v1/keys. Existing sk_test_… and sk_live_… API keys keep working with no changes. There is nothing to migrate unless you opt in.
For the full concept page, see Service keys. To upgrade an existing integration, see the dedicated upgrade guide.
sk_svc_test_… / sk_svc_live_…), generated from the portal, used for /v1/keys credential management. They authenticate the same way as regular API keys (Authorization: Bearer …) but cannot place calls, send SMS, or read /v1/audit./v1/keys for child key lifecycle, plus GET /v1/audit for the compliance event stream.client.keys.{create,list,get,update,delete,rotate}./v1/audit writes an audit_read compliance event.Four envelopes from v0.5.6.0 are now also documented in the OpenAPI spec: agent_scope_error (403), agent_permission_denied (403), agent_cap_exceeded (402), and m3_fraud_block (403).
All three official clients gain a keys resource:
@saperly/sdk): client.keys.create / list / get / update / delete / rotate. Auto-generates Idempotency-Key (UUID v4) when one isn’t passed.saperly): same surface, snake_case (agent_label, line_id, monthly_cap_cents, idempotency_key). Sync and async clients.@saperly/mcp): same surface as tools. Destructive tools (keys.delete, keys.rotate) require confirm: true in the tool call.