API keys authenticate everything that isn’t a logged-in browser session — the runtime agent/sensor, CI pipelines, IDE extensions, AI assistants (MCP), and direct API consumers. TigerGate keeps keys in separate stores, each with its own prefix and its own consumer. Pick the store that matches the client. Manage keys under Settings → Organization → API Keys. That tab has four sub-tabs: Organization Keys, IDE Keys, CI/CD Keys, and MCP / AI Assistant.

​
Key stores

StorePrefixUsed byScope
Organization Keystg_Runtime agent/sensor, MCP/AI assistants, direct API integrationsFull organization access — treat like an admin credential
IDE Keystgide_VS Code and JetBrains extensionsAuthenticate a developer’s IDE; back the device footprint and AI-spend views
CI/CD Keystgci_The TigerGate CLI in pipelinesSubmit scans, upload results, evaluate the quality gate (scan, upload, quality_gate)
The MCP / AI Assistant sub-tab is a connection guide, not a separate key store. AI assistants (Claude, Cursor, VS Code) authenticate to the MCP server with an Organization key (tg_…) — mint one on the Organization Keys tab, then paste it into a client snippet.
The self-hosted pentest (TigerStrike) worker does not use one of these keys — it authenticates per scan with a short-lived scan token issued when the scan starts.

​
Keys are region-scoped

Every key belongs to the region whose dashboard minted it. Regions are independent, so a key issued in one is rejected by every other — there is no key that works across regions. This matters because the failure is a plain 401, indistinguishable from a wrong or revoked key. If a key you just created is rejected:
1

Check which region minted it

The dashboard you created the key on is its region. app.tigergate.dev is us1; every other region uses its own host.
2

Point the client at that region

Pass --region <code> (CLI and agents), set TIGERGATE_REGION, or set tigergate.region in the IDE extension. Nothing passed means us1.
The CLI names the region it authenticated against in the error itself, so tigergate regions plus the error text is usually enough to spot the mismatch.

​
Create a key

1

Open the right sub-tab

Go to Settings → Organization → API Keys and select Organization Keys, IDE Keys, or CI/CD Keys.
2

Create the key

Click Create Key (or Create IDE Key / Create CI Key). Give it a descriptive name — e.g. acme-prod-dc1, gha-ci-prod, alice-laptop. IDE and CI/CD keys also let you pick an expiration.
3

Copy the key

The key is shown once, in a dialog. Copy it straight into your secret store before closing it — it is not stored and cannot be shown again.
Creating a key in any store requires an owner or admin role.

​
Expiry

Expiry options depend on the store:
StoreExpiration choices
Organization KeysNo expiration (created without an expiry from the dashboard)
IDE KeysNo expiration, 30, 90, 180, or 365 days
CI/CD KeysNo expiration, 30, 60, 90, 180, or 365 days
Expiry is enforced at authentication time: once a key’s expires_at passes, requests are rejected with 401.

​
Revocation

StoreHowEffect
Organization KeysRevoke, rotate, or deleteRevoke marks the key dead and it stops authenticating immediately. Rotate issues a new secret in place, so integrations keep the same key entry. Delete removes it outright
IDE KeysDelete from the key listThe key is removed; every IDE device using it is signed out until a new key is pasted
CI/CD KeysRevoke from the key tableThe key is marked revoked and stops authenticating
All three take effect immediately — every authentication path checks the revoked state on each request, so there is no cache to wait out. Rotating an Organization key returns the new secret once, at the moment you rotate. Copy it before leaving the page, then update wherever the old key is deployed. If you cannot update every consumer at the same time, create a second key instead, migrate consumers one at a time, and revoke the first when nothing is using it. For agents and workers you can do a clean swap: create the new key, update the deployment (--set backend.apiKey=… for the sensor, or the relevant .env), roll out (docker compose up -d / kubectl rollout restart), then delete the old key.

​
Storage

Only a SHA-256 hash of the key is stored, plus a short prefix to identify it in the dashboard list. Authentication hashes the presented key and looks up that hash — there is never a plaintext comparison.
Copy the key when it is shown. The full key appears exactly once, when you create or rotate it. It is not stored, so it cannot be shown again — the dashboard list only ever displays the prefix. If you lose an Organization key, rotate it; for IDE and CI/CD keys, create a new one and delete the old.
Pass an Organization key via Authorization: Bearer tg_… or the X-API-Key header — never in a query string, where it would land in access logs.

​
Audit

Creation and deletion of Organization and IDE keys are recorded to the organization audit trail, viewable under Settings → Organization → Audit Logs. Each key row also shows a Last used timestamp, updated on every authenticated request. If you suspect a key has leaked, revoke or delete it immediately, then review the audit trail.