Install tokens: lifetime, scope and hygiene

An install token is the credential that lets a fresh agent enrol and tells the platform where that agent belongs. It is issued against a specific client and site, and it has a configurable lifetime.

Treat a token as a credential, because it is one. Anyone holding a valid token can enrol a machine into your estate at the client and site the token names. That is a lower-consequence event than most credential leaks, but it is not a nothing event: an unexpected endpoint in a client tree is a confusing thing to discover during an audit.

Three practices keep this manageable. Issue tokens per deployment batch, not per estate. Set the lifetime to slightly longer than your deployment window rather than to the maximum available. And treat a token that has appeared in a ticket, a chat message or a shared script as spent — regenerate rather than reasoning about who might have seen it.

Tokens are consumed at enrolment. Once an agent has enrolled, its ongoing connection to the platform does not depend on the token remaining valid, so token expiry never disconnects a working endpoint. Expiry only prevents new enrolments.

If an install fails with an enrolment rejection, the token is the first thing to check — expired, mistyped, or copied with a trailing character from a chat client that helpfully appended a space. The agent log will distinguish a rejected token from a connectivity failure, and reading it takes less time than guessing.