gitai binds each coding agent’s writes to its own token. One config flag decides whether that holds

Published October 23, 2026 · Last reviewed October 23, 2026

In May 2026 Anthropic merged about 2,500 code changes a day. By September it was merging more than 30,000, and source control, builds and CI, all built for human-scale work, had become the bottleneck.¹² On October 13 the company described Scion, the server-centric version control system it built to replace its Git setup, and called it “by no means a suitable replacement for git for general use.”¹ The Register reports there will be no open source release.³

Two days later an independent developer published an MIT-licensed server that implements the publicly described design on top of ordinary Git repositories. It shipped as open_scion and was renamed gitai (repository feder-cr/git-ai) the next day.⁴ Four more releases followed in eight days, the latest, v0.4.0, on October 23.⁵ That morning the repository had about 970 GitHub stars, which measures attention, not production use.⁶

Anthropic’s post is mostly about speed. The more useful part of gitai is smaller and easier to check: its documentation says exactly which caller identity a write is judged by, and which deployment setting makes that guarantee disappear. That boundary is worth understanding before anyone generalizes from “each agent has its own token” to “we know who did this.”

What shipped: an open source take on a design Anthropic kept in-house

Scion moves the work to the server: instead of every client holding a full copy of a monorepo with almost 100 GB of history, the server answers history questions, creates commits and runs merges, and each update is a changeset in a write-ahead log.¹ The post mentions access control and per-directory permissions but does not describe how Scion identifies an agent.

gitai is not that system, and its README says it is “not affiliated with or endorsed by Anthropic.”⁷ It starts from a fork of Gitaly, GitLab’s Git RPC server, leaving out upstream’s non-MIT ee/ directory, and adds a layer it calls Graft: per-agent tokens, an RPC allowlist, branch policies, server-side landing with a compare-and-swap per reference, a changeset log and a review service. Its identity model is the maintainer’s own design, and the README marks interfaces as subject to change before 1.0.⁷

The README’s headline benchmark compares gitai with the same server with batching turned off, not with ordinary Git hosting, in two runs on one 16-core machine with a shared file that “conflicts by design.”⁸ It shows that batching helps this server under contention, and nothing broader.

Follow one write: five fields that all look like “who did this”

Take one agent, configured as a [[graft.agent]] entry with its own token_file, asking a standalone gitai server to land a change on a protected branch. The request touches five things that could each be read as “who did this,” and gitai treats them differently.

1. The credential. The server compares the token in constant time and takes the caller’s identity from it. In the security document’s words: “Agent identity is taken from the token, never from the request.”⁹
2. The request’s identity fields. Gitaly requests carry gl_id and gl_username. For a caller with an agent token, the request-defaults code sets both to the agent’s name “even when the client sent another value.”¹⁰ It does not compare the two first; it overwrites. Callers using the shared token keep whatever they sent.
3. The policy actor. [[graft.policy]] rules decide which actors may update which references, including the HEAD symbolic ref, so an agent cannot repoint HEAD around a protected branch. A different gl_id from the client does not change the decision.¹¹
4. The changeset actor. The log records the token’s identity: the agent’s name, or shared for the shared token. When the server batches concurrent lands into one update, the batch entry’s actor is graft-batch and each member keeps its agent’s name, though a member list longer than 32 KiB is cut and flagged as incomplete.¹¹¹²
5. The committer and the author. The committer name and email of new commits are kept as the client sent them, and author fields come from the client’s own commits.¹¹ They are text the client supplies.

In standalone mode, then, the token, the policy actor and the changeset actor all name the same configured agent, while the author and committer fields can say anything. Reviews follow the token too, so one agent cannot approve as another, but the review document adds that “landing does not check reviews yet.”⁹¹³

Those agreeing fields are a local label the operator wrote into a config file, bound to a secret the operator handed out. They say this credential made this change. They do not say which person or company the agent works for, whether that person approved this change, or anything a party outside the server could check, and gitai does not claim they do. An IETF Internet-Draft on agent identity, revised on October 1, names the same gap: a workload identity alone “may not identify the user or organization accountable” for what an agent does.¹⁴

How GitHub and GitLab label agent writes

The hosted platforms draw the same line between what a client claims and what the server knows, and some go further. GitHub’s Copilot cloud agent (formerly the Copilot coding agent) authors its own commits and lists the person who assigned the task as co-author, and since April 3 it has signed every commit it makes.¹⁵ On October 12 GitHub opened a limited preview of push attribution for Enterprise customers. It records the authenticated pusher next to each commit, because “Commit author and committer fields are just strings that the pushing client supplies.”¹⁶ GitLab’s composite identity, generally available since GitLab 18.8, “combines two identities into a single token”: the agent’s service account and the person who started the request, with the lower of the two roles applied.¹⁷

gitai’s agent token covers the first half of that pair. It names the agent. Nothing in it names the person who set the agent running, and signed changesets are still a roadmap item.¹¹

The flag that moves the boundary

Everything above assumes one setting. With graft.standalone = true it does its own access checks and hooks and needs no GitLab. Otherwise it sits behind GitLab the way upstream Gitaly does, and GitLab’s /allowed endpoint makes the access decision.¹¹

The server installs the request defaults that write the agent’s name into the identity fields only when graft.standalone is true, and only on its external listener.¹⁸ The limitations document spells out what follows when they are off: with agents configured but standalone mode disabled, the gl_id and gl_username an agent sends reach GitLab’s /allowed check unchanged, “so an agent can act as any GitLab user.”¹¹

The same agent with the same token can therefore end up with two identities: in standalone mode it cannot claim another actor, and behind GitLab the identity checked is whatever the agent typed.

Version 0.4.0, released on October 23, took one agent rule out from under the flag: agents can no longer write the server’s own refs/graft/ references in any mode.⁵ The identity overwrite still depends on standalone mode.

The second exception is the shared token, the upstream Gitaly credential that operators keep. The limitations document calls it an administrative credential whose holder can act as any user, as with upstream Gitaly and GitLab, and the security document says it is an operator credential, not an agent.¹¹⁹ If an agent’s runtime can reach that secret, per-agent tokens stop meaning much, and the log records shared instead of a name.

None of this is an exploit. The project documents its own boundary, and the practical reading is narrow:

• What per-agent tokens guarantee depends on the deployment, and standalone mode is off by default.¹⁹ Check graft.standalone before relying on it.
• Keep the shared token out of every agent’s environment.
• Treat commit author and committer fields as client input in either mode.

”Success” needs evidence: what the releases fixed and what the log can miss

Authority is one half of trusting an agent’s write. The other half is whether “done” means done, and two fixes in v0.2.0, released on October 18, are about that.²⁰

The first concerns committer dates. The release notes say landing decisions are now “exact when committer dates are skewed”: an inexact history check could refuse an already landed commit or merge it a second time, and the rebase operations, which come from Gitaly, had the same exposure.²⁰ Committer dates are client-supplied text, the same field the previous sections said not to trust. Here the text fed a correctness decision, not attribution.

The second concerns squashes. UserSquash, an RPC inherited from Gitaly that agents can call only if an operator adds it to graft.agent_rpcs, could report success without a commit when a merge failed for a reason other than a conflict.⁹ A caller that trusts the return value would carry on as if its change had been squashed. Version 0.3.1 fixed a related case, in which a land answered already_landed for a branch that did not exist.²¹

The changeset log, the record of what happened, has documented edges too:¹¹

• Only reference updates that pass through Gitaly’s transaction path are recorded. Tools that write to the repository directly are not.
• With the default file log, a recording error cannot undo an update git has already committed, so the log can miss it; each loss is counted in a metric. With the optional storage core in authoritative mode, the log is written in the same database transaction as the update.
• Signed changesets and a verifiable export of the log are on a roadmap the project says is not a commitment.

So the log is careful operational evidence kept by the operator, not a tamper-evident audit trail a third party could verify. Our look at Strands Box found the same shape one layer down: decision records that belonged to the operator, unsigned, with every agent inside the sandbox named self.

How this connects to Tobira

gitai answers a question inside one organization: may this credential change this branch? Tobira works on a different question, the one that comes up when an agent leaves the systems its operator controls and meets a stranger’s agent: whom does the agent represent, and do both humans want to be introduced? A Tobira @handle gives the person or company an agent represents an address another agent can look up (the network had 729 agents per Tobira internal data, September 2026), and mutual reveal shares contact details only after both sides agree. None of that replaces repository authorization, tests or audit logs. It sits next to them, at the relationship boundary a repository token was never meant to cover.

What to remember

• gitai is not Scion. It is an independent MIT-licensed Gitaly fork, first published as open_scion, built from Anthropic’s public description of an internal system.
• The token names the agent, not the person. In standalone mode the token, the policy actor and the changeset actor agree. Commit author and committer text is whatever the client sent. GitHub and GitLab now record more: the pusher, a signature, or the person who started the agent.
• One flag decides whether it holds. With graft.standalone off, an agent’s gl_id and gl_username reach GitLab’s /allowed check unchanged, and the shared token can act as any user in every mode.
• Success reports and the log are the operator’s evidence. The releases fixed false successes. The default log can miss updates, reviews do not gate landing yet, and signing is only on the roadmap.

Anthropic’s 30,000 merges a day land on a server nobody outside the company can run. The open implementation ships with its boundary written down: one setting, graft.standalone, in a file called LIMITATIONS.md.

Frequently asked questions

What is gitai?

gitai (repository feder-cr/git-ai) is an open source, Git-compatible version control server for many coding agents working at once. It is MIT licensed, forked from GitLab’s Gitaly, and adds per-agent tokens, branch policies, server-side landing and a changeset log. It was first published as open_scion on October 15, 2026, renamed the next day, and reached v0.4.0 on October 23. It implements the publicly described design of Anthropic’s internal Scion and is not affiliated with Anthropic.

Can an agent act as another user in gitai?

It depends on the deployment. In standalone mode, an agent token cannot claim another actor: the server overwrites the request’s identity fields with the agent’s name. With agents configured but standalone mode off, the documentation says the identity fields an agent sends reach GitLab’s /allowed check unchanged, so the agent can act as any GitLab user. The shared token is an administrative credential in every mode.

How do GitHub and GitLab label agent writes?

GitHub’s Copilot cloud agent authors its commits, lists the person who assigned the task as co-author and signs every commit. GitHub is also previewing push attribution for Enterprise customers, which records the authenticated pusher next to each commit. GitLab’s composite identity puts the agent’s service account and the person who started it into one token. gitai’s agent token names only the agent.

Does gitai’s changeset log prove who did what?

It records which configured token made each reference update that passed through Gitaly’s transaction path. Direct repository writes are not recorded, the default file log can miss an update when recording fails, and signed changesets with a verifiable export are only on the roadmap. It does not identify the human or company behind an agent.

Sources