TigerTrust issues two types of API keys for programmatic access: public keys for scripts, CI pipelines, and integrations, and agent keys for field agents enrolling and reporting through the control plane.

Public keys (ck_*)

User-scoped keys for calling the REST API from scripts, CI, or your own dashboards. Custom scopes, optional expiry.

Agent keys (ak_*)

Used by TigerTrust field agents to enroll and report. Fixed scopes, no expiry by default.
Api Keys

​
Key format

ck_prod_ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcd    # public, production
ck_stag_...                                          # public, staging
ak_prod_...                                          # agent, production
The prefix after the key type indicates the environment (prod, stag, dev). This makes leaked keys immediately identifiable in logs.

​
Create a public key

Go to Integrations → API Keys → New key. Set a name, environment, scopes, and optional expiry date. The plaintext key is only shown once — save it to your secrets manager immediately. Prefer to create keys programmatically? See API Reference → Authentication.

​
Available scopes

  • certificates:read — list and get
  • certificates:issue — create new certificates
  • certificates:renew — trigger renewal
  • certificates:revoke — revoke and publish to CRL
  • certificates:deploy — deploy to endpoints
  • cas:read
  • cas:manage — create CAs, rotate keys, publish CRL
  • discovery:read — read scan history and results
  • discovery:trigger — start on-demand scans
  • discovery:configure — add scan targets and cloud accounts
  • agent:connect (agent keys only)
  • agent:report (agent keys only)
  • agents:read
  • agents:manage
  • workflows:trigger
  • workflows:manage
  • policies:read
  • policies:manage
  • *:read — read every resource in the workspace
Agent keys always have the fixed scopes agent:connect, agent:report, and certificates:read. You cannot add or remove scopes from agent keys.

​
Environments

Each key is issued for a specific environment: production, staging, or development. Environment is enforced at authentication time — a production key cannot call the staging API and vice versa. This gives blast-radius isolation without maintaining separate workspaces.

​
Using a key

Public keys are Bearer tokens — see API Reference → Authentication for the exact header format and pagination model. The workspace is inferred from the key.

​
Rate limits

Key typeLimitBurst
Public keys300 requests/minute500
Agent keys3,000 requests/minute5,000
Read-only endpoints1,000 requests/minute2,000
Limits are per key. Exceeding them returns 429 Too Many Requests with Retry-After, X-RateLimit-Remaining, and X-RateLimit-Reset headers.

​
Usage analytics

Go to Integrations > API Keys and click a key to view its usage: request count, error rate, latency percentiles (p50, p95, p99), top endpoints called, and top source IPs.

​
Rotating a key

1

Create the replacement key

Create the new key alongside the old one. Do not revoke the old key yet.
2

Update your consumers

Roll out the new key to your CI variables, secrets manager, and any other consumers.
3

Confirm zero traffic on the old key

Wait 24 hours and verify that the old key’s request count has dropped to zero in the usage dashboard.
4

Revoke the old key

Go to Integrations > API Keys, click the old key, and click Revoke. The key is invalidated immediately.
Aim to rotate production keys at least every 90 days.

Webhooks

Complement polling with push notifications.

SSO

For human users, delegate authentication to your IdP instead.

API reference

Full authentication and pagination reference.