Vzdálené executory

Dejte agentovi skutečný počítač, na kterém bude pracovat: Linux, macOS nebo Windows.

Co je vzdálený executor

Agent v Nessie nemá počítač. Umí číst, co je v Nessie, mluvit s lidmi a přes síť volat připojené nástroje, ale nedokáže otevřít soubor na notebooku, spustit příkaz ani se podívat na stránku, která existuje jen za něčím přihlášením. Vzdálený executor je způsob, jak mu dát stroj, na kterém bude pracovat.

Executor je malý daemon, který nainstalujete na počítač, jenž máte pod kontrolou. Páruje se směrem ven s vaší instancí Nessie, prokazuje, o jaký stroj jde, pomocí klíče, který hostitele nikdy neopustí, a pak nabízí pevně daný, pojmenovaný soubor operací — nic dalšího. Práce přichází jako jednotlivé podepsané příkazy; výsledky se vracejí jako omezená, strukturovaná potvrzení. Stroj nikdy nepřijme příchozí spojení z Nessie.

Stojí za to být přesný v tom, čím executor není, protože většina nástrojů pro vzdálený přístup je některá z těchto věcí a executor je záměrně žádnou z nich. Není to SSH, není to obecný vzdálený shell, není to připojení k terminálovému multiplexeru, který už máte otevřený, není to standardní vstup na straně cloudu ani obecný proxy server do místní sítě. Není to MCP server a není to kontejner ani cloudové výpočetní prostředí — Nessie tyto věci už má a jsou to něco jiného. Executor je koncový bod nesoucí oprávnění, s uzavřeným seznamem operací, a tento seznam je jeho celý povrch.

Komu executor patří

Každý executor se vytváří s přesně jedním rozsahem a ten se později nedá změnit. Určuje, kdo ho smí vyvolat a kdo ho smí spravovat.

Soukromý executor musí mít vždy alespoň jednoho aktivního lidského správce. Přímé odebrání posledního selže; pokud by offboardingová transakce žádného nenechala, executor přestane přijímat novou práci, dokončí to, co už má, a sám se odvolá. Vlastník organizace má nouzovou cestu, která umí pouze odvolat executor, jenž jinak nespravuje, a to bez zobrazení jeho soukromého seznamu přiřazených osob, jeho relací nebo obsahu. Soukromý přístup se nikdy tiše nepředá jinému člověku.

Co s ním agent skutečně může dělat

Slovník operací je pevně daný v kódu, nekonfiguruje se pro jednotlivá nasazení. Dělí se na dvě části a to rozhoduje, co je třeba nainstalovat: některé operace daemon obsluhuje z vlastního pracovního adresáře bez jakéhokoli virtuálního stroje, zbytek potřebuje guest VM, tedy virtuální stroj pro každou relaci na hostiteli.

Operace, které nepotřebují guest VM, tvoří pracovní balík. Hostitel, který nemůže spustit guest VM, není rozbitý executor: páruje se normálně, jako sandbox backend hlásí none a nabízí pouze pracovní balík a nic dalšího. Do tohoto stavu se dostane edice Windows bez Hyper-V nebo počítač s Linuxem, jehož uživatel nemá přístup k /dev/kvm, a rozhraní to jasně pojmenuje, místo aby selhalo nepřehledně.

Práci s prohlížečem agent nikdy nespustí sám od sebe. Běžná cesta pro vazbu jedné operace výslovně odmítá browser.open a browser.observe; běh prohlížeče spustí člověk z kanálu jako jeden balík čtyř operací na novém běhu a k němu už nelze přidat žádnou další vazbu. Spravované relace kódování fungují stejně.

Existují ještě dvě skupiny, které jsou v kódu a záměrně nedostupné. Operace pro ovládání karty Chrome, do které jste už přihlášeni, mají úplnou lokální implementaci a rozšíření pro nativní zasílání zpráv (native messaging), ale řídicí vrstva je odmítá nabídnout, dokud server nedokáže prokázat, že původní konverzace byla soukromá, a zaznamenat, kdo co zveřejnil. Základ je záměrně neaktivní a rozšíření se neinstaluje v žádném z instalátorů. Několik operací pro kódování — připojení, prompt, přerušení a zavření — je uvedeno ve schématu, ale nemá implementaci, takže je nelze udělit.

Jak to funguje

Spojení je vždy odchozí

Daemon navazuje odchozí spojení HTTPS a WSS pouze k vašemu API Nessie a k ničemu jinému. Nessie nikdy nevolá na notebook, nikdy nedrží jeho adresu a nikdy nepovažuje žádný koncový bod z katalogu za přenosový kanál ke stroji. Proto executor funguje z domácí sítě, za NAT, ve firemním VPN, bez přesměrování portů a bez příchozího pravidla firewallu — a proto je zastavení daemonu úplným a okamžitým odpojením.

API musí být na HTTPS. Jedinou výjimkou je loopback adresa pro lidi, kteří provozují Nessie na vlastním počítači, a to přes vlastní proměnnou prostředí; žádný běžný přepínač nedokáže produkční adresu přepnout na prostý HTTP.

Párování ověří stroj a člověk to potvrdí

Párování je dvoustranný důkaz. Oprávněná osoba vytvoří executor v Nessie s jeho rozsahem a Nessie vydá registraci (enrolment): 256bitovou náhodnou výzvu, z níž uchovává pouze ověřovací otisk SHA-256. Výzva platí deset minut a lze ji použít jen jednou.

Daemon na stroji vygeneruje pár klíčů Ed25519, uloží jej do úložiště chráněného operačním systémem a přístupným jen vlastníkovi, a přesný podepsaný požadavek zapíše na disk dřív, než provede jakékoli síťové volání — takže ztracenou odpověď lze zopakovat se stejným připraveným klíčem a stroj se tiše nespáruje dvakrát. Pak odešle identifikátor registrace, výzvu, svůj veřejný klíč a podpis důkazu. Nessie uloží veřejný klíč a jeho otisk. Soukromý klíč nikdy neuloží.

Nessie pak ukáže tento otisk člověku, který jej potvrdí. Dokud neproběhne toto potvrzení a následný důkaz vlastnictví klíče, executor zůstává offline. Párování nelze dokončit z textu chatu ani z přepisu terminálu: vyžaduje záměrný lidský krok ve webovém nebo desktopovém rozhraní.

Stroj, který ztratí svůj klíč, nemůže obnovit svůj záznam executoru. Executor se odvolá a registruje se znovu jako nový. Naproti tomu rotace klíče je jediná transakce podepsaná starým i novým klíčem.

Descriptor je podepsané tvrzení stroje o sobě samém

Spárovaný daemon publikuje descriptor: podepsané, monotónně zvyšované tvrzení pouze o strukturálních faktech — která schémata operací podporuje, jaké má limity zdrojů a sítě, svou platformu a digest své místní politiky. Neobsahuje žádné cesty na hostiteli a v cloudu nevytváří žádné oprávnění.

Nová revize se nikdy neaktivuje hned po příchodu. Uloží se jako čekající na kontrolu a oprávněná osoba ji musí vidět a potvrdit, než může ovlivnit, co je dostupné. Právě to brání tomu, aby obnovení schopností tiše udělilo novou moc: nově oznámená operace začíná zamítnutá.

Buďte jasní v tom, co podpis dokazuje. Descriptor podepsaný klíčem spárovaného executoru dokazuje, že ten klíč tvrzení učinil. Neprokazuje, že hostitel není kompromitovaný, a rozhraní to musí říct.

Odeslání: kandidát, vazba, příkaz, potvrzení

Agent nikdy nepojmenovává executor. Než může běh executor použít, Nessie přeloží logickou operaci na neprůhledného, krátkodobého kandidáta na dostupnost. Odpověď neobsahuje identifikátor executoru; databáze si uchovává jen digest identifikátoru (handle) spolu s tím, kdo a pro co byl vyřešen. Modely a klienti dostávají identifikátor, nikoli stroj, který by si mohli vybrat.

Dostupnost řeší jeden resolver, který shodně používají API, worker, uživatelské rozhraní i asistent:

available(operation, human, agent, immutableRunContext) =
  human may discover executor
  ∩ exact executor-agent-operation grant allows operation
  ∩ stable logical tool grant allows operation
  ∩ scope matches immutable run context
  ∩ executor is online and descriptor is approved
  ∩ local policy permits operation

Spotřebování kandidáta vytvoří vazbu pod zámkem databáze, který znovu ověří všechny tyto brány, a posune monotónní čítač fence. Odeslání je ověří ještě jednou. Důsledkem je, že odebrané oprávnění, zúžená politika nebo odvolaný executor mezi dvěma kroky práci zastaví, místo aby se o tom dozvěděla až později — a opakovaný pokus nikdy nemůže skončit na jiném stroji, než na kterém byl běh svázán.

Samotný příkaz jede přes běžnou frontovou úlohu Nessie a životní cyklus volání nástrojů, nikoli přes vlastní druhou frontu. Daemon si práci vyžaduje sám přes ověřený řídicí kanál; nikdy se mu nic nepushuje. Příkaz projde čtyřmi potvrzeními a žádnými dalšími:

leased → accepted → started → result-acknowledged

Každý rámec váže identifikátor příkazu, původ běhu, číslo fence vazby, revizi schopností, expiraci, idempotentní klíč a digesty argumentů i obsahu. Daemon odmítne neshodu, zastaralou politiku, opakované přehrání nebo druhý výsledek pro příkaz, který už dokončil. Argumenty a koncové výsledky se ukládají šifrované algoritmem AES-256-GCM; databáze uchovává omezený šifrovaný text a kanonické digesty, nikoli obsah.

Pokud se ztratí potvrzení, Nessie nepředpokládá úspěch. Příkaz se zapíše jako neznámý výsledek a běh jde běžnou cestou obnovy. Daemon každý doručený příkaz zaznamená lokálně do žurnálu dřív, než začne pracovat, takže vedlejší efekt nezopakuje. Pozdější potvrzení může nejednoznačnost poctivě vyřešit.

Hranice důvěry

Instalace a párování executoru

CLI pro Mac nainstalujete přes Homebrew, aplikace pro Mac přes Homebrew cask, CLI pro Linux přes APT nebo DNF a executor pro Windows přes WinGet. Každý spárovaný tým má svá oprávnění uložená na počítači. Nessie řídí přístup v rámci týmu; místní prostředky změnit nemůže.

Průvodce instalací a párováním obsahuje přesné příkazy, dvoustranný postup s osmimístným kódem, místní nastavení, spouštění, aktualizace a odebrání.

Jak daleko je každá platforma skutečně ověřena

Stav tří guest sandboxů se liší a ten rozdíl je podstatný. macOS má funkční a otestovaný guest backend. Backend Firecracker na Linuxu a backend Hyper-V na Windows jsou implementovány a pokryty testy na straně hostitele — spouštěcí sekvence, diskové obrazy, transporty řízení a odchozího provozu, protokol konceptů. Žádný guest však zatím v kontinuální integraci tohoto projektu nenastartoval na reálném hardwaru, protože to vyžaduje počítač s KVM nebo Hyper-V a úlohy, které by to dokázaly, takový stroj nikdy neměly. Pracovní balík, který guest nepotřebuje, je otestován od začátku do konce na Windows proti skutečné řídicí smyčce. S operacemi s guest VM na Linuxu a Windows zacházejte jako s neověřenými, dokud je neověříte na vlastním hardwaru. Obrazovka párování v Nessie říká totéž vlastními slovy.

Bezpečnost a izolace

Jeden kořen pracovního prostoru a jeho cesta zůstává na stroji

Párování vybere přesně jeden kanonický kořen pracovního prostoru: jeden adresář, ne sadu složek, a nikdy jejich nejbližšího společného předka. Nessie je řečen základní název kořene, aby osoba poznala hranici v rozhraní; úplná cesta zůstává v místním stavu stroje přístupném jen vlastníkovi a nikdy se nenahrává. Změnit kořen lze, ale až poté, co se odstraní všechny místní koncepty a sandboxy, a vznikne nová revize descriptoru, která projde stejnou lidskou kontrolou jako každá jiná změna politiky. Nikdy se tiše nerozšíří na nadřazený adresář.

Operace se soubory přijímají pouze relativní cesty. Odmítají procházení mimo kořen a každou komponentu symbolického odkazu, znovu ověřují, že nakonfigurovaný kořen je stále běžný adresář, a vracejí omezené strukturované výsledky bez cesty na hostiteli.

Zápisy jdou do kopie a jen člověk je může povýšit

Agent nikdy nezapisuje do vašich souborů. file.write vytvoří omezený copy-on-write strom pod vlastním stavovým adresářem daemonu, navázaný na běh, a pozdější čtení a výpisy pro daný běh vidí koncept. Práce v guest VM, včetně relací kódování, používá stejný copy-on-write dočasný prostor.

Aplikace konceptu na skutečný pracovní prostor je jediná operace — workspace.promote — a je to jediný zápis na hostitele v celém systému. Nemá vůbec žádné schéma pro modely: žádný agent, žádný asistent ani cesta zadaná volajícím nemůže přeměnit koncept na zápis na hostitele. Místo toho osoba otevře Your reviewed drafts, stiskne Review promotion a potvrdí svým aktuálním heslem. Server pak znovu ověří potvrzený digest kontroly, digest manifestu, původní běh, uživatele a agenta, revizi autorizace, grant operace a aktivní místní politiku, než vytvoří příkaz. Na stroji daemon manifest sestaví znovu sám a odmítne digest, který se změnil — takže úprava provedená po kontrole nemůže proklouznout s jejím schválením.

Samotné použití je založené na deskriptorech a zapsané do žurnálu. Nativní pomocný proces dostává kořen pracovního prostoru a koncept jako již otevřené deskriptory adresářů, nikoli jako cesty. Ověřuje každou komponentu operacemi bez sledování odkazů, odmítá symbolické a pevné odkazy, speciální soubory a přechody přes připojené svazky (mount). Udržuje žurnál typu vše-nebo-obnovit, takže pád buď dokončí ověřený manifest, nebo před čímkoli jiným obnoví původní stav.

Guest nemá síť a odchozí provoz je vynucen

Když operace guest potřebuje, je to micro-VM Linuxu pro každou relaci, bez domovského adresáře hostitele, bez socketu Dockeru, bez agenta SSH, bez zděděného prostředí a bez jiného připojeného hostitelského svazku než sdílení pracovního prostoru. Spustitelný runtime je připojen jen pro čtení; zapisovatelné připojení pracovního prostoru spouštění zakazuje, takže cokoli se spouští pochází z ověřeného runtime balíku, a ne z něčeho, co napsal agent. Guest před otevřením jakéhokoli socketu přejde na neprivilegovanou identitu a sdílení vlastněné uživatelem root ukončí boot, místo aby ponechalo privilegovanou úlohu běžet.

Nejdůležitější je, že guest nemá síťové rozhraní. V Linuxu spouštěcí sekvence záměrně nic nekonfiguruje a nevytváří se žádné zařízení TAP; ve Windows se virtuální síťový adaptér, který Hyper-V standardně přidává, při nastavení odstraní. Jediná cesta guestu ven ze stroje je loopback proxy uvnitř něj, tunelovaná přes virtuální socket k mostu na hostiteli, který bajty předá bráně samotného daemonu. Ta je socketovým posluchačem pouze pro vlastníka bez TCP posluchače a bez obecného režimu přeposílání. Právě tam se vynucuje politika HTTP, CONNECT, WebSocket, přesměrování, původu, stahování a nahrávání. Používá existující mechanismus Nessie pro připnuté načítání (pinned fetch), nikoli druhou implementaci stejných pravidel. Neexistuje žádný NAT most ani přímý DNS resolver: alternativní DNS, surové TCP, QUIC a obcházení proxy jsou všechna zakázána.

Seznam původů, který brána vynucuje, je nakonfigurován na stroji jeho vlastníkem a záměrně se nikdy nenahrává. Rozhraní tuto absenci pojmenovává, místo aby předstíralo, že Nessie je editor politik původů: co smí prohlížečový executor otevřít, zjistíte od osoby, která stroj vlastní.

Přihlašovací údaje

Žádné úložiště přihlašovacích údajů hostitele se nikdy nepřipojuje do guestu. Ani klíčenka, ani ~/.codex nebo ~/.claude, ani globální token CLI, ani proměnná prostředí s API klíčem. Jediné podporované přihlášení pro spravovanou relaci kódování je autentizační soubor patřící jen vlastníkovi, jehož obsah čte výhradně sestavovač initrd ovládaný vlastníkem — nikdy Nessie, nikdy descriptor, nikdy log ani argument příkazu. Soubor se jednorázově přesune do soukromého domovského adresáře uvnitř guestu, který se zničí spolu s VM. Tento guest může dosáhnout přesně jednoho původu.

Executor prohlížeče je ještě přísnější: každá relace dostane čerstvý soukromý profil prohlížeče a odmítne ten, který připravil pracovní prostor, takže začíná bez cookies, bez rozšíření a bez přenesených přihlášení.

Surová lokální data se mohou dostat k poskytovateli modelu jen uvnitř explicitního, omezeného běhu. Nessie trvale ukládá jen očištěné manifesty, digesty argumentů a politik, digesty výsledků a strukturovaný stav. Obsah souborů, výstup terminálu, DOM prohlížeče, přihlašovací údaje a ověřovací faktory se nesmějí objevit v databázových záznamech, auditních záznamech, logech, realtime událostech ani hlášeních o chybách.

Co provozovatel uděluje a jak to zase odebírá

Oprávnění použít executor není jeden přepínač. Agent může vyvolat operaci, jen když drží grant pro přesný executor a přesnou operaci, a zároveň běžná logická politika nástrojů to povoluje, a zároveň rozsah běhu sedí, a zároveň místní politika stroje to dovoluje. Udělení jedné operace na jednom executoru tedy nic neautorizuje na jiném a obnovení schopností nemůže nic rozšířit, protože nové operace přicházejí zamítnuté.

Přístup agentů i sdílení se projeví hned na samotné stránce, bez pokračování schválením, bez výzvy k heslu a bez nového ověřování. Na záložce Agents u executoru správce přímo zapíná nebo vypíná přístup agenta ke stroji; na záložce Sharing dává osobě oprávnění Can use nebo Admin, nebo rozšiřuje použití na projekt či na všechny v aktuálním týmu, stejným způsobem. Ve vaší vlastní konverzaci s asistentem — jen tam, nikdy ve sdíleném kanálu, v naplánované úloze nebo v běhu jiného agenta — může asistent místo toho připravit změnu přístupu agenta nebo přiřazení. Ta zveřejní potvrzovací kartu do té konverzace a nic se nezmění, dokud na ní nestisknete Allow access. Text v chatu se nikdy nepočítá jako potvrzení.

Tři změny stále vyžadují, abyste při potvrzení znovu zadali své aktuální heslo: aktivaci revize descriptoru; asistentem připravené přiřazení, které dává stroj osobě, nikoli agentovi; a trvalou politiku, která kolegům dovoluje spouštět na stroji příkazy jako jeho vlastník, tedy politiku neobslužené práce na úkolech. Odpojení nebo smazání stroje záměrně ani jedno nevyžaduje, protože vypínač nesmí být těžší k dosažení než to, co zastavuje. Povýšení zkontrolovaného konceptu to vždy vyžaduje. Auditní záznam zvlášť eviduje jednajícího člověka a zapojení asistenta.

Executor prochází malou, explicitní sadou stavů:

pending_pairing → online ↔ offline
        │             ↓
        └──────────→ draining → revoked
                         ↓
                       error

Nabídka Computer v hlavičce je místo, kde správce připravuje každou změnu životního cyklu: pozastavit ji, po pozastavení obnovit, odpojit ji nebo smazat. Pozastavení ponechá executor online, ale přestane přijímat příkazy. Odpojení zneplatní jeho klientské certifikáty a všechny čekající identifikátory kandidátů a nelze jej vrátit zpět — odpojený executor se musí znovu spárovat jako nový. Smazání dělá totéž a navíc odstraní executor ze seznamu. Na rozdíl od odpojení se nabízí bez ohledu na stav executoru, včetně čekajícího párování a už odpojeného, protože je to jediný způsob, jak ze seznamu odejít. Drenáž — dokončení práce, kterou už má, než přestane brát další — je v protokolu skutečný třetí stav a rozhraní může stroj v tomto stavu zobrazit, ale nic v něm nespustí; pouze přímé volání API. Každá potvrzená změna přístupu, kontrola descriptoru a přechod životního cyklu, včetně drenáže, také posune epochu připojení daemonu, takže jeho další řídicí dotaz — nejdéle za jednu sekundu — selže uzavřeně (fail closed) a zastaví každý běžící guest dřív, než se může znovu připojit. Odvolání je žádost, kterou stroj nemůže ignorovat.

Provoz executoru

Kontrola, že je v pořádku

Odpověď Nessie je kontrola živosti. Daemon podepisuje heartbeat a executor, jehož poslední ověřená aktivita je starší než šedesát sekund, se trvale označí jako offline dřív, než může být vypsán, vybrán nebo mu něco odesláno. Executor, který se ukazuje jako online, se prokázal během poslední minuty.

Na stroji neexistuje žádný endpoint pro kontrolu stavu — daemon záměrně neposlouchá na žádném portu určeném pro operátora. Na macOS a Linuxu se zeptejte přímo CLI:

nessie-executor status                # every paired executor, plus linger state
nessie-executor status <executorId>
systemctl --user status nessie-executor@<executorId>

Na macOS stav hlásí launchd agent každého týmu. Příkaz systemctl je pouze pro Linux. Na Windows je ikona v systémové liště rychlou odpovědí, její nabídka uvede důvod a podrobnosti jsou v logu služby. Na obou platformách záložka Overview executoru v Nessie ukazuje jeho schválené profily, hranici dat, kdy byl naposledy viděn a případný čekající návrh místní politiky ke kontrole.

Logy

Sem se zapisuje každé odmítnutí, které může člověk řešit: nepodepsaný nebo pozměněný runtime, stavový adresář, který nelze zabezpečit, executor, který se při startu nespustil. Sem se nikdy nezapisuje výzva k párování, klíč ani výstup podřízeného procesu. Neexistuje žádné nastavení úrovně logování, které by bylo třeba zvýšit, protože není co podrobnějšího zapnout.

CLI pro Mac zapisuje servisní log každého týmu do ~/Library/Logs/NessieExecutor/<executorId>.log.

Aktualizace

Aktualizujte CLI přes Homebrew, APT nebo DNF a pak restartujte službu každého týmu příkazy disable a poté enable. WinGet aktualizuje executor pro Windows. Přímé instalátory Nessie Desktop nabízejí podepsané aktualizace v aplikaci; instalace MSI a Debian používají svého správce balíčků. Párování a místní oprávnění aktualizace přežijí.

Zastavení a odebrání

Zastavení je řízená cesta, kterou vlastní daemon, nikoli zabití procesu. Daemon přijme signál k ukončení, zastaví každou guest relaci, uvolní svůj lease a skončí. V Linuxu jednotka čeká patnáct sekund na desetisekundový rozpočet na úklid a záměrně nikdy nepřechází na nezachytitelné zabití, protože daemon zabitý uprostřed úklidu by nechal micro-VM a overlay pracovního prostoru bez procesu, který by je uklidil. Zastavení, které se zasekne, je proto vidět v systemctl --user status, a ne tiše; eskalace je záměrné lidské rozhodnutí.

Odebrání balíčku v Linuxu:

nessie-executor disable <executorId>   # stops and disables the service
sudo apt remove nessie-executor
loginctl disable-linger                # only if your user manager should stop running at boot too

Na Windows msiexec /x zastaví a odebere službu, její záznamy v registru a položku spouštění trayové ikony. Na obou platformách spárovaný stav záměrně zůstává: ~/.local/state/nessie-executor/ v Linuxu a %ProgramData%\Nessie Executor ve Windows. Párování je klíč stroje a podepsaná revize politiky a odinstalování programu není žádost o jejich zničení; přeinstalace je najde tam, kde byly. Pro zapomenutí párování smažte adresář ručně a executor v Nessie odvolejte, čímž ho ukončíte i z druhé strany.

Ikona na Windows i desktopový společník nabízejí Forget pairing on this computer jako plnohodnotnou akci: zastaví místní daemon, odstraní klíč stroje a výběr složky a po jediném nativním potvrzení trvale smaže místní kopie konceptů. Serverový executor a jeho auditní historii ponechá vlastníkovi, aby je zachoval nebo odvolal.

Časté chyby