Device keys & provisioning tokens

Every device in your fleet holds exactly two kinds of credential over its life, and neither is a user login:

1. A provisioning token (apt_…) gets a device onto the platform. It’s what the setup command carries.
2. A device key (adk_…) is the device’s permanent identity. The agent presents it on every request after enrollment.

Keeping these separate is deliberate: a leaked setup command can’t impersonate an enrolled device, and a compromised device key can’t enroll new devices — or act as any user.

​

Provisioning tokens

When you click Add Device, the dashboard generates a setup command backed by a provisioning token. Those setup commands are single-use and expire after 24 hours — if one goes stale, generate a fresh one rather than hunting down the old command. For automation — enrolling many devices from your own tooling — the API also lets you create named provisioning tokens with a longer lifetime:

• Named and tracked — each token has a name, a use count, and a last-used timestamp, so you can see what’s enrolling devices.
• Expiring — tokens expire (30 days by default) and can be created as single-use, which revokes them automatically after the first successful enrollment.
• Revocable — revoke a token at any time to stop it enrolling anything new. Devices already enrolled with it are unaffected; they hold their own device keys.

See POST /api/provisioning-tokens in the API reference.

​

Device keys

Enrollment ends with the platform issuing the device its key:

• Shown once. The raw key is returned to the device at provisioning and never again — the platform stores only a hash (SHA-256), so keys can’t be read back out of the database.
• Device-scoped. The agent sends the key as an X-Device-Key header, and it only works on device endpoints — check-in, uploads, model downloads. It is not a general-purpose API key.
• Org-scoped. Like everything else, a device key is bound to your organization.

​

Rotating a key

There’s no separate rotation ceremony — re-running the setup command on a device rotates its key. Re-provisioning deletes the device’s old keys and issues a fresh one, so a device you suspect is compromised can be re-keyed with one command (generate a new setup command first; the old one will have expired).

​

Revoking access

• Revoke a provisioning token to stop new enrollments through it.
• Delete the device to cut off an enrolled device: its keys are removed (so its next request fails), and its management endpoint is cleaned up with it.
• Removing a user (Orgs, users & multi-tenancy) never touches device keys — people and devices are revoked independently.

​

Clone protection

At enrollment the platform records a hardware fingerprint for the device. If something later tries to provision with the same device identity but different hardware — a copied disk image, a duplicated config — the platform rejects it as a suspected clone rather than silently re-keying. The same applies across organizations: hardware already enrolled in another org can’t be re-enrolled into yours.

​

Next steps