Docs / Make changes safely
Automation tokens
Planned design. TractorStack is in development. This page describes how it is designed to work; nothing here is available to install yet. See the roadmap for the status of each part.
Exploring An idea we are working through. Nothing here is committed, and the details will change.
Scoped tokens for automation and CI answer a simple need: a script or a pipeline sometimes has to start a run, and it should not need a person’s password or a broad admin key to do it. The idea we are exploring for TractorStack is a narrow, expiring token that can do one job, such as starting a plan for one environment, and nothing else. Above all, a token can start a run but never approve one.
Why not just use a personal account
When automation borrows a person’s credentials, three problems follow. The audit trail can no longer tell the person from the script. The credential usually has far more access than the script needs. And when the person leaves or changes roles, something breaks, often at night. A dedicated token fixes all three: it is named for its purpose, limited to what that purpose needs, and owned by a team rather than an individual.
Scoped tokens for automation and CI: what one could do
The shape we have in mind for a token:
- One or a few environments. A token for
site-a/testcannot touchsite-a/prod. - One or a few actions. For example: start a plan, start a drift check, read run results. Applying is only possible after a person has approved the matching change.
- An expiry date. Every token expires. Short lifetimes, measured in days or weeks, are the default we are considering; very long lifetimes would need a stated reason.
- A named owner and purpose. Recorded when the token is created, and shown in every run it starts.
| Action | Token | Person with the right role |
|---|---|---|
| Start a plan or check | Yes, if in scope | Yes |
| Read run results | Yes, if in scope | Yes |
| Approve a change | Never | Yes, if not the author |
| Create or widen tokens | Never | Admins only |
Where tokens are kept
A token is a secret and is treated like one. In GitLab it would live as a masked, protected CI/CD variable, available only to protected branches. On other machines it belongs in the same secret store as other credentials, described in secrets and credentials. It should never appear in a repository, a log line or a ticket. The token value would be shown once, at creation, and only a hash kept on the server, so a database leak does not expose working tokens.
Rotation and revocation
Expiry forces rotation, which is the point: a token that is replaced regularly limits how long a leaked one is useful. The plan is to warn the owner before expiry through alerts, so rotation is a routine task rather than a surprise outage. Revoking a token takes effect immediately, and runs it already started continue to be recorded under its name.
Tokens fit alongside single sign-on for people: people sign in through your identity provider and approve changes; automation uses tokens and only starts work. Keeping those two paths separate is what makes the sign-off rule hold.
Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com