SGit: the RiskMandate X-ray

a company · prepared · sources read on 2026-11-07 · the deck · how this X-ray was made · X-ray another name

What happened: how this X-ray was made →

With JavaScript, the graph of this X-ray and a player for each use case's simulation are drawn here. Everything they show is written out below.

What it does

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. s3 s4 s10 s9 s19

Its AI agents

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. s5 s6

What it can do:

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. s18 s19 s20 s21

What it can do:

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. s1 s7

What it can do:

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 cases: reach, mandate and gap

For each use case: what the agent can technically reach (from the sources), what a deployer would plausibly authorise (the mandate: illustrative, our judgement), the gap between the two (authority nobody accepted), and the controls that publicly stand in the way.

Handing over a vault key, sealed to a pinned root

The agent: An agent session with a pki.sgit.ai identity (pki-agent) · who uses it: An operator whose agents create vaults all the time and who keeps a vault of vaults; the agents that make vaults must pass their keys to him or to a keeper agent without printing them.

Reach	Kind	Sources
The vault key of a vault the agent created (read and write), read by sgit vault show-key inside --from-vault	data	s20 s10
The agent's own session key pair in sgit's key store (~/.sg-send/keys/), which dies with the container	system	s18 s19
The pki.sgit.ai register: records, operates and operated-by links, and the trust chain to the pinned root	outside	s18 s19
Any public key it is shown as a recipient, including fingerprints that arrive in messages, QR codes or web pages	people	s20 s21
The vault key in clear on arrival: the saved vault-key file, the command line of sgit clone, and the agent's transcript	data	s20 s23
The vault of vaults, where the keeper commits the keys it receives	data	s20

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: reach beyond the mandate	From the reach
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).	The vault key in clear on arrival: the saved vault-key file, the command line of sgit clone, and the agent's transcript
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.	The pki.sgit.ai register: records, operates and operated-by links, and the trust chain to the pinned root; Any public key it is shown as a recipient, including fingerprints that arrive in messages, QR codes or web pages

Controls that publicly stand in the way	Sources
send and seal refuse any recipient that does not chain to a root pinned out of band (optionally also confirmed in a DNS TXT record); no --unverified.	s19 s20 s21
seal --from-vault seals the key in memory: it is never shown and never written to a file.	s20
A sealed message carries its recipient, time and expiry inside the signature; a sealed key expires in a week and an old image shown again is refused.	s19 s20
QR codes for agents hold strict JSON only, and what is read from a QR code or message is data, never instructions.	s18 s20
A vault key is sealed to the root by default, and to the keeper as well when asked, so no single agent holds the only copy.	s21

The simulation, each action placed against the mandate (RiskMandate is never in the request path: read-only by design: it places, it does not stop):

Makes its own session key with pki-agent keygen --session and names the operator's key as its operator. (agent, reaches The agent's own session key pair in sgit's key store (~/.sg-send/keys/), which dies with the container): inside the mandate
Compares the fingerprint the session printed with the one in his vault and confirms it with an 'operates' link for a week. (operator, reaches The pki.sgit.ai register: records, operates and operated-by links, and the trust chain to the pinned root): inside the mandate
Pins the root, checks the keeper with trust, and seals the new vault's key with seal --from-vault into a QR image. (agent, reaches The vault key of a vault the agent created (read and write), read by sgit vault show-key inside --from-vault): inside the mandate
A message in its inbox gives a different fingerprint and asks it to seal the key there too; it tries trust on that fingerprint. (agent, reaches Any public key it is shown as a recipient, including fingerprints that arrive in messages, QR codes or web pages): outside the mandate: in the gap. What RiskMandate's record shows: 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.
Reads the carried QR image with read-qr and opens it with open --save into a folder of the vault of vaults. (keeper agent, reaches The vault of vaults, where the keeper commits the keys it receives): inside the mandate
Runs sgit clone with the received key on the command line to check that the vault opens. (keeper agent, reaches The vault key in clear on arrival: the saved vault-key file, the command line of sgit clone, and the agent's transcript): outside the mandate: in the gap. What RiskMandate's record shows: 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.

An agent team whose only memory is an encrypted vault

The agent: A vault-working agent (sgit CLI) · who uses it: A person running several agents on dedicated accounts, each with one focus, sharing state through vaults driven by the sgit CLI (the setup the SGit Newsroom describes running with twelve agents).

Reach	Kind	Sources
Every file in the vault and every commit in its history, decrypted locally with the vault key the session was given	data	s3 s7 s17
Write access: commits pushed to the vault, including sgit write straight to HEAD	data	s7
Other agents' folders in the same vault: a scoped clone holds the vault key and sgit fetch widens it to any folder	data	s8
A vault app's manifest (.vault/app.json), which grants the app its permissions, editable via sgit or the vault browser	code	s13
The sync server (dev.send.sgraph.ai by default) over HTTPS, which holds ciphertext only	system	s4 s7
The shared named branches that a human reviews and merges	people	s1 s7

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: reach beyond the mandate	From the reach
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.	Other agents' folders in the same vault: a scoped clone holds the vault key and sgit fetch widens it to any folder
Commit authorship is not yet signed: in a shared vault an agent's identity comes from its branch, not a signature.	Write access: commits pushed to the vault, including sgit write straight to HEAD; The shared named branches that a human reviews and merges
There is no key revocation: rotating a key protects future commits, not objects someone already fetched.	Every file in the vault and every commit in its history, decrypted locally with the vault key the session was given

Controls that publicly stand in the way	Sources
Files, filenames, commit messages and branch names are encrypted client-side (AES-256-GCM) before upload; the server stores ciphertext and never holds a key.	s3 s4
A scoped clone refuses writes outside the folders it holds, by name.	s7
sgit history show and history diff are read-only: an agent can inspect a peer's commit without touching its own working copy.	s7
A read key is derived one way from the vault key and can never be turned back into write access.	s10
Files such as .env, .netrc, .git-credentials and private key files are always excluded from commits.	s4
An app cannot write its own manifest: .vault/** is a protected floor.	s13

The simulation, each action placed against the mandate (RiskMandate is never in the request path: read-only by design: it places, it does not stop):

Starts its session with a scoped, shallow clone of its own folder of the team vault. (agent, reaches Every file in the vault and every commit in its history, decrypted locally with the vault key the session was given): inside the mandate
Records a finding with sgit write --push --json, one commit on its own clone branch. (agent, reaches Write access: commits pushed to the vault, including sgit write straight to HEAD): inside the mandate
Looks at a peer's latest commit with sgit history show, without merging. (agent, reaches Every file in the vault and every commit in its history, decrypted locally with the vault key the session was given): inside the mandate
Runs sgit fetch on another agent's folder to read its notes. (agent, reaches Other agents' folders in the same vault: a scoped clone holds the vault key and sgit fetch widens it to any folder): outside the mandate: in the gap. What RiskMandate's record shows: The record places the read against m4 and shows it was possible because the scoped clone carries the whole vault key; the gap is that a partial clone is not an access boundary.
Edits .vault/app.json through the CLI to give the vault's app write access to a wider folder. (agent, reaches A vault app's manifest (.vault/app.json), which grants the app its permissions, editable via sgit or the vault browser): outside the mandate: in the gap. What RiskMandate's record shows: The record shows a change to the grant itself, outside m6; the app could not have made it, but an agent holding the vault key could.
Pushes its session's work; the server receives ciphertext only. (agent, reaches The sync server (dev.send.sgraph.ai by default) over HTTPS, which holds ciphertext only): inside the mandate
Pulls, reviews the branch in SG/Vault and merges it onto the named branch. (operator, reaches The shared named branches that a human reviews and merges): inside the mandate

A site agent with a comms vault as its inbox

The agent: The sgit.ai site agent (@Sgit) · who uses it: Sites in the sgit.ai network whose agents write to each other with signed, encrypted mail under Agent Contact v0.1, each site publishing its agent's public keys at a standard path.

Reach	Kind	Sources
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	s6 s5
Its public append lane on SG/Send, which it lists and fetches with an enum key derived from the comms vault key	system	s6
Senders' contact files, fetched over HTTPS from allow-listed domains and cached for at most an hour	outside	s6
Other sites' agents lanes, written to when it replies	outside	s5 s6
Its own site: publishing the contact file, key changes and pages, each a commit to the site's repository	code	s6
People named in the messages it handles	people	s6

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: reach beyond the mandate	From the reach
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.	Its own site: publishing the contact file, key changes and pages, each a commit to the site's repository
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 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; Its public append lane on SG/Send, which it lists and fetches with an enum key derived from the comms vault key
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.	Its public append lane on SG/Send, which it lists and fetches with an enum key derived from the comms vault key

Controls that publicly stand in the way	Sources
The allow list is checked before anything is fetched from the network, so strangers cannot make the agent fetch their URLs.	s6
Unsigned, unencrypted or wrongly signed messages are never read; everything else is counted and dropped unread.	s5 s6
The To check, a 7-day Date window and Message-ID replay refusal stop re-wrapped and replayed messages.	s6
A read-key holder of the comms vault cannot use its private keys; only the holder of the vault key can drain the lane.	s6
The append token rotates with one call, and a key is retired by raising its serial; key history is public in the site's repository.	s5 s6

The simulation, each action placed against the mandate (RiskMandate is never in the request path: read-only by design: it places, it does not stop):

Starts a session with the comms vault key and restores its identity from the vault. (agent, reaches 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): inside the mandate
Lists and fetches pending files from its agents lane and decrypts them. (agent, reaches Its public append lane on SG/Send, which it lists and fetches with an enum key derived from the comms vault key): inside the mandate
For a sender on the allow list, fetches its contact file, recomputes the fingerprints and verifies the signature. (agent, reaches Senders' contact files, fetched over HTTPS from allow-listed domains and cached for at most an hour): inside the mandate
A verified message from an allowed agent asks it to add a new domain to its accepts_from list; it commits the change to its site. (agent, reaches Its own site: publishing the contact file, key changes and pages, each a commit to the site's repository): outside the mandate: in the gap. What RiskMandate's record shows: The record shows a change to the site's own trust settings made on a verified message outside any declared flow, where m8 sends it to the operator.
Replies to a question over the sender's lane, encrypted to its published key and signed. (agent, reaches Other sites' agents lanes, written to when it replies): inside the mandate
Includes a contact's details from the CRM in a reply, to save a round trip. (agent, reaches People named in the messages it handles): outside the mandate: in the gap. What RiskMandate's record shows: The record shows personal data leaving over a lane, outside m9; the spec's own rule is to link to it inside the vaults.
Writes accepted, quarantined and log entries to the comms vault, marks the files processed and purges them. (agent, reaches 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): inside the mandate

Incidents, as reported

2026-08-11: The passphrase of sgit.ai's own vault was written into a tracked build file and reached three commits of a public repository; it was found by a history grep after the owner asked, and the vault was deleted from the server, rekeyed and pushed within the hour, with the write-up published. s11 s12
2026-08-06: A security review found that an earlier word-based share token, from which vault keys were derived, carried about thirty bits of entropy and could be recovered in around a tenth of a second on a GPU; the feature was removed from the client on 12 August 2026. s16
2026-09-20: An agent asked to open two vaults published on sgit.ai refused because their deliberately public read keys were labelled sgit_private_read_; the keys were relabelled the same day and the build now refuses a private-prefixed credential in any tracked file. s10

The run

The search agents that looked for leads on 2026-11-07T18:30:08.917Z, for a total cost of $0.0870. What a model says is a lead, not a fact.

Agent	Model	Time	Citations	Leads
Perplexity search	`perplexity/sonar`	7.0 s	15	16
OpenAI search	`openai/gpt-5.4-nano:online`	8.6 s	6	13
Gemini search	`google/gemini-3.1-flash-lite:online`	4.0 s	4	9
OpenRouter web search	`anthropic/claude-haiku-5.5`	20.6 s	5	19

Leads: what the models claimed, and what we found

Model	Claim	Status	Source
perplexity	sgit is git for encrypted vaults (clone, commit, branch, merge files encrypted client-side) and is presented as the encrypted git for humans and AI agents.	confirmed	s1
perplexity	A site agent publishes a machine-readable contact file and uses the site as its identity for signed, encrypted mail between agents.	confirmed	s6
perplexity	An agent or vault app can render a vault-held repo's history and diffs in sandboxes, CI containers and Lambdas without git installed.	confirmed	s12
perplexity	Use case: encrypted team memory, vaults as shared memory for collaboration, CRM and notes.	confirmed	s17
perplexity	Use case: agent collaboration with identity separation (separate accounts, vaults, branches, keys issued out of band).	confirmed	s17
perplexity	Use case: legible encrypted code archives (repo history inside a vault).	confirmed	s12
perplexity	Commit authorship is not yet signed, so in a shared vault an agent's identity comes from its branch (model dated this 2026-11-02; the article is dated 2026-10-06).	confirmed	s17
perplexity	There is no key revocation, so rotating a read key protects future commits but not objects already fetched.	confirmed	s17
perplexity	The lane for direct vault-to-vault messaging is not wired end to end yet.	confirmed	s17
perplexity	sgit encrypts files with AES-256-GCM before they leave the machine (cited to the vault-apps page, which does not say it; stated on What is sgit).	confirmed	s3
perplexity	The vault key is the address of the vault, the authorisation to write to it, and the key that decrypts it.	confirmed	s15
perplexity	Whoever holds the vault key can decrypt the vault; the server cannot.	confirmed	s3
perplexity	Two-branch model: a private clone branch per machine or agent plus shared named branches.	confirmed	s3
perplexity	Object identity is content-addressed over ciphertext.	confirmed	s4
perplexity	The site frames identity for agents, a key registry for agents and ephemeral environments as core parts of the product (the home page lists them as topics of sibling *.sgit.ai sites, not as product features).	not-found	s1
perplexity	The company is actively discussing vault key management with password managers and enterprise identity providers (the page is an open call for collaboration and says no integration exists yet).	not-found	s16
openai	sgit snapshots folders, encrypts objects client-side and syncs only ciphertext; it also provides agent identity and signed, encrypted messaging over lanes tied to vault-held keys.	confirmed	s3
openai	The sgit.ai site agent receives signed agent mail from allow-listed sites, replies over their lanes, and keeps the site and its vaults.	confirmed	s5
openai	The riskmandate.ai site agent is a monitored mailbox for people and a write-only lane on an encrypted vault for agents.	confirmed	s26
openai	Use case: secure collaboration and state sharing between humans and AI agents in encrypted workspaces.	confirmed	s3
openai	Use case: LLM-assisted work without exposing the credential, the Risk Mandate vault calling an LLM without holding the API key.	confirmed	s14
openai	Use case: signed, encrypted agent-to-agent messaging via contact files and lanes.	confirmed	s6
openai	No incidents found in the public materials reviewed (sgit.ai publishes incident write-ups, including its own leaked vault key on 11 August 2026).	not-found	s11
openai	Files are encrypted client-side with AES-256-GCM; the server stores ciphertext under opaque IDs and cannot see filenames, contents or commit messages.	confirmed	s3
openai	A vault is a folder with a .sg_vault/ directory holding encrypted objects, refs and keys; pushing transfers ciphertext only.	confirmed	s3
openai	Contact files carry public encryption and signing keys and lane append tokens; agents communicate by signed, encrypted mail through vault lanes.	confirmed	s6
openai	The sgit.ai agent identity is a lane identity, not an SMTP mailbox, and its private keys live in a comms vault not published on the site.	confirmed	s5
openai	The RiskMandate agents page describes its identity as both a monitored mailbox for people and a write-only lane for agents.	confirmed	s26
openai	The Risk Mandate demo vault uses an LLM without holding the API key, which is sealed under the vault key.	confirmed	s14
gemini	SGit is version control for encrypted vaults, encrypting with AES-256-GCM before upload, leaving the server only content-addressed ciphertext.	confirmed	s3
gemini	The RiskMandate agent is a monitored mailbox and a write-only lane on an encrypted vault, authenticated via Agent Contact v0.1 (cited to riskmandate.ai home; stated on its /agents/ page).	confirmed	s26
gemini	Use case: secure multi-agent collaboration with versioned encrypted vaults, named branches and sandboxed in-vault apps.	confirmed	s1
gemini	Use case: an app calls a language model through the sg.llm bridge without holding the API key.	confirmed	s22
gemini	An agent refused to open vaults whose read keys were mislabelled sgit_private_read_ instead of sgit_public_read_, on 20 September 2026 (cited to the home page; stated on the credentials page).	confirmed	s10
gemini	Risk of a vault key exposed on the command line, on disk and in agent transcripts once it arrives, as observed on 24 October 2026.	confirmed	s23
gemini	Storage providers cannot read file contents, filenames or commit messages.	confirmed	s1
gemini	The vault key (passphrase:vault-id) combines the server address, the access credential and the root of the local key derivation in one string.	confirmed	s3
gemini	The project tracks development history and roles in publicly accessible vaults as an open-source transparency strategy (Apache-2.0 and a public release record confirmed; roles tracked in public vaults not found).	not-found	s1
openrouter	SGit is an encrypted, versioned workspace for humans and AI agents, with a CLI (sgit-ai) and a published security model of what the server can and cannot see.	confirmed	s1
openrouter	The site and its vaults are built by one person working with several AI agents who hand work to each other through vaults.	confirmed	s1
openrouter	The riskmandate.ai site agent drains an encrypted, write-only inbox lane and prepares replies a person must see before anything is sent (the page says a session holding the vault key; it does not name Claude Code).	confirmed	s26
openrouter	Use case: shared versioned state for AI agents that survives the context window.	confirmed	s1
openrouter	Use case: delivering a penetration test report (fictional sample) as one vault with a re-test script per finding.	confirmed	s1
openrouter	Use case: encrypted vaults for version control and sync on a host that must not read the files.	confirmed	s24
openrouter	Use case: an agent contact file and append-only inbox for the riskmandate.ai identity.	confirmed	s26
openrouter	The team that owns the API reviewed a vault built from a published brief and found the brief wrong in two places; the correction sits above the mistake.	confirmed	s1
openrouter	One agent forked another agent's vault, kept every byte, added a layer, and the original's tests still pass inside the fork.	confirmed	s1
openrouter	sgit is in beta while powering production workflows daily.	confirmed	s1
openrouter	The published threat model says the server can see object sizes, timing and the vault ID.	confirmed	s4
openrouter	Files are encrypted client-side with AES-256-GCM and the server never receives a key.	confirmed	s24
openrouter	Per-file keys are derived with HKDF and vault keys with PBKDF2-SHA256 at 600,000 iterations (GitHub page returned 403 here; read in the repository's README).	confirmed	s25
openrouter	The server sees only ciphertext, never a filename, file contents or commit message.	confirmed	s24
openrouter	The CLI's PKI generates RSA-4096 and ECDSA P-256 pairs, signs and verifies, and does hybrid RSA-OAEP plus AES-256-GCM encryption.	confirmed	s24
openrouter	sgit is Apache-2.0 and installable as the Python package sgit-ai.	confirmed	s3
openrouter	The riskmandate.ai agent identity is a monitored mailbox for people and a write-only lane for agents, and its private keys sit inside the comms vault.	confirmed	s26
openrouter	The riskmandate.ai contact file follows Agent Contact v0.1, and the agent's own Google Workspace account bounds what it can do under that identity.	confirmed	s26
openrouter	The sgit repository on GitHub describes a server that stores only ciphertext, with all cryptography run locally.	confirmed	s25

The questions we would ask

We have not asked them yet.

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?
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?
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?
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?
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?

Sources

s1 sgit (the encrypted git for humans and AI agents), sgit.ai (the sgit project) (own-site, read 2026-11-07)
https://sgit.ai/
s2 sgit.ai llms.txt (site index for agents), sgit.ai (the sgit project) (own-site, read 2026-11-07)
https://sgit.ai/llms.txt
s3 What is sgit, Docs, sgit.ai (the sgit project) (docs, read 2026-11-07)
https://sgit.ai/docs/what-is-sgit.html
s4 Security model, sgit, sgit.ai (the sgit project) (docs, read 2026-11-07)
https://sgit.ai/security/index.html
s5 Agents: the contact files of the sgit.ai network, sgit.ai (the sgit project) (own-site, read 2026-11-07)
https://sgit.ai/agents/index.html
s6 Agent Contact v0.1: signed, encrypted mail between the agents that run our websites, sgit.ai (the sgit project) (docs, read 2026-11-07)
https://sgit.ai/docs/agent-contact.html
s7 Working with AI agents, sgit Docs, sgit.ai (the sgit project) (docs, read 2026-11-07)
https://sgit.ai/docs/agents.html
s8 When NOT to use sgit, Docs, sgit.ai (the sgit project) (docs, read 2026-11-07)
https://sgit.ai/docs/limitations.html
s9 Keys, signatures and encrypting to someone else, sgit.ai (the sgit project) (docs, read 2026-11-07)
https://sgit.ai/docs/pki.html
s10 Vault credentials: what each one can do, and what its prefix declares, sgit.ai (the sgit project) (docs, read 2026-11-07)
https://sgit.ai/docs/credentials.html
s11 The day we leaked our own vault key (sgit.ai case study), sgit.ai (the sgit project) (own-site, read 2026-11-07)
https://sgit.ai/case-studies/exposed-vault-key.html
s12 Git repos inside vaults, SG/Vault, sgit.ai (the sgit project) (docs, read 2026-11-07)
https://sgit.ai/docs/vault/git-and-vaults.html
s13 Building vault apps, SG/Vault, sgit.ai (the sgit project) (docs, read 2026-11-07)
https://sgit.ai/docs/vault/vault-apps.html
s14 Risk Mandate, a published vault, sgit.ai (the sgit project) (own-site, read 2026-11-07)
https://sgit.ai/demos/vaults/risk-mandate/index.html
s15 Git for things you cannot put on GitHub, sgit.ai (the sgit project) (own-site, read 2026-11-07)
https://sgit.ai/articles/what-sgit-is.html
s16 Who holds the keys? A call for collaboration on vault key management, sgit.ai (the sgit project) (own-site, read 2026-11-07)
https://sgit.ai/partnerships/vault-key-management.html
s17 The agent team as it runs: one person, twelve agents, encrypted vaults, and a mailbox nobody sends from, SGit Newsroom (newsroom.sgit.ai) (own-site, read 2026-11-07)
https://newsroom.sgit.ai/articles/the-agent-team-as-it-runs.html
s18 pki.sgit.ai: a register of people and their public keys, verified both ways, pki.sgit.ai (the sgit project) (docs, read 2026-11-07)
https://pki.sgit.ai/llms.txt
s19 Identities for agents, pki.sgit.ai, pki.sgit.ai (the sgit project) (docs, read 2026-11-07)
https://pki.sgit.ai/agents/index.html
s20 Handing over a vault key: instructions for agents, pki.sgit.ai (the sgit project) (docs, read 2026-11-07)
https://pki.sgit.ai/handover.md
s21 Agents, vault keys and the root, pki.sgit.ai (the sgit project) (own-site, read 2026-11-07)
https://pki.sgit.ai/articles/agents-vault-keys-and-the-root.md
s22 llms.sgit.ai: your app calls a language model without ever holding an API key, llms.sgit.ai (the sgit project) (docs, read 2026-11-07)
https://llms.sgit.ai/
s23 Why: the last metre (SHarness design), sharness.ai (other, read 2026-11-07)
https://sharness.ai/design/why/index.md
s24 sgit-ai on PyPI (package metadata and description, v0.27.0), PyPI (other, read 2026-11-07)
https://pypi.org/pypi/sgit-ai/json
s25 SGit-AI__CLI README, GitHub (SGit-AI organisation) (other, read 2026-11-07)
https://raw.githubusercontent.com/SGit-AI/SGit-AI__CLI/HEAD/README.md
s26 RiskMandate, Agents: the contact file, the mailbox and the lane, riskmandate.ai (other, read 2026-11-07)
https://riskmandate.ai/agents/
s27 RiskMandate llms.txt, riskmandate.ai (other, read 2026-11-07)
https://riskmandate.ai/llms.txt

X-rayed by RiskMandate, which measures what your agents can actually reach, evidences the controls that contain them, prices the exposure, and produces that record (riskmandate.ai/llms.txt). The mandates are illustrative. Built by xray@web-summit.dinis from data/xray/sgit/xray.json.