# Keys and authentication

Keep public ingestion, secret build uploads, and agent sessions separate.


## Which credential goes where?

| Credential | Used for | Browser bundle? |
| --- | --- | --- |
| Public project key `pk_…` | SDK telemetry and public release reports | Yes |
| Secret upload key `ik_…` | Source-map upload in CI/server builds | Never |
| CLI/device session | Authenticated agent and platform operations | Never |
| Personal API key | Explicit CI/platform integration where supported | Never |
| GitHub App/OAuth secrets | Authorized repository integration on the server | Never |

A public ingestion key is not a platform management token. CLI login does not turn it into a secret account credential and does not grant GitHub access.

## Rotation

Project key endpoints support rotation. Update the consuming runtimes/build environment with the new value and verify delivery. Do not keep using predictable legacy project-ID-derived keys; new integrations should use the generated random key.

## Storage

Keep CLI credentials in their protected configuration directory and server/provider secrets in a secret manager or private files. Never put an `ik_…` upload key, a personal API key, an OAuth client secret, or a private App key into a browser variable.

For self-hosting, set the deployment's public origins and encryption/authentication configuration consistently. A local-development service token is not an appropriate universal public-user credential.