Anthropic's Scion Explained: A Supply Chain Security View

Scion is the in house version control system Anthropic built to replace git for its own monorepo, described in an Anthropic engineering post on 13 October 2026. It is not released, and Anthropic says plainly that it is not a general git replacement. For security teams, the useful part is the design: a server that owns history, merges and permissions.

Below: what Anthropic published, how the model compares with git and Subversion using their own documentation, and what agent scale merge rates mean for scanning and provenance. Every Scion fact comes from Anthropic's post. Where Anthropic is silent, such as the hash function or signing, we say so and do not guess.

Key takeaways

• Scion is Anthropic's internal source control system. It is not available to install, and Anthropic says it is not a suitable replacement for git for general use.
• Anthropic built it because daily merges to its monorepo grew from about 2,500 in May 2026 to more than 30,000 by September 2026, and CI was doing about 25 million checkouts a day.
• The server computes history, blame, commits, merges and rebases; clients keep only a bounded local cache. Data is content addressed and immutable.
• Scion supports repository access control and per directory permissions. Core git has no per directory read control; Subversion has path based authorization.
• Anthropic's post does not name a hash algorithm and does not describe commit signing, encryption, audit logs or provenance attestations. Those gaps matter if you are mapping a similar design to SLSA's source track.
• At 30,000 merges a day, a serial one minute gate clears only 1,440. Anthropic says it relies on post merge and pre deploy testing instead of a merge queue.
• For teams on git: enforce policy on the server, do not treat sparse checkout as access control, and count your mirrors.

What is Scion, and why did Anthropic build it?

Scion is the version control system Anthropic wrote to hold its monorepo after git stopped fitting the way the company works. The post, titled "Redesigning source control at Anthropic", was published on 13 October 2026 and updated on 15 October 2026 to add detail on the projects whose techniques Scion uses. It is credited to Nick G. and Anthropic's source control team.

The reason is agent scale. Anthropic's post argues that writing code is no longer the slow step; the slow steps are systems built for human pace, such as source control, builds and CI.

Source: Anthropic Engineering, "Redesigning source control at Anthropic", 13 October 2026, updated 15 October 2026.

Anthropic's observation is that git was designed for distributed, often offline work, while almost every client in its environment is an agent or job that is always connected, and the mirrors got harder to run as merges climbed. Scion was built alongside an internal code review tool called Antique, a code search system and a source control identity and access system.

How Scion is built

Anthropic's post lays out six design principles and an architecture. Here they are in our own words.

Design principles

1. Clients are always online. The server is assumed reachable at all times, and clients fetch what they need when they need it.
2. Work is lopsided on purpose. The server does the heavy work: history, blame, commits, merges and rebases. The client holds a bounded local object cache and the working files.
3. Source control is an API. The queries a client uses are also exposed through an API, so many jobs never need a local repository at all. The post names automated bisect and revert pipelines as tools that would not be practical at scale without this.
4. It scales out. Data is spread across machines. According to the post, no complete copy of the repository exists anywhere, the server included, and there are no packfiles to maintain.
5. Commits are cheap and do not take locks. Commits happen on the server, their cost grows with the size of the change rather than the size of the repository, and the workflow discourages refs such as branches and tags.
6. Working copies are optional and sparse. CI can ask the server for diffs and merge bases directly, and checkouts can be sparse or virtual.

Changesets in a write ahead log

The unit of work is a changeset recorded in a write ahead log. A changeset lists the files that changed relative to its first parent and holds content addressed pointers to compressed file contents in blob storage. Changesets are created on the server, not on the client.

Content addressed, immutable storage

Anthropic says all source control data is content addressed, so a stored piece of data never changes. Because of that, any server tier can cache any object without worrying that it will go stale. The post does not say which hash function produces the addresses.

Refs as a single row compare and swap

Refs still exist, but moving one is a separate operation from creating a changeset. A ref move is a compare and swap on a single row in Spanner, the database the authoritative server reads from along with cloud storage. Separating "record this change" from "point main at it" gives policy a clean place to sit.

Three tiers

All three tiers answer the same RPCs, and the tiering is enforced so that a failure in one domain stays there. The post reports a cache hit rate above 99 percent at each tier.

A protocol that asks only for what it needs

The client negotiates only the trees and blobs it wants, starting at a root tree and walking down. There is no single large packfile, and transfers can resume after an interruption. Sparse and virtual checkouts fall out of this without special handling.

Derived data

Blame, path history and commit graph skip lists are computed from changesets through one generic mechanism that builds each value from its parents' values, eagerly or later, without client changes.

Reported results

The post reports large gains in infrastructure cost, checkout time and CI capacity, plus a faster ingestion pipeline rewritten by an Anthropic model, Mythos Preview. The ranking below lists them.

Ranked: Anthropic's reported improvements by size

This ranking orders the multipliers Anthropic reported, from largest to smallest. Where Anthropic gave two raw figures rather than a ratio, we computed the ratio and marked it.

Source for every row: Anthropic Engineering, "Redesigning source control at Anthropic", 13 October 2026. The cache hit rate above 99 percent per tier is a level rather than a change, so it is not ranked.

Lineage: Sapling, Mononoke and Bonsai

Anthropic names prior art directly. The post says large monorepo source control has been done before, notably in Google's Piper and Meta's Sapling. The 15 October update adds specific credit to Mononoke, the server component of Sapling, saying it pioneered many of the techniques Scion uses, in particular the Bonsai data model.

Mononoke's public README describes it as a server for the Sapling source control system, written mainly in Rust and built to handle thousands of commits an hour across millions of files. It also says the project is still in development, that the public build lacks some features of the internal one, and that configuration documentation is limited. The README itself does not describe Bonsai, so for what Bonsai means inside Scion we rely only on Anthropic's statement that Scion uses that data model.

Can you use Scion?

No. Scion is internal to Anthropic and has not been released. Anthropic's post says Scion is "by no means a suitable replacement for git for general use." The post explains that its ideas only make sense for very large monorepos and that the internal tools are too tailored to Anthropic to release in a form other organizations could use.

What Anthropic does say is that it wants to share the thinking so that developers can bring the most successful parts of Scion to git, and that it hopes to work with the major git hosting platforms and the open source community to do that. No specific integration, partnership or release has been announced.

Public repositories that call themselves open or community Scion are not Anthropic's, and some say so. The SCION internet architecture is an unrelated networking project.

What always online clients change for integrity and audit

Git and Scion put the source of truth in different places, and integrity controls follow it.

How git spreads trust

Git is a content addressable store. Git's hash function transition document explains that blobs, trees, commits and tags are named by the hash of their content, which gives two things: corruption is detected because altered content no longer matches its name, and a signature on one object covers everything that object references, because the signed content names other objects by hash. That is why a signed tag on a release commit vouches for the whole tree beneath it.

Every full clone carries the entire history, so many independent copies of the object graph exist. If a server's history were rewritten, anyone with an older clone could notice the hashes no longer match. That side effect of the distributed design quietly does security work.

Git's partial clone documentation describes clones that skip objects and fetch them later from a "promisor" remote. It says partial clone requires connectivity and that git assumes promisor remotes have a complete view of the repository. A partial clone already trusts its server more than a full clone does.

How a server authoritative design concentrates trust

In Scion, by Anthropic's description, changesets, merges and rebases happen on the server and clients hold only a bounded cache. Three consequences apply to any system built this way.

Fewer independent witnesses. If clients do not hold full history, they cannot catch a history rewrite by comparing against their own copy. Integrity has to come from the server's own controls: immutable storage, restricted write paths, and records of who moved which ref and when. Content addressing helps, because anyone holding an object and its address can recompute one from the other. Anthropic does not say whether Scion clients verify addresses on read, so we do not claim they do.

One place to record everything. When every commit, merge and ref move happens on the server, the server sees every operation. In git, a merge is built on a laptop or CI runner and pushed as a finished object. A server that performs the merge can apply policy before the merge exists. Anthropic does not describe audit logging, so this is a property of the architecture, not of Scion's implementation.

A higher value target. Whoever can move a ref on that service changes what every build consumes. In git the equivalent is push access to a protected branch; the difference is that with fewer client copies there is less outside evidence after a compromise.

Side by side

Sources: git hash function transition and partial clone documentation; Anthropic Engineering post for the last column.

Access control: repository, directory and path

Anthropic's post says Scion supports rich access control on repositories and can apply permissions to individual directories, so sensitive code can be protected inside a single monorepo. It also describes the review tool, Antique, as able to express complex semantic constraints on approvals, for example telling a change that only touches comments apart from a sensitive logic change.

Git

Core git has no per directory read permissions. Hosting platforms add repository permissions and branch protection, which control who can push or approve, not who can read a path after cloning.

The gitnamespaces page says that "namespaces on a server are not effective for read access control," and advises keeping private data in a separate repository. The sparse checkout page describes a working tree feature with no security claims; excluded files stay in history. We covered this in more depth in sparse checkout is not access control.

Git does give you server side enforcement on writes: the githooks page describes pre-receive, which can reject a whole push, and update, which can reject a single ref. Clients cannot skip them.

Subversion

The Subversion book describes path based authorization: a rules file, read by Apache's mod_authz_svn or by svnserve, with sections per repository and path granting read, read and write, or nothing. Rules inherit downward, the most specific path wins, and groups are supported. The book notes the extra server work and maintenance, and advises restricting reads only when there is a real need.

Comparison

Sources: git githooks, gitnamespaces and sparse checkout docs; Subversion book 1.7, path based authorization; Anthropic Engineering post.

Path level read control is not new. What a server authoritative design adds is that the permission check and the data sit in one service whose protocol sends only requested trees and blobs. Anthropic does not describe how the two interact, so that is our inference, not a claim about Scion.

What Anthropic's post does not say

For a security reader, the omissions are as important as the content. We checked the post for each item below on 23 October 2026.

None of this means Scion lacks these things. The public description does not cover them, so a threat model should mark the gaps rather than fill them. For any system in this style, these are the questions to ask.

Why the hash function question matters

Git's hash function transition document notes that the SHAttered attack showed a practical SHA-1 collision on 23 February 2017. Git has used a hardened SHA-1 since 2.13.0, but still plans a move to SHA-256, and its breaking changes page says Git 3.0 will make SHA-256 the default for new repositories, with no release date yet. In any content addressed system, the address is only as trustworthy as the hash behind it, and an outside reviewer cannot confirm an unpublished algorithm.

Mapping to SLSA's source track

The SLSA source track gives a vocabulary for this. In SLSA 1.2:

• Source Level 1 means source lives in a modern version control system.
• Source Level 2 requires continuous, immutable, retained branch history, and the source control system issues a source provenance attestation for each new revision.
• Source Level 3 requires the system to enforce the organization's technical controls on designated branches and tags continuously.
• Source Level 4 requires two trusted people to agree to changes on protected branches.

The spec asks the source control system to give each revision an immutable identifier, record every ref change with who and when, block branch moves to non descendant revisions, and document immutability if identifiers are not cryptographic digests.

A server authoritative design fits this list well: one point to record history and enforce rules, immutable content addressed storage, and approval rules close to Level 4. But attestations and the hash behind identifiers are what a verifier checks, and Anthropic has not published them. Anthropic claims no SLSA level for Scion, and we assign none.

Agent scale numbers and what they do to scanning budgets

How we measured

We used only two numbers from Anthropic's post: more than 30,000 merges per day (September 2026) and about 25 million CI checkouts per day. Everything else in the tables below is our arithmetic, with the assumptions written out. The per scan times are illustrative round numbers, not measurements of any product. We did not average or adjust Anthropic's figures, and treated 30,000 as a floor, since the post says the rate is over 30,000. For the scale comparison with Google, we used only what Google's own research page states; the full Communications of the ACM article was not retrievable when we checked on 23 October 2026, so its detailed figures are not used here.

Rates

What a gate costs at 30,000 merges a day

Suppose every merge must pass a dependency and policy check.

Method: total time is 30,000 multiplied by the per merge time. Workers is total hours divided by 24. Serial capacity is 86,400 seconds divided by the per merge time.

Compute is not the hard part; even a five minute check needs about a hundred workers. Anything serial breaks: one lock with a one minute check tops out below 5 percent of the September 2026 rate. That matches Anthropic's remark that a proper merge queue does not make much sense at agent scale.

What that implies for supply chain controls

• Scope the check to the change. Most merges do not touch a manifest or lockfile. A dependency check that runs only when dependency files change, and runs a full inventory on a schedule, keeps per merge cost near zero for most changes.
• Move hard gates to the deploy boundary. If merges cannot wait, the place to block a known exploited vulnerability is before deployment, where the number of events is far smaller than the number of merges.
• Automate the fix path. At 1,250 merges an hour, a finding waiting on a human ticket is stale before anyone reads it.
• Read the diff, not the tree. Many security jobs need only the dependency files, not a 25 GB checkout.

A dated scale comparison

These rows come from different years and measures, so they are not a race. Google's 2016 framing is tens of thousands of human developers; Anthropic's 2026 framing is always online agents and jobs.

Lessons for teams still on git

Here is what translates to git now, with commands from git's own documentation.

Step 1: Enforce policy on the server, not the laptop

Client side hooks can be skipped; server side hooks cannot. This update hook, adapted from git's documented pattern, rejects any push that rewrites main:

#!/bin/sh
# hooks/update on the server: refuse non fast forward updates to main
refname="$1"; old="$2"; new="$3"
zero=0000000000000000000000000000000000000000
if [ "$refname" = "refs/heads/main" ] && [ "$old" != "$zero" ]; then
  if ! git merge-base --is-ancestor "$old" "$new"; then
    echo "Rejected: history rewrite on main" >&2
    exit 1
  fi
fi
exit 0

This is the SLSA source track rule against non descendant branch moves. Hosting platforms do this with branch protection.

Step 2: Use partial clone and sparse checkout for speed, not secrecy

Scion's sparse and virtual checkouts are a big part of its speedup. Git offers a version of this today:

# Skip file contents at clone time; fetch them on demand from the remote
git clone --filter=blob:none --sparse https://git.example.com/org/monorepo.git
cd monorepo

# Materialize only the directories this job needs (cone mode)
git sparse-checkout set services/payments libs/crypto

# Confirm what is in the working tree
git sparse-checkout list

Partial clone needs the remote reachable for unfetched objects, and sparse checkout controls only the working tree. A secret directory belongs in a separate repository or a system with real path level read control.

Step 3: Sign what you release and verify before you merge

Anthropic has not described signing in Scion. In git, signing is available today and is the one integrity control that does not depend on trusting the server. From the Pro Git book:

# Sign a release tag and a commit
git tag -s v2.4.0 -m "Release 2.4.0"
git commit -S -m "Bump dependency to fixed version"

# Inspect signature status for recent commits (G = good, N = none)
git log --pretty="format:%h %G? %aN %s" -10

# Refuse to merge a branch containing unsigned commits
git merge --verify-signatures feature/dependency-bump

The book's warning: signing only works if everyone does it, so make it the team default.

Step 4: Count your mirrors

Anthropic ran several hundred git mirrors at peak. Every mirror is a full copy of the source with its own credentials and access list. List every place a full copy of your main repository lives: CI caches, build mirrors, developer VMs, backups, vendor integrations.

Step 5: Scan dependencies independently of where the source lives

Dependency risk lives in manifests, lockfiles, images and SBOMs, so a scan of those works whatever system holds the source. With the Safeguard CLI:

# Scan a working directory, a built image, or an existing SBOM
safeguard scan --dir .
safeguard scan --image registry.example.com/payments:2.4.0
safeguard scan --sbom build/sbom.cdx.json
# Results are written as JSON under ./output

In CI, a minimal GitHub Actions step that runs only when dependency files change might look like this, assuming the CLI is installed on the runner as described in the CLI docs:

on:
  pull_request:
    paths:
      - "**/package-lock.json"
      - "**/requirements*.txt"
      - "**/go.sum"
      - "**/pom.xml"
jobs:
  dependency-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          sparse-checkout: |
            services/payments
      - run: safeguard scan --dir services/payments

Where Safeguard fits, and where it does not

Safeguard does not provide source control and has no Scion integration or Anthropic partnership; its source control integrations are with git hosting platforms. Most of its supply chain work does not depend on where source lives:

• SBOM and dependency scanning read repositories, container images and SBOM files, so the same scan applies whatever the version control system is.
• The platform shows which projects contain a given component and version, which is the first question after any new advisory.
• Vulnerabilities are matched against vulnerability databases, and reachability analysis ranks the ones your code actually calls.
• Policies and gates are evaluated in the platform, with actions such as block, warn, notify or require approval, and a CI gate action is available. This is where the "gate at deploy, not at every merge" pattern above is implemented.
• Autonomous remediation opens fix pull requests. It ships switched off, so your team chooses which categories run on their own.
• The Safeguard CLI's assistant can edit code and run commands with your approval, and safeguard exec runs it in CI.

Where Safeguard does not help: it does not replace your source control system's access control, branch protection, review rules or signing, and it cannot tell you anything about Scion's internals that Anthropic has not published.

Common mistakes

• Calling Scion a git replacement you can adopt. It is internal, unreleased, and Anthropic says it is not suitable for general use.
• Treating community "open Scion" projects as Anthropic's. They are independent, and some say so in their own descriptions.
• Assuming a hash algorithm or signing model. The post names neither. A threat model built on a guess is worse than one that marks the gap.
• Treating sparse checkout as access control. Git's documentation describes it as a working tree feature. History still contains every path.
• Relying on client side hooks for policy. They can be skipped; server side receive hooks cannot.
• Building a serial gate for agent scale merge rates. At 30,000 merges a day, a one minute serial check clears fewer than 1,500.
• Forgetting the mirrors. Every mirror is another copy of the source with its own access list.

Fix it without waiting for upstream

Whatever system holds your source, most known vulnerabilities live in the dependencies inside it, and at agent scale merge rates fixes cannot wait on a person.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

What is Anthropic Scion?

Anthropic's in house version control system for its monorepo, described in an engineering post on 13 October 2026. The server owns history, merges and rebases.

Is Scion open source or available to download?

No. It is internal and unreleased, and Anthropic says it is not a suitable general git replacement. Public projects using the name are not Anthropic's.

Why did Anthropic replace git?

Per Anthropic, daily merges grew from about 2,500 (May 2026) to more than 30,000 (September 2026), CI ran about 25 million checkouts a day, and several hundred mirrors were needed. Git's offline design did not match always online clients.

Is Scion based on Mononoke or Sapling?

Anthropic's post names Google's Piper and Meta's Sapling as prior art, and its 15 October update credits Sapling's server, Mononoke, with pioneering many techniques Scion uses, in particular the Bonsai data model.

What hash function does Scion use?

Anthropic has not said. The post calls the data content addressed and immutable but names no algorithm.

Does Scion sign commits?

The post does not describe signing, encryption, audit logs or provenance attestations. That does not mean Scion lacks them; it means the public description does not cover them.

Does Scion support per directory permissions?

Yes, according to Anthropic, along with rich repository access control. The implementation is not described.

How should a security team handle 30,000 merges a day?

Avoid a serial gate on every merge. Scope checks to dependency file changes, scan fully on a schedule, block at deploy, and automate fix pull requests under policy.

See how Safeguard would help

None of these demos involves Scion; they work on git repositories and their dependency files.

This demo shows a real Safeguard CLI session. You ask it to fix the lodash CVE in a repository; it reads the finding and advisory, asks before each command, updates package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. At agent scale merge rates, this is the shape of an automated fix that a person still controls.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with a device code, and then scans from the terminal. It is the same scan you would point at a sparse checkout or a single service directory to keep per merge cost low.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Teams running coding agents at high merge rates can give an agent read access to findings while keeping the decision about what it may change with a person.

Click through it at your own pace, or open it full screen.

You can download the Safeguard apps and CLI or read the CLI documentation. Related: git permissions for a cloud coding agent and sharding scans of a large monorepo.

Quick check

Sources

• Anthropic Engineering: Redesigning source control at Anthropic (13 Oct 2026, updated 15 Oct 2026)
• Sapling: Mononoke README
• Git documentation: hash function transition
• Git documentation: breaking changes for Git 3.0
• Git documentation: partial clone
• Git documentation: git sparse-checkout
• Git documentation: gitnamespaces
• Git documentation: githooks
• Pro Git: Signing your work
• Version Control with Subversion 1.7: path based authorization
• SLSA 1.2: source track requirements
• Google Research: Why Google stores billions of lines of code in a single repository (CACM, 2016)
• Safeguard: Sparse checkout is not access control

Last reviewed: 23 October 2026. Scion is internal to Anthropic; check Anthropic's engineering post for any updates.