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.

Enroll with your tenant ID

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

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 — and enables silent background self-update for this machine. Every default is its own flag if you need to change it:

tokenshift enroll \
  --tenant-id=00000000-0000-4000-8000-000000000001 \
  --tier-cap=1 \
  --project-mode=hashed_remote \
  --auto-update=false

--auto-update is the one flag that affects local machine config ([update].auto_update in ~/.tokenshift/config.toml) rather than the enrollment manifest; pass --auto-update=false to keep updates manual (tokenshift update).

Then verify:

tokenshift doctor --verify

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

Advanced: apply a manifest file

Prefer to review the full manifest before applying it, or feed it into an MDM rollout? Generate enrollment.json in the PointFive app, then apply it with tokenshift enroll <path>:

# from a file
tokenshift enroll ~/Downloads/enrollment.json

# or from stdin (paste / pipe)
pbpaste | tokenshift enroll -

Where it lives

Per-user (default)

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

System (MDM)

• macOS / Linux: /etc/tokenshift/enrollment.json
• Windows: %PROGRAMDATA%\tokenshift\enrollment.json

Used when an MDM (Jamf, JumpCloud, Intune, Ansible) drops a manifest as root for every user on the machine. The runtime resolver falls through here when no per-user manifest is present. See MDM rollout.

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

Why enrollment exists

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.

Field reference

Field	Meaning
tenant_id	The tenant your records land in. The only field required.
user_id_hmac_key	Optional 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_cap	Maximum telemetry tier this tenant allows. Effective tier is min(local tier, tier_cap). Defaults to Tier 2.
config.project_mode	How project names are derived for project labels on records. Defaults to raw_dir (raw directory name).
config.recovery_cache_enabled	Whether the local recovery cache is enabled for this tenant.
config.sample_allowlist	Rules eligible for Tier-4 compression samples.
config.sample_rate	Probability that an allowlisted invocation actually emits a sample.

Note

For the full security model — threat surface, what each field protects, how the wire path enforces it — see Installation & distribution.

Next

• MDM rollout — patterns for Jamf, JumpCloud, Intune, Ansible.
• Security overview — what’s encrypted on the wire and what’s never transmitted.