Skip to content

Anthropic built Scion for itself. Carbon Forge is yours →

Carbon Forge
Menu

Security

A history you can verify, and reach you can name.

Every byte is named by its hash. Every revision is sealed to the one before it. Every token holds a declared list of tools, and an agent’s run holds one lane and one path. Nothing is trusted because it says so.

SPECIFICATION · CHAPTER 2

The seal

  • Every revision of a page, an atom or a code tree is sealed as it is written, and each seal names the one before.

    Carbon Forge docs
  • With a signing key, each seal is also signed with Ed25519, and public keys are kept so a seal still verifies after a key rotates.

    Carbon Forge docs
  • chain.verify checks that a page’s, an atom’s or a code tree’s revision history is intact, or that one changeset’s link over its members is.

    Carbon Forge docs
  • History only moves forward: a revert is a new landing, and a cut names a sealed snapshot that never moves.

    Carbon Forge docs
Chapter 2 of the specification

SPECIFICATION · CHAPTER 8

Tokens and reach

  • Every token is scoped by a preset or a custom tool list; the role is always the upper bound.

    Carbon Forge docs
  • An execution token writes only to its lane and under its tree path; every widening is refused and nothing is minted.

    Carbon Forge docs
  • An execution token is a short-lived child token minted for a single AEGIS run: its writes are held to one lane and one tree path, and it lives at most one day.

    Carbon Forge docs
Chapter 8 of the specification

With AEGIS, agents never hold credentials

Agents never hold credentials: the orchestrator resolves secrets and enforces policy rules on every tool call, proxied through Ed25519-signed envelopes.

AEGIS docs