Create a policy with caps and limits
Defines caps (soft-landing constraints) and rate limits for scopes. Policies are evaluated during reservation requests.
AUTHORIZATION: - ApiKeyAuth (X-Cycles-API-Key): tenant creates policies for their
own scopes only. tenant_id is implicit from the authenticated key
and MUST NOT appear in the request body.
- AdminKeyAuth (X-Admin-API-Key): admin operator creates a policy
on behalf of a tenant. tenant_id is REQUIRED in the request body.
Audit log records actor_type=ADMIN_ON_BEHALF_OF. Matches the
existing dual-auth pattern on read endpoints.
SCOPE PATTERNS: - "tenant:acme-corp" (exact match) - "tenant:acme-corp/" (all descendants) - "agent:" (all agents system-wide) - "*/agent:summarizer" (agent across all tenants)
PRIORITY: - Higher priority policies override lower priority - If multiple policies match, highest priority wins
EFFECTIVE DATES: - Optional time-bounded policies - Useful for temporary restrictions or trials
Authorizations
Tenant-scoped API key for runtime operations (consistent with Cycles Protocol)
Administrative API key with full system access. Also accepted as an alternative to ApiKeyAuth on an explicit per-operation allowlist — the authoritative list is the union of operations whose security: block declares AdminKeyAuth (consult per-operation security blocks rather than this prose, which has historically drifted as the dual-auth surface expanded). When using AdminKeyAuth on list or fund endpoints, a tenant scoping parameter (typically tenant or tenant_id) is required for scoping (400 if missing) — the per-operation description specifies which. Lookup-style endpoints that uniquely identify a resource by non-tenant key (e.g. GET /v1/admin/budgets/lookup, where the (scope, unit) pair is unique) do NOT require a tenant parameter. Allowlisting is per-operation (exact method:path matching — no prefix matching, no wildcards) so new endpoints do not accidentally inherit admin-accessible status.
Request Body
Responses
Policy created