Fjärrexecutorer

Ge en agent en riktig dator att arbeta på, med Linux, macOS eller Windows.

Vad en fjärrexecutor är

En agent i Nessie har ingen dator. Den kan läsa det som finns i Nessie, prata med människor och anropa kopplade verktyg över nätverket – men den kan inte öppna en fil på en bärbar dator, köra ett kommando eller titta på en sida som bara finns bakom någons inloggning. En fjärrexecutor är hur du ger den en dator att arbeta på.

En executor är en liten daemon som du installerar på en dator du kontrollerar. Den parkopplar sig utåt mot din Nessie-instans, bevisar vilken maskin den är med en nyckel som aldrig lämnar värddatorn och erbjuder sedan en fast, namngiven uppsättning operationer – inget annat. Arbete kommer in som enskilda signerade kommandon, och resultaten skickas tillbaka som avgränsade, strukturerade kvitton. Maskinen tar aldrig emot en inkommande anslutning från Nessie.

Det är värt att vara exakt om vad en executor inte är, eftersom de flesta fjärråtkomstverktyg är något av dessa och en executor är medvetet inget av dem. Det finns ingen SSH, inget allmänt fjärrskal, ingen koppling till en terminalmultiplexer du redan har öppen, ingen standardindata från molnsidan och ingen allmän proxy för det lokala nätverket. Den är inte en MCP-server, och den är inte en container eller en exekveringsmiljö i molnet – Nessie har redan sådant, och det är något annat. En executor är en slutpunkt som bara ger åtkomst via explicit beviljade förmågor, med en sluten lista över operationer, och den listan är hela ytan.

Vem en executor tillhör

Varje executor skapas med exakt en omfattning, och den omfattningen kan inte ändras efteråt. Den avgör vem som får anropa executorn och vem som får administrera den.

En privat executor måste alltid ha minst en aktiv mänsklig administratör. Att ta bort den sista direkt misslyckas; om en person som lämnar organisationen skulle lämna ingen kvar slutar executorn ta emot nya uppdrag, slutför det den redan har och återkallar sig själv. En organisationsägare har en återkallningsväg för nödfall som avslutar en executor de inte annars administrerar, utan att visa dem dess privata lista över personer, dess sessioner eller dess innehåll – privat åtkomst överförs aldrig tyst till någon annan.

Vad en agent faktiskt kan göra med en executor

Uppsättningen operationer är fast i koden, inte konfigurerbar per installation. Den delas i två: vissa operationer betjänas av daemonen från dess egen temporära arbetskatalog utan någon virtuell maskin alls, och resten kräver en gäst-VM per session på värddatorn. Det avgör vad du behöver installera.

Operationerna som inte behöver någon gäst är arbetsytepaketet. En värd som inte kan starta en gäst är inte en trasig executor: den parkopplas normalt, rapporterar sin sandbox-backend som none och annonserar bara arbetsytepaketet och inget annat. Det är läget en Windows-utgåva utan Hyper-V, eller en Linux-maskin vars användare inte kan använda /dev/kvm, hamnar i, och gränssnittet anger det i stället för att misslyckas på ett otydligt sätt.

Webbläsararbete är aldrig något en agent startar på eget initiativ. Den vanliga enkeloperationsvägen för bindning vägrar browser.open och browser.observe helt och hållet; en webbläsarkörning startas av en person från en kanal, som ett paket med fyra operationer i en ny körning, och ingen ytterligare bindning kan läggas till i den efteråt. Hanterade kodsessioner fungerar på samma sätt.

Två grupper till finns i koden och är medvetet otillgängliga. Operationer för att styra en Chrome-flik som du redan är inloggad i har en fullständig lokal implementation och ett tillägg för native messaging, men kontrollplanet vägrar annonsera dem tills servern kan bevisa att den ursprungliga konversationen var privat och registrera vem som lämnat ut vad. Grunden är medvetet overksam, och tillägget levereras inte i någon av installationsprogrammen. Dessutom är flera kodoperationer – attach, prompt, interrupt och close – namngivna i schemat men saknar implementation, så de kan inte beviljas.

Hur det fungerar

Anslutningen är alltid utgående

Daemonen gör utgående HTTPS- och WSS-anslutningar till ditt Nessie-API och ingenting annat. Nessie ringer aldrig upp en bärbar dator, har aldrig en adress till en sådan och behandlar aldrig någon katalogslutpunkt som en maskintransport. Därför fungerar en executor från ett hemnätverk, bakom NAT, på ett företags-VPN, utan portvidarebefordran och utan regel i brandväggen för inkommande trafik – och därför är det att stoppa daemonen en fullständig och omedelbar frånkoppling.

API:ets ursprung måste vara HTTPS. Det enda undantaget är en loopback-adress för personer som kör Nessie på sin egen maskin, styrd av en egen miljövariabel; ingen vanlig flagga gör ett produktionsursprung till vanlig HTTP.

Parkoppling bevisar en maskin, och en person bekräftar den

Parkopplingen är ett tvåsidigt bevis. En behörig person skapar executorn i Nessie med dess omfattning, och Nessie utfärdar en registrering: en slumpmässig 256-bitars utmaning, av vilken Nessie bara lagrar en SHA-256-verifierare. Registreringen är giltig i tio minuter och kan bara användas en gång.

På maskinen genererar daemonen ett Ed25519-nyckelpar, lagrar det i lagring som bara ägaren kan läsa och som operativsystemet skyddar, och skriver den exakta signerade begäran till disk innan den gör något nätverksanrop. Så kan ett förlorat svar försökas igen med samma förberedda nyckel i stället för att tyst parkopplas två gånger. Den skickar sedan registreringens id, utmaningen, sin publika nyckel och en bevissignatur. Nessie lagrar den publika nyckeln och dess fingeravtryck. Den lagrar aldrig den privata nyckeln.

Nessie visar sedan fingeravtrycket för en person, som bekräftar det. Tills den bekräftelsen och ett efterföljande bevis på innehav är gjorda förblir executorn offline. Parkoppling kan aldrig slutföras från chattext eller en terminalutskrift: det krävs en avsiktlig mänsklig handling i webb- eller skrivbordsgränssnittet.

En maskin som tappar sin nyckel kan inte återta sin executor-post. Den återkallas och registreras på nytt som en ny executor. Nyckelrotation är däremot en enda transaktion som signeras av både den gamla och den nya nyckeln.

Deskriptorn är maskinens signerade påstående om sig själv

En parkopplad daemon publicerar en deskriptor: ett signerat påstående vars revision alltid ökar och som bara innehåller strukturella fakta – vilka operationsscheman den stöder, dess resurs- och nätverksgränser, dess plattform och ett digest av dess lokala policy. Den innehåller inga värdsökvägar och skapar ingen behörighet i molnet.

En ny revision aktiveras aldrig när den anländer. Den lagras som väntande granskning, och en behörig person måste se den och bekräfta den innan den kan påverka vad som finns tillgängligt. Det är det som hindrar att en uppdatering av förmågor tyst beviljar ny makt: en nyligen annonserad operation börjar nekad.

Var tydlig med vad signaturen bevisar. En deskriptor signerad av en parkopplad executor-nyckel bevisar att nyckeln gjorde påståendet. Den bevisar inte att värddatorn är oförstörd, och gränssnittet måste säga det.

Dispatch: kandidat, bindning, kommando, kvitto

En agent väljer aldrig en executor. Innan en körning kan använda en löser Nessie den logiska operationen till en ogenomskinlig, kortlivad tillgänglighetskandidat. Svaret innehåller inget executor-id; databasen behåller bara ett digest av handtaget tillsammans med vem och vad det löstes för. Modeller och klienter får ett handtag, inte en maskin att välja.

Tillgänglighet hanteras av en enda resolver, som används identiskt av API:et, workern, gränssnittet och assistenten:

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

Att konsumera kandidaten skapar en bindning under ett databaslås som kontrollerar var och en av dessa spärrar en andra gång och flyttar fram en fence-räknare som bara ökar. Dispatch kontrollerar dem igen. Följden är att en tilldelning som dras tillbaka, en policy som snävas åt eller en executor som återkallas mellan två steg stoppar arbetet i stället för att märkas efteråt – och ett återförsök kan aldrig landa på en annan maskin än den som körningen blev bunden till.

Själva kommandot går via Nessies vanliga kötjobb och livscykeln för verktygsanrop i stället för via ett eget. Daemonen frågar efter arbete över sin autentiserade kontrollkanal; den får aldrig push. Ett kommando rör sig genom fyra kvitton och inga andra:

leased → accepted → started → result-acknowledged

Varje meddelande binder kommando-id, körningens ursprung, bindningens fence-värde, förmågerevisionen, en förfallotid, en idempotensnyckel och digest av både argumenten och nyttolasten. Daemonen vägrar en avvikelse, en inaktuell policy, en återspelning eller ett andra resultat för ett kommando den redan har slutfört. Argument och slutresultat krypteras med AES-256-GCM i vila; databasen behåller avgränsad chiffertext och kanoniska digest, inte innehållet.

Om en bekräftelse går förlorad antar Nessie inte att det lyckades. Kommandot registreras som ett okänt utfall och körningen följer den vanliga återhämtningsvägen. Daemonen, som journalför varje levererat kommando lokalt innan den börjar arbeta, upprepar inte sidoeffekten. Ett sent kvitto kan fortfarande lösa tvetydigheten ärligt.

Förtroendegräns

Installera och parkoppla en executor

Installera Mac-CLI:t med Homebrew, Mac-apparna med Homebrew-casks, Linux-CLI:t via APT eller DNF, eller Windows-executorn via WinGet. Varje parkopplat team har egna behörigheter, lagrade på datorn. Nessie styr åtkomsten inom teamet; det kan inte ändra lokala resurser.

Guiden för installation och parkoppling har exakta kommandon, det tvåsidiga flödet med åttasiffrig kod, lokala inställningar, start, uppdateringar och avinstallation.

Hur långt varje plattform faktiskt har bevisats

Läget för de tre gästsandboxarna skiljer sig åt, och skillnaden är väsentlig. macOS är backenden med en fungerande, testad gästväg. Firecracker-backenden på Linux och Hyper-V-backenden på Windows är implementerade och täckta av tester på värdsidan – startsekvensen, diskavbilderna, kontroll- och utgående transporterna, utkastprotokollet – men ingen gäst har ännu startats på riktig hårdvara i projektets kontinuerliga integration, eftersom det kräver en maskin med KVM eller Hyper-V och de jobb som skulle bevisa det har aldrig haft en sådan. Arbetsytepaketet, som inte behöver någon gäst, är testat från början till slut på Windows mot en verklig kontrollslinga. Behandla gäststödda operationer på Linux och Windows som obevisade tills du har bevisat dem på din egen hårdvara. Parkopplingsskärmen i Nessie säger samma sak med sina egna ord.

Säkerhet och inneslutning

En rotkatalog för arbetsytan, och dess sökväg stannar på maskinen

Parkopplingen väljer exakt en kanonisk arbetsytans rot: en katalog, inte en uppsättning mappar, och aldrig deras närmaste gemensamma överordnade katalog. Nessie får veta rotens basnamn, så att en person kan känna igen gränsen i gränssnittet; hela sökvägen stannar i maskinens ägarskyddade tillstånd och laddas aldrig upp. Det går att ändra roten, men bara efter att alla lokala utkast och sandboxar har tagits bort, och det ger en ny deskriptorrevision som går genom samma mänskliga granskning som alla andra policyändringar. Den kan aldrig tyst vidgas till en överordnad katalog.

Filoperationer accepterar bara relativa sökvägar. De avvisar traversering och varje symbolisk länk i sökvägen, kontrollerar på nytt att den konfigurerade roten fortfarande är en vanlig katalog och returnerar avgränsade strukturerade resultat utan någon värdsökväg.

Skrivningar går till en kopia, och bara en person tillämpar dem

En agent skriver aldrig till dina filer. file.write skapar ett avgränsat kopiera-vid-skrivning-träd under daemonens egen tillståndskatalog, nycklat till körningen, och senare läsningar och listningar för den körningen ser utkastet. Arbete i gästen, inklusive kodsessioner, använder samma kopiera-vid-skrivning-utrymme för tillfälliga filer.

Att tillämpa ett utkast på den riktiga arbetsytan är en enda operation – workspace.promote – och det är den enda skrivningen till värden i systemet. Den har inget modellriktat schema alls: ingen agent, ingen assistent och ingen sökväg från anroparen kan göra ett utkast till en skrivning på värden. I stället öppnar en person Dina granskade utkast, trycker på Granska tillämpning och bekräftar med sitt nuvarande lösenord. Servern kontrollerar sedan på nytt det bekräftade granskningsdigestet, manifestdigestet, den ursprungliga körningen, användaren och agenten, auktoriseringsrevisionen, operationstilldelningen och den aktiva lokala policyn innan den skapar kommandot. På maskinen bygger daemonen om manifestet själv och vägrar ett digest som har ändrats – så en redigering som görs efter granskningen kan inte åka med på granskningens godkännande.

Själva tillämpningen är deskriptorbaserad och journalförd. Den inbyggda hjälpen tar emot arbetsytans rot och utkastet som redan öppnade katalogdeskriptorer, aldrig som sökvägar. Den validerar varje komponent med operationer som inte följer symboliska länkar, avvisar symboliska länkar, hårda länkar, specialfiler och monteringspunkter som korsas, och håller en allt-eller-återställ-journal. Så antingen slutför en krasch det validerade manifestet eller återställer originalet innan något annat körs.

Gästen har inget nätverk, och utgående trafik tvingas

När en operation kräver en gäst är det en Linux-mikro-VM per session, utan hemkatalog på värden, ingen Docker-socket, ingen SSH-agent, ingen ärvd miljö och ingen värdmontering utöver arbetsytans delning. Den körbara körningsmiljön är monterad skrivskyddad; den skrivbara arbetsytemonteringen förbjuder körning. Allt som körs kommer därför från den verifierade körningsnyttolasten och inte från något en agent skrivit. Gästen går ner till en oprivilegierad identitet innan den öppnar någon socket, och en delning som ägs av root gör att starten misslyckas i stället för att lämna en privilegierad arbetslast igång.

Viktigast av allt har gästen inget nätverksgränssnitt. På Linux konfigurerar startsekvensen medvetet aldrig ett, och ingen TAP-enhet skapas; på Windows tas det virtuella nätverkskort som Hyper-V lägger till som standard bort under installationen. Gästens enda väg ut från maskinen är en loopback-proxy inuti den, tunnlad över en virtuell socket till en brygga på värden. Bryggan lämnar över byten till daemonens egen gateway – en lyssnare på en lokal socket som bara ägaren kan använda, utan TCP-lyssnare och utan allmänt vidarebefordringsläge. Där tillämpas policyn för HTTP, CONNECT, WebSocket, omdirigering, ursprung, nedladdning och uppladdning, med Nessies befintliga pinnade hämtningsmekanism (pinned-fetch) i stället för en andra implementation av samma regler. Det finns ingen NAT-brygga och ingen direkt DNS-resolver: alternativ DNS, rå TCP, QUIC och förbikoppling av proxy är alla nekade.

Ursprungslistan som gatewayen tillämpar konfigureras på maskinen, av dess ägare, och laddas medvetet aldrig upp. Gränssnittet säger att den saknas i stället för att låtsas att Nessie är en redigerare av ursprungspolicy. För att veta vad en webbläsarexecutor får nå, fråga personen som äger maskinen.

Autentiseringsuppgifter

Inget värdlager för autentiseringsuppgifter monteras någonsin i en gäst. Varken nyckelringen, ~/.codex eller ~/.claude, inte en global CLI-token och inte en miljövariabel med en API-nyckel. Den enda stödda inloggningen för en hanterad kodsession är en autentiseringsfil som bara ägaren kan läsa. Dess innehåll läses enbart av den ägarstyrda initrd-byggaren – aldrig av Nessie, aldrig av deskriptorn, aldrig av en logg eller ett kommandoargument. Filen flyttas en gång till ett privat hem i gästen, som förstörs tillsammans med VM:en. Den gästen kan nå exakt ett ursprung.

Webbläsarexecutorn är ännu strängare: varje session får en ny privat webbläsarprofil och vägrar en profil som förberetts av arbetsytan. Den startar därför utan cookies, utan tillägg och utan något omgivande inloggat tillstånd.

Rådata från den lokala maskinen kan nå en modellleverantör bara inuti en tydlig, avgränsad körning. Det Nessie sparar är redigerade manifest, digest för argument och policy, digest för resultat och strukturerad status. Filinnehåll, terminalutdata, webbläsarens DOM, autentiseringsuppgifter och autentiseringsfaktorer är förbjudna i databasposter, revisionsposter, loggar, realtidshändelser och felrapporter.

Vad en operatör tilldelar, och hur tilldelningen återtas

Behörighet att använda en executor är inte en enda strömbrytare. En agent kan anropa en operation bara när den har en tilldelning för just den executorn och just den operationen, och den vanliga logiska verktygspolicyn tillåter den, och körningens omfattning stämmer, och maskinens egen lokala policy tillåter den. Att tilldela en executor en operation ger därför ingen rätt på en annan, och en uppdatering av förmågor kan inte vidga något, eftersom nya operationer kommer in nekade.

Agentåtkomst och delning träder båda i kraft direkt på själva sidan, utan godkännandesteg, lösenordsprompt eller steg för ny autentisering. På executorns flik Agenter slår en administratör av eller på en agents åtkomst till maskinen direkt. Under Delning ger de en person Kan använda eller Admin, eller utökar användningen till ett projekt eller till alla i det aktuella teamet, på samma sätt. I din egen assistentkonversation – bara där, aldrig i en delad kanal, ett schemalagt jobb eller en annan agents körning – kan assistenten i stället förbereda en ändring av agentåtkomst eller tilldelning. Det lägger ett bekräftelsekort i den konversationen. Ingenting ändras förrän du trycker på Tillåt åtkomst på kortet, och chattext räknas aldrig som bekräftelse.

Tre ändringar kräver fortfarande att du anger ditt nuvarande lösenord igen i ögonblicket för bekräftelsen: att aktivera en deskriptorrevision; en assistentförberedd tilldelning som ger en person, snarare än en agent, maskinen; och en stående policy som låter kollegor starta kommandon på den som ägaren, policyn för obevakat ärendearbete. Att koppla från eller ta bort en maskin begär medvetet varken det ena eller det andra, eftersom en nödbroms aldrig får vara svårare att nå än det den stoppar. Tillämpning av ett granskat utkast kräver alltid lösenordet. Granskningsloggen registrerar den handlande personen och assistentens inblandning separat.

En executor rör sig genom en liten, tydlig uppsättning tillstånd:

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

Menyn Dator i sidhuvudet är där en administratör förbereder varje livscykeländring: pausa den, återuppta den när den är pausad, koppla från den eller ta bort den. Att pausa lämnar executorn online men slutar ta emot kommandon. Att koppla från ogiltigförklarar dess klientcertifikat och varje utestående kandidathandtag, och det kan inte ångras – en frånkopplad executor parkopplas om som en ny. Ta bort gör samma sak och tar dessutom bort executorn från listan. Till skillnad från frånkoppling erbjuds den oavsett executorns tillstånd, även väntande parkoppling och redan frånkopplad, eftersom det är det enda sättet att lämna listan. Dränering – att slutföra arbetet den redan har innan den slutar ta emot mer – är ett verkligt tredje tillstånd i protokollet. Gränssnittet kan visa en dator i det, men ingenting här startar det; bara ett direkt anrop till API:t gör det. Varje bekräftad åtkomständring, deskriptorgranskning och livscykelövergång, dränering inräknad, höjer också daemonens anslutningsepok. Så misslyckas dess nästa kontrollfråga – högst en sekund senare – stängt och stoppar varje levande gäst innan den kan återansluta. Återkallelse är ingen begäran som maskinen kan välja att ignorera.

Att driva en executor

Kontrollera att den är frisk

Nessies eget svar är liveness. En daemon signerar ett heartbeat, och en executor vars senaste autentiserade aktivitet är äldre än sextio sekunder markeras varaktigt som offline innan den kan listas, väljas eller få dispatch. En executor som visas som online har bevisat sig själv under den senaste minuten.

Det finns ingen hälsoslutpunkt på maskinen. Daemonen lyssnar inte på någon port riktad mot en operatör, med avsikt. På macOS och Linux frågar du CLI:t direkt:

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

På macOS rapporterar status varje teams launchd-agent. Kommandot systemctl gäller bara Linux. På Windows är ikonen i aktivitetsfältet svaret vid första anblicken, dess meny anger orsaken och tjänstloggen innehåller detaljerna. På båda plattformarna visar executorns flik Översikt i Nessie dess godkända profiler, dess dataavgränsning, när den senast syntes och eventuellt ett lokalt policyförslag som väntar på granskning.

Loggar

Varje avvisning en person kan agera på hamnar där: en osignerad eller manipulerad körningsmiljö, en tillståndskatalog som inte kan säkras, en executor som inte startade vid uppstart. Det som aldrig hamnar där är en parkopplingsutmaning, en nyckel eller en barnprocess utdata. Det finns ingen loggnivå att höja, eftersom det inte finns något mer utförligt att slå på.

Mac-CLI:t skriver varje teams tjänstlogg till ~/Library/Logs/NessieExecutor/<executorId>.log.

Uppgradering

Uppgradera CLI:t via Homebrew, APT eller DNF och starta sedan om varje teams tjänst med disable följt av enable. WinGet uppgraderar Windows-executorn. Direkta Nessie Desktop-installationsprogram erbjuder signerade uppdateringar i appen; MSI- och Debian-installationer använder sin pakethanterare. Parkopplingar och lokala behörigheter består efter uppgraderingar.

Stoppa och ta bort

Att stoppa är en mjuk väg som daemonen själv äger, inte en kill. Den tar emot en avslutningssignal, stoppar varje gästsession, släpper sin lease och avslutas. På Linux väntar enheten femton sekunder på en nedstängningsbudget på tio sekunder och eskalerar medvetet aldrig till en kill som inte kan fångas. Skälet är att en daemon som dödas under nedstängningen lämnar kvar en mikro-VM och ett overlay för arbetsytan utan någon process kvar som kan städa upp dem. Ett stopp som hänger sig syns därför i systemctl --user status i stället för att vara tyst, och eskalering är ett uttryckligt mänskligt beslut.

För att ta bort Linux-paketet:

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

På Windows stoppar och tar msiexec /x bort tjänsten, dess registerposter och aktivitetsfältets startpost. På båda plattformarna lämnas den parkopplade tillståndet medvetet kvar – ~/.local/state/nessie-executor/ på Linux och %ProgramData%\Nessie Executor på Windows. En parkoppling är en maskinnyckel och en signerad policyrevision, och att avinstallera ett program är ingen begäran om att förstöra dem. En ny installation hittar dem där de var. Ta bort katalogen för hand för att glömma en parkoppling, och återkalla executorn i Nessie för att avsluta den från andra sidan.

Windows-aktivitetsfältsappen och skrivbordskompanjonen erbjuder båda Glöm parkopplingen på den här datorn som en förstklassig åtgärd. Den stoppar den lokala daemonen, tar bort maskinnyckeln och mappvalet och raderar permanent de lokala utkastkopiorna efter en bekräftelse i operativsystemet. Executorn på servern och dess revisionshistorik lämnas kvar för en ägare att behålla eller återkalla.

Vanliga fel