How can we help?

Rotating your LLM token tracking ingest token

Uri Nativ
Uri Nativ
  • Updated
Torii AI

Your ingest token authenticates every event the Torii AI Telemetry page receives. Rotate it on a regular schedule (your standard secret-rotation cadence - quarterly or sooner) and immediately if you suspect it's been exposed.

The rotation guarantee: 24-hour overlap

When you rotate, the previous token stays valid for 24 hours. The new token works immediately. This window lets you propagate the new value through your MDM or collector environment without dropping a single event.

Practical implication: you do not have to coordinate the rotation with a maintenance window. Rotate at 10am, update your MDM parameter or collector env var sometime that day, and verify before the 24-hour grace period expires.

How to rotate

  1. In Torii, go to AI → Telemetry → (any tool page). The Credentials card at the top of the page contains the token row.
  2. Click the Rotate button on the token row.
  3. Confirm in the dialog. Torii issues a new token and shows it masked in the Credentials card.
  4. Click Copy on the token row to copy the unmasked new value to your clipboard.

Rotation is shared across all three tools - Claude Code, Gemini CLI, and Codex CLI all use the same ingest token, so you rotate it once and it applies everywhere.

Updating the new token in your deployment

Where to put the new value depends on the deployment path you used.

If you rolled out via MDM

For each MDM policy that runs a Torii install script:

  1. Open the policy in your MDM.
  2. Update the TOKEN parameter (or whatever the per-vendor field is called - see Article 6) to the new value.
  3. Save. The next time the policy fires on each machine (login, recurring check-in, on-demand), the install script writes the new token into the CLI's config file.

You do not need to re-upload the script - the script bytes don't change, only the parameter does.

Within the 24-hour window, every machine that's online should pick up the new value on its normal MDM check-in cadence. If you have machines that are offline (laptops in storage, etc.), they'll be on the old token until they next check in - and that token stays valid until they do.

If you wired Torii into your existing OTEL collector

Update TORII_INGEST_TOKEN in the secret store your collector reads from (Vault, AWS Secrets Manager, Kubernetes Secret, env file, etc.) and signal the collector to pick up the new value:

  • otelcol / Splunk OTel / ADOT: kill -HUP <pid> (or your process manager's reload command).
  • Grafana Alloy: SIGHUP or alloy reload.
  • Datadog Agent gateway / Elastic Agent gateway (the small otelcol you stood up in front): same as otelcol.

If you run multiple collector instances (gateways across regions, sidecars per cluster), update each one. Partial rollouts are fine within the 24-hour window - instances still on the old token continue to work, and you can confirm new-token success by tailing events from workstations routed through an updated instance.

If you used the manual one-liner or manual config edit

Re-run the one-liner on each machine with the new token, or edit each config file by hand and replace the old token with the new one. This is not realistic for fleets - if you've grown past a handful of machines, move to MDM rollout.

Verifying the rotation took effect

  1. After updating the MDM parameter or collector env var, run a test event from a workstation you know has the new token (or a workstation that has checked in with the MDM since you updated the parameter).
  2. Watch the event tail in Torii. Successful events on the new token will appear as normal.
  3. If you want to be extra sure, ask Torii support to confirm which token(s) are seeing traffic. Within the 24-hour window, both old and new will be active.

What happens at the 24-hour mark

After the grace period ends, the old token returns 401 Unauthorized at the ingest. Workstations or collectors still configured with the old token will stop sending successful events. The Status card in Torii will transition to Stale (last event > 14m ago) for any tool where every active machine was still on the old token.

If you discover at hour 25 that you missed a corner of the fleet, contact Torii support - we can temporarily re-enable the old token to give you another rollout window.

When to rotate immediately

  • You suspect the token was accidentally committed to a public repo, shared in a screenshot, or included in a script body uploaded somewhere it shouldn't have been.
  • An employee with access to the token (or to the MDM that stored it) leaves the company.
  • You're moving from a "trial" deployment to a production rollout and want a clean separation.

Token hygiene

  • Never paste the unmasked token into a script body that lives in source control. Use MDM parameters or collector env vars instead.
  • The Torii install scripts intentionally never log the full token - verbose mode prints only the last 4 characters. If you're capturing MDM script output for audit, the token won't be in it.
  • The token is treated as a bearer credential (Authorization: Bearer … for Claude and Codex; embedded in the URL path for Gemini due to upstream CLI limitations). Same handling principles either way.

Next steps

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request