for agents/llms.txtv0.12.65

Home / Articles / Handing secrets to agents and browsers / Versions / v1.1.0

Handing secrets to agents and browsers: what changed in v1.1.0

From v1.0.0 (2026-10-15, af647d064) to v1.1.0 (2026-10-15, this release), paragraph by paragraph.

1 paragraph added, 0 removed, 2 changed in place, 42 unchanged. About 73 words added and 0 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.

all versions

16 unchanged paragraphs, under In short {#in-short}, The pain {#pain}, What SG/Send already has {#backend}

It also has a friendly mode, where two words and four digits derive both the key and the transfer id. The word list has 320 words, so a code is one of about a billion, roughly 30 bits, stretched with PBKDF2 at 600,000 iterations. That is fine for a single download that expires in minutes, where every guess has to go through the server. It is not enough tofor protectanything. aThe keysgit team's security review of 6 August found that lasts,the ifpublic id is an unsalted hash of the code, so anyone everwho getssees the ciphertext.id can recover the code offline, and that the fixed salt lets one precomputed table open every such transfer; the command line stopped creating them in June. And sgit already has public-key cryptography: sgit pki keygen makes an RSA-OAEP 4096 key for encryption and an ECDSA P-256 key for signing, and encrypt and decrypt do the rest.

17 unchanged paragraphs, under The design: the recipient makes the key {#design}, Tested end to end {#test}, The first secret {#first}…

1. One site, one job. A separate site, built on SG/Send's transfer API, for handing secrets and public keys to agents and browsers. 2. Client first. All cryptography in the browser or the command line; a JavaScript library and the sgit command line share one format. 3. Recipients make keys. A browser makes a non-extractable key pair; an agent session runs one command; both show the public half as a QR code, a link and text. 4. Owners encrypt and sign. The page that sends shows the recipient's fingerprint, encrypts, signs, and creates a transfer with one download, deletion and a short expiry. 5. Receive into the tool. One command downloads, verifies the owner's signature against a pinned key, decrypts and pipes into sgit clone -; nothing is printed. 6. Pairing for new sessions. A session that has no key yet shows a fingerprint and a QR code; the owner approves it from a phone. 7. No passphrase prompt for agents. A documented way to give the private key's protection from the environment, and a test that it never reaches a log. 8. ShortNo codesshort stay short-lived.codes. The friendly code is retired; a short code is only safe inside a key exchange built for singleit, downloadsas thatMagic expireWormhole in minutes.does. 9. Location limits, if wanted. New work in the back end, not something it has today.

6 unchanged paragraphs, under What this does not claim {#limits}

• Corrected on 15 October. The first version said the friendly code was fine for a single download that expires in minutes; the sgit security review shows the code can be recovered offline from the public id, so it is not.

3 unchanged paragraphs, under Where this comes from {#sources}

all versions