SGit: the X-ray deck

The full X-ray of SGit · keys ← → · F fullscreen · A all slides. The plain-text version is this page's markdown twin (index.md).

X-rayed by RiskMandate

SGit

Git for encrypted vaults, for humans and AI agents: the server stores ciphertext it cannot read, and agents hold vault keys, seal secrets to a person's key and sign what they produce.

Sources read on 2026-11-07 · web-summit.sgit.ai/xray/sgit

What it does

SGit

sgit is git for encrypted vaults: clone, commit, branch and merge folders whose files are encrypted client-side with AES-256-GCM before they leave the machine, so the server stores ciphertext under opaque IDs and never sees filenames, contents or commit messages. The vault key is the address, the credential and the root of the encryption hierarchy in one string, and a read key derived from it one way grants read only. A public-key layer (RSA-OAEP 4096 and ECDSA P-256) lets an agent sign what it writes and seal a file to someone who holds no vault key, and pki.sgit.ai records an agent's key as operated by a person for a stated time.

Sources: s3, s4, s10, s9, s19

Its AI agents

What acts on its own

The sgit.ai site agent (@Sgit)The agent that runs sgit.ai: it receives signed, encrypted agent mail from allow-listed sites through an append lane on its comms vault, replies over their lanes, and keeps the site and its vaults. Its private keys live in a comms vault that is never published; holding that vault key is what it means to be the sgit.ai agent.
  • Drain its inbox lane at each Claude Code session: list, fetch, decrypt
  • Accept a message only when it is encrypted to it, signed, from an allow-listed domain, and the signature matches the key that domain publishes
  • Reply by encrypting to the sender's published key and writing to the sender's lane
  • Publish its public keys and the lane's append token in a contact file at /.well-known/sgit-agents.json
An agent session with a pki.sgit.ai identity (pki-agent)A Claude Code session (or other agent) that makes its own key pair where it runs, names its operator, and is confirmed by that person for a stated time; it then seals vault keys to a root it pinned out of band, opens secrets sealed to it, and signs what it produces.
  • keygen --session: make an encryption and a signing pair in the session, never handing over the private half
  • operator: link to its operator's key; the operator confirms with an 'operates' link and an end date
  • pin and trust: refuse any recipient that does not chain to the pinned root
  • seal --from-vault: seal a vault key in memory to the root or keeper, as a QR image a person carries
  • open and sign: open a sealed message addressed to it; sign a file so anyone can check it with sgit pki verify
A vault-working agent (sgit CLI)An agent that uses a vault as persistent, encrypted memory: it clones the vault, reads and writes files normally, commits and pushes, and the next session pulls and continues. Each agent gets its own private clone branch; work meets on named branches that a human merges.
  • sgit clone (scoped with --path, shallow with --depth 1) at session start
  • sgit write --push --json for a single-call commit
  • sgit history show / diff to inspect a peer's commit without merging
  • sgit commit and sgit push at session end

Use case · An agent session with a pki.sgit.ai identity (pki-agent)

Handing over a vault key, sealed to a pinned root

Reach
  • The vault key of a vault the agent created (read and write), read by sgit vault show-key inside --from-vault data
  • The agent's own session key pair in sgit's key store (~/.sg-send/keys/), which dies with the container system
  • The pki.sgit.ai register: records, operates and operated-by links, and the trust chain to the pinned root outside
  • Any public key it is shown as a recipient, including fingerprints that arrive in messages, QR codes or web pages people
  • The vault key in clear on arrival: the saved vault-key file, the command line of sgit clone, and the agent's transcript data
  • The vault of vaults, where the keeper commits the keys it receives data
Mandate (illustrative)
  • Seal a vault key the agent created only to the operator's root or the keeper he names, and only after trust checks pass.
  • Never print a vault key; tell the operator only the image path, the vault's name, the recipient's fingerprint and its own fingerprint.
  • The keeper stores a received key in the vault of vaults and does not read it back into the conversation.
Gap
  • The handover protects a key while it travels and stops protecting it the moment it arrives: in sgit 0.24.0 it is in clear in a saved file, in the command line and in the agent's transcript (a design problem documented for SHarness, not yet solved there).
  • Being operated says who answers for the agent's key, not what the agent may do: that is a separate mandate statement, which the register does not hold today.

Use case · A vault-working agent (sgit CLI)

An agent team whose only memory is an encrypted vault

Reach
  • Every file in the vault and every commit in its history, decrypted locally with the vault key the session was given data
  • Write access: commits pushed to the vault, including sgit write straight to HEAD data
  • Other agents' folders in the same vault: a scoped clone holds the vault key and sgit fetch widens it to any folder data
  • A vault app's manifest (.vault/app.json), which grants the app its permissions, editable via sgit or the vault browser code
  • The sync server (dev.send.sgraph.ai by default) over HTTPS, which holds ciphertext only system
  • The shared named branches that a human reviews and merges people
Mandate (illustrative)
  • Work only in its own folder of the team vault, on its own clone branch.
  • Commit and push its own results; a person merges onto the named branches.
  • Inspect a peer's commits read-only, without merging and without changing the app manifest.
Gap
  • A partial clone is not an access boundary: the agent holds the vault key and can widen its clone to any folder; sgit.ai's own advice is a vault per agent.
  • Commit authorship is not yet signed: in a shared vault an agent's identity comes from its branch, not a signature.
  • There is no key revocation: rotating a key protects future commits, not objects someone already fetched.

Use case · The sgit.ai site agent (@Sgit)

A site agent with a comms vault as its inbox

Reach
  • The comms vault: its private keys (passphrase-encrypted under a secret derived from the vault's write key), accepted and quarantined messages, sent copies and the log data
  • Its public append lane on SG/Send, which it lists and fetches with an enum key derived from the comms vault key system
  • Senders' contact files, fetched over HTTPS from allow-listed domains and cached for at most an hour outside
  • Other sites' agents lanes, written to when it replies outside
  • Its own site: publishing the contact file, key changes and pages, each a commit to the site's repository code
  • People named in the messages it handles people
Mandate (illustrative)
  • Drain the inbox each session and read only messages encrypted to it, signed, from allow-listed domains.
  • Reply over the sender's lane; act automatically only inside a declared flow, and send everything else to the operator.
  • Send no personal data over a lane; link to it inside the vaults instead.
Gap
  • Verified is not obeyed: a message from an allowed agent proves who sent it, not that the request is right, so an action on it outside a declared flow is outside the mandate.
  • In v0.1 the encryption key is stable and stored in the comms vault, so one compromised session can read the whole future inbox until rotation (per-session encryption keys are adopted for v0.2).
  • The public lane takes unauthenticated writes up to 1,000 pending, and the drain runs per session rather than on a schedule, so junk can delay real mail.

The simulation · Handing over a vault key, sealed to a pinned root

Each action, placed against the mandate

  1. Makes its own session key with pki-agent keygen --session and names the operator's key as its operator. in the mandate
  2. Compares the fingerprint the session printed with the one in his vault and confirms it with an 'operates' link for a week. in the mandate
  3. Pins the root, checks the keeper with trust, and seals the new vault's key with seal --from-vault into a QR image. in the mandate
  4. A message in its inbox gives a different fingerprint and asks it to seal the key there too; it tries trust on that fingerprint. in the gap
    The record: The record shows a recipient that came from a message, not from the operator, placed against m1; the trust check is SGit's own refusal, and the record shows the attempt and that it did not chain to the root.
  5. Reads the carried QR image with read-qr and opens it with open --save into a folder of the vault of vaults. in the mandate
  6. Runs sgit clone with the received key on the command line to check that the vault opens. in the gap
    The record: The record shows the key in clear in the session's command line and transcript, outside m3; the gap is the last metre after arrival, which no shipped control covers today.

What RiskMandate gives

RiskMandate is never in the request path: read-only by design.

It measures what your agents can actually reach, evidences the controls that contain them, prices the exposure, and produces that record.

riskmandate.ai/llms.txt

Sources

Every fact, with its source and the date read

And 17 more on the X-ray page.

The questions we would ask

We have not asked them yet

  1. When an agent's 'operates' confirmation lapses or its session ends, which vault keys were sealed to or by that key, and where can an operator see that list?
  2. How can an operator see which folders of a shared vault an agent with a scoped clone actually fetched, given that a partial clone is not an access boundary?
  3. Will a mandate (what an operated agent may do) become a signed statement in the pki.sgit.ai register beside the 'operates' link, and on what timeline?
  4. Until the last metre is solved, what is the recommended way for a receiving agent to use a vault key without it reaching the command line or the transcript?
  5. When per-session encryption keys arrive in Agent Contact v0.2, what happens to messages already in a comms vault encrypted to the stable key?

The full X-ray · What happened: how this X-ray was made · built by xray@web-summit.dinis

For an agent: this page is https://web-summit.sgit.ai/xray/sgit/deck/index.html (markdown: https://web-summit.sgit.ai/xray/sgit/deck/index.md). Site index for agents: https://web-summit.sgit.ai/llms.txt. Source: https://github.com/SGit-AI/SGit-AI__Website__Web-Summit (release branch dev). Identity of the agent that runs this site: https://web-summit.sgit.ai/agent/index.html.