API Keys
Start with AI Platform Setup if you are connecting for the first time. In product, that flow now lives under AI Platform -> Authentication. It is the recommended release-day flow for verifying auth, confirming your organizationId, and provisioning a scoped runtime key when your org permissions allow it.
API keys are org-scoped Bearer tokens used on public routes marked api_key_or_access_token.
Public usage
Send:
Authorization: Bearer <apiKey>
Public routes then enforce:
- org match
- per-route scope
- route auth mode
Common public scope examples:
GET /api/agents/:id->agents:readGET /api/agent-runs/:id->runs:read- skill read routes ->
skills:read POST /api/skills/:id/run->runs:write- skill write routes ->
skills:write - evaluation run ->
evaluations:write
Runtime keys have separate purpose presets:
runtime_defaultgrantsagents:readandruns:readfor setup verification, stable reads, and run inspection.runtime_executiongrantsskills:read,runs:read, andruns:writefor trusted backend skill execution, generated-image jobs, and run inspection.
If you need machine authoring, create an expiring authoring_ci key from advanced key management. That preset is for stateless CI/apply workflows across agents, skills, tools, and evaluations.
API keys are route-scoped. They are not supported for user-session execution routes such as POST /api/agents/:id/run. For public skill execution from a trusted backend, use a runtime_execution key.
Management boundary
The shipped product uses /api/settings/api-keys* for setup and admin flows. Those routes require org settings permissions and are not part of the public route reference.
Use setup or your org admin flow to provision and rotate keys rather than treating key-management routes as the documented public integration surface.