Skip to content

Enrollment

tokenshift install wires the agent hooks. Enrollment is the separate step that binds the binary to a specific TokenShift tenant — required for anything that touches the cloud side.

All you need is your tenant UUID, handed to you by your PointFive contact at onboarding:

Terminal window
tokenshift enroll --tenant-id=00000000-0000-4000-8000-000000000001

That writes ~/.tokenshift/enrollment.json with sensible defaults — Tier 2 telemetry, raw directory name as the project label, recovery cache on. Every default is its own flag if you need to change it:

Terminal window
tokenshift enroll \
--tenant-id=00000000-0000-4000-8000-000000000001 \
--tier-cap=1 \
--project-mode=hashed_remote

Then verify:

Terminal window
tokenshift doctor --verify

This ships one synthetic record through the live ingest path and reports acceptance.

Prefer to review the full manifest before applying it, or feeding an MDM rollout? Generate the JSON in your browser — nothing here calls out to a server — and apply it with tokenshift enroll <path>:

Tenant

The UUID your PointFive contact gave you at onboarding. The binary rejects non-UUID tenant IDs at manifest load.

Telemetry policy

Maximum tier any client in this tenant can emit. Users can opt below, never above.

How a repo identifies itself in records. Raw mode exposes repo names — only enable if your security review allows it.

Sampling Tier 4 only

%

Per-rule sampling probability for compression_sample. 0% = off even when Tier 4 is permitted.

Comma-separated rule names that may be sampled. Empty = no samples emitted, regardless of tier or rate.

Terminal window
# from a file
tokenshift enroll ~/Downloads/enrollment.json
# or from stdin (paste / pipe)
pbpaste | tokenshift enroll -

~/.tokenshift/enrollment.json — what tokenshift enroll writes. No sudo required. The runtime resolver looks here first.

The same shape works at either path. Per-user wins if both exist.

Pinning (the ingest URL + public key compiled into the binary) tells TokenShift where to send records and how to encrypt them. The enrollment manifest tells TokenShift who is sending them — the tenant ID and the per-tenant HMAC key used to derive stable, pseudonymous user IDs.

Without an enrollment manifest, TokenShift still works as a local proxy and hook layer:

  • compression and rewrite rules run normally
  • recovery cache is populated and readable
  • stats land in the local SQLite DB

Telemetry, recovery sync, and any feature that talks to the cloud side stay off.

FieldMeaning
tenant_idThe tenant your records land in. The only field required.
bearer_tokenOptional. Reserved for a future per-tenant ingest credential; omit it.
user_id_hmac_keyOptional per-tenant 32-byte salt (base64) for deriving pseudonymous user IDs. When omitted, it is derived deterministically from tenant_id, so attribution stays consistent across every machine in the tenant.
config.tier_capMaximum telemetry tier this tenant allows. Effective tier is min(local tier, tier_cap). Defaults to Tier 2.
config.project_modeHow project names are derived for project labels on records. Defaults to raw_dir (raw directory name).
config.recovery_cache_enabledWhether the local recovery cache is enabled for this tenant.
config.sample_allowlistRules eligible for Tier-4 compression samples.
config.sample_rateProbability that an allowlisted invocation actually emits a sample.
  • MDM rollout — patterns for Jamf, JumpCloud, Intune, Ansible.
  • Security overview — what’s encrypted on the wire and what’s never transmitted.