Access Control

Rekor provides granular access control through scoped API keys, multi-user organizations, and base tags.

Scoped API Keys

Create API keys with specific permissions scoped to bases, record_types, and environments. Each key can only access what its grants allow.

# Full access key
rekor tokens create --name "admin" \
  --grants '[{"scope":{"bases":["*"]},"permissions":["*"]}]'

# Read-only key for one base
rekor tokens create --name "client-a-reader" \
  --grants '[{
    "scope": {"bases": ["client-a"], "environments": ["production"]},
    "permissions": ["read:records", "read:record_types"]
  }]'

# Agent key for CRUD in production
rekor tokens create --name "client-a-agent" \
  --grants '[{
    "scope": {"bases": ["client-a"], "environments": ["production"]},
    "permissions": ["read:records", "write:records", "read:record_types"]
  }]'

Grant Scope

Field	Description
`bases`	Required. `["*"]` for all, or specific base IDs.
`record_types`	Optional. Omit for all record_types, or specify IDs.
`environments`	Optional. `["production"]`, `["preview"]`, or omit for both.

Permissions

Each resource type has read and write permissions: read:records, write:records, read:record_types, write:record_types, read:relationships, write:relationships, read:relationship_types, write:relationship_types, read:attachments, write:attachments, read:file_types, write:file_types, read:files, write:files, read:inbound_webhooks, write:inbound_webhooks, read:triggers, write:triggers, read:bases, write:bases, read:toolsets, write:toolsets, read:actions, write:actions, read:seeds, write:seeds. Use * for all. read:audit grants read access to entity change history (and the audit log via the query endpoint); it is admin-gated, read-only, and not implied by other grants.

Privilege Ceiling

A key can only create child keys with equal or narrower scope. A scoped key cannot escalate to full access.

Key Expiration

Set an expiration date on any key. Expired keys are automatically rejected. Track usage with last_used_at to identify stale keys.

# Create a key that expires in 90 days
rekor tokens create --name "temp-agent" \
  --grants '[{"scope":{"bases":["*"]},"permissions":["read:records"]}]' \
  --expires-at 2026-06-25T00:00:00Z

Managing Keys

# List all keys (shows status, last used, expiration)
rekor tokens list

# Revoke a key
rekor tokens revoke <token_id>

The raw key value is shown only once on creation. Store it securely — it cannot be retrieved later.

Secret Vault

Store API keys, credentials, and other sensitive values at the organization level. All vault secrets are encrypted at rest and masked in API responses.

Credential-grade blobs — a client certificate, keystore, or service-account JSON (base64-encoded) — can be stored too, with an optional content_type so consumers know the format. Secrets are imported values, so rotating one installs the new credential you supply (it never auto-generates a replacement that would overwrite your real credential).

Set an optional expires_at on credentials that lapse — yearly certificates, time-bound tokens — and list the ones expiring within a window so they can be renewed before an integration breaks. Expiry is informational; secrets are never auto-disabled.

Use the vault to centralize secrets for external integrations, then reference them from base configurations.

Organizations

Users can belong to multiple organizations. Each organization has its own bases, data, and API keys. Invite team members to collaborate on shared bases.

Base Tags

Tag bases to group them by client, project, team, or any other dimension. Tags are queryable for easy filtering.

# Create with tags
rekor bases create client-a --name "Client A" \
  --tags "client:acme,region:us"

# Update tags
rekor bases tag client-a --tags "client:acme,region:us,billing"

# Filter by tag
rekor bases list --tag "client:acme"

Tags are simple strings (max 20 per base, 50 characters each). Use a key:value convention for structured grouping.