CI/CD & automation
Your pipeline gets an identity, not a shared secret
The usual arrangement is one long-lived, broad-scope token in a vault that nobody can fully account for. Here a pipeline is an identity whose credential can execute exactly what you listed, where and when you listed it—and every step of its life is on the record.
What bounds a token
Narrow by construction, not by promise
A service token starts with nothing. Everything it can do is something you granted, and everything you granted has an edge.
An identity, not a key
The pipeline authenticates as an application with its own service token. Commands it runs land in the record under the application's name, not a person's.
Deny-by-default allowlists
Three independent ACL types—commands, servers, file paths—and each denies by default. A command not on the list does not run; a token with no rule of a type has no access of that kind at all.
Bounded in space and time
Pin the token to IP ranges, and to the hours and weekdays it may work. A deploy token that only deploys from your runners, only on weekdays, is three fields—not a policy document.
An expiry it cannot outlive
Every token carries a 30, 90, 180, or 365-day rotation policy. Rotating is one call that keeps the ACLs and bounds; expired tokens are cleaned up automatically instead of lingering.
A recorded life
Created, activated, updated, rotated, disabled, deleted—each lifecycle event lands in the token's history with who did it. When an auditor asks about a credential, the answer is a timeline, not an interview.
Tokens can be born pending
A token issued through the approval lane exists from the moment it is requested—but it authenticates nowhere until an approver activates it. The credential your pipeline holds was reviewed before it worked, and the activation is in the history.
Incidents
Even the emergency path keeps the allowlist
When an incident needs a token to work from the wrong network or outside its hours, break-glass access lifts exactly two things: the IP allowlist and the time window. It takes a superuser, a written justification, and a duration of one to eight hours. The command, server, and file allowlists still apply, and both the activation and the deactivation land in the token's history.
- Superuser plus written justification, 1–8 hours
- Lifts only IP and time bounds—ACLs still apply
- Activation and deactivation both recorded
Where it runs
Drop it into the pipeline you already have
No runner-side agent, no inbound port. The pipeline authenticates with its token and works.
GitHub Actions
Four published actions—setup, exec, copy, websh—so a workflow step runs a bounded command on your servers with nothing to install by hand.
Docker image
The CLI as an image, for any CI system that can run a container.
Ansible
Register fleets with the guided playbook—the same path the console walks you through.
REST API
Everything the console does is API-addressable with the same token bounds, audit records included.
MCP
AI agents connect through the hosted MCP server and operate under the same ACLs and audit trail as any pipeline.
CLI
One binary for shells, file transfer, and batch commands—scriptable end to end.
CI/CD & automation
Give your pipeline an identity today
Connect a server, mint a token, bound it. The free plan is enough to see the whole loop.