One identity system, two credential kinds.

tfp_ tokens — the git password and API key

A tfp_ token is your credential for HTTPS git (it’s the password) and for the CLI / API. Mint one scoped to exactly what it needs and give it an expiry.

# Mint a token — read | write | admin, optionally repo-scoped, with an expiry.
tilldev forge tokens create --scope write --repo acme-api --expires 90
# → tfp_live_…   (shown ONCE — copy it now)

tilldev forge tokens ls               # list; secrets are never shown again
tilldev forge tokens revoke <id>      # kill a token immediately

Add --repo <slug> to pin a token to a single repository — least authority by default. A token can never exceed the role of the member who minted it.

Keep a token in TillSecrets? Deleting or rotating that secret can revoke the old tfp_ token in the same step. See revoke on delete.

SSH keys with an enforced lifecycle

For SSH git, register a public key. TillForge validates the key, records its SHA-256 fingerprint, and refuses an RSA key under 2048 bits, a key already registered in the workspace, and a key whose private half is known (see Leaked keys). Every key is scoped and must carry an expiry — there are no long-lived keys, which is exactly the control that lets SSH sit alongside HTTPS safely.

# Your own key: every repo you can reach, and it pushes as you.
tilldev forge keys-account add --name laptop \
  --key "ssh-ed25519 AAAA… you@host" --scope write --expires 90
tilldev forge keys-account ls         # fingerprints, owner, scope, expiry, last-used
tilldev forge keys-account rm <id>

# Owners and admins: a machine key for automation, org-wide or one repo.
tilldev forge keys-account add --name ci-box --key "ssh-ed25519 AAAA…" --machine
tilldev forge keys add <repo> --name deploy --key "ssh-ed25519 AAAA…" --scope read

Only the public half is ever stored. Keys are listed with their fingerprint, owner, scope, expiry, and last-used time. You can revoke your own keys; owners and admins can revoke any, and revoke is instant. Who a key belongs to decides whose name its commits may carry (see Commit identity). Use these with the SSH clone URL.

The same public key can be registered in several workspaces. Each registration only governs its own workspace, so someone who adds your public key to theirs gains nothing and doesn’t lock you out.

Leaked keys

A key is refused everywhere once its private half is known. That covers keys published with tools (such as Vagrant’s insecure keys) and any private SSH key that lands in a TillForge repository: the secret scan flags it, and once someone allowlists it into history or a pull mirror brings it in, every registration of that key is revoked in every workspace, it can’t be added again, and its commit signatures stop counting as Verified. The git server proves it holds the private key before anything is revoked, and a push the scan refused revokes nothing, since the key never entered history. Revoked keys show as revoked · private key leaked, and the finding names the key’s fingerprint.

An RSA key under 2048 bits that was registered before this rule shows as refused · too weak and no longer works over SSH. Make a new key with ssh-keygen -t ed25519.

Roles govern git and the API alike

Membership and roles are TillAuth’s — an org has owners, admins, developers, and viewers, and that role governs both what a session can do in the dashboard and what a tfp_ token or SSH key can do at the git boundary.

Authorization is 404-not-403: a request for a repo outside your org resolves to a not-found, never a permission leak. Every high-privilege action — a force-push to a protected branch, a policy change, minting a token — is append-only audited (read it with tilldev forge audit).