Eksterne executorer

Gi en agent en ekte maskin å jobbe på, på Linux, macOS eller Windows.

Hva en ekstern executor er

En agent i Nessie har ingen datamaskin. Den kan lese det som finnes i Nessie, snakke med folk og kalle tilkoblede verktøy over nettverket, men den kan ikke åpne en fil på en bærbar maskin, kjøre en kommando eller se en side som bare finnes bak noens innlogging. En ekstern executor er måten du gir den en maskin å jobbe på.

En executor er en liten daemon du installerer på en datamaskin du kontrollerer. Den kobler seg utover til din Nessie-instans, beviser hvilken maskin den er med en nøkkel som aldri forlater vertsmaskinen, og tilbyr deretter et fast, navngitt sett med operasjoner, og ikke noe annet. Arbeid kommer inn som enkeltvise, signerte kommandoer, og resultatene sendes tilbake som avgrensede, strukturerte kvitteringer. Maskinen aksepterer aldri en innkommende forbindelse fra Nessie.

Det er verdt å være presis om hva en executor ikke er, fordi de fleste verktøy for fjerntilgang er en av disse tingene, og en executor er med vilje ingen av dem. Det finnes ingen SSH, ingen implisitt fjernskall, ingen oppkobling til en terminalmultiplekser du allerede har åpen, ingen standard inn fra skyen og ingen generell proxy for det lokale nettverket. Den er ikke en MCP-server, og den er ikke en container eller et skybasert kjøremiljø. Nessie har slike allerede, og de er noe annet. En executor er et endepunkt som bærer sin egen kapasitet, med en lukket liste over operasjoner, og den listen er hele flaten.

Hvem en executor tilhører

Hver executor opprettes med nøyaktig ett omfang, og omfanget kan ikke endres etterpå. Det avgjør hvem som kan kalle executoren, og hvem som kan administrere den.

En privat executor må alltid ha minst én aktiv menneskelig administrator. Å fjerne den siste direkte mislykkes. Hvis en avslutningstransaksjon ville etterlate ingen, slutter executoren å ta imot nytt arbeid, tømmer arbeidet den har, og tilbakekaller seg selv. En organisasjonseier har en nødvei som bare kan tilbakekalle, og som avslutter en executor de ellers ikke styrer, uten å vise dem dens private deltakerliste, økter eller innhold. Privat tilgang overføres aldri stille til noen andre.

Hva en agent faktisk kan gjøre med en executor

Vokabularet for operasjoner er fast i koden, ikke konfigurert per installasjon. Det deles i to, og delingen avgjør hva du må installere. Noen operasjoner betjenes av daemonen fra sin egen arbeidsmappe uten noen virtuell maskin i det hele tatt. Resten trenger en gjest-VM per økt på verten.

Operasjonene som ikke trenger en gjest, er arbeidsområdepakken. En vert som ikke kan starte en gjest, er ikke en ødelagt executor. Den parer seg normalt, rapporterer sin sandkasse-backend som none, og annonserer arbeidsområdepakken og ingenting annet. Det er tilstanden en Windows-utgave uten Hyper-V, eller en Linux-maskin der brukeren ikke kan bruke /dev/kvm, havner i. Grensesnittet nevner det i stedet for å feile uforklarlig.

Nettleserarbeid er aldri noe en agent starter av seg selv. Den vanlige bindingsruten for én operasjon avviser browser.open og browser.observe uten videre. En nettleserkjøring startes av en person fra en kanal, som ett bunt med fire operasjoner på en ny kjøring, og ingen ytterligere binding kan legges til etterpå. Administrerte kodeøkter fungerer på samme måte.

To ytterligere grupper finnes i koden og er med vilje utilgjengelige. Operasjoner for å styre en Chrome-fane du allerede er logget inn i, har en komplett lokal implementasjon og en utvidelse for native messaging. Kontrollplanet nekter likevel å annonsere dem før serveren kan bevise at den opprinnelige samtalen var privat og registrere hvem som ga ut hva. Grunnlaget er bevisst inaktivt, og utvidelsen er ikke med i noen av installasjonsprogrammene. Flere kodeoperasjoner, attach, prompt, interrupt og close, er nevnt i skjemaet, men har ingen implementasjon, så de kan ikke innvilges.

Slik fungerer det

Forbindelsen er alltid utgående

Daemonen oppretter utgående HTTPS- og WSS-forbindelser til ditt Nessie-API, og ingenting annet. Nessie kobler seg aldri til en bærbar maskin, har aldri en adresse til en, og behandler aldri et katalogendepunkt som en maskintransport. Derfor fungerer en executor fra et hjemmenettverk, bak NAT, på et firma-VPN, uten portvideresending og uten innkommende brannmurregel. Og derfor er det å stoppe daemonen en fullstendig og øyeblikkelig frakobling.

API-originen må være HTTPS. Det eneste unntaket er en loopback-adresse for folk som kjører Nessie på sin egen maskin, styrt av en egen miljøvariabel. Ingen vanlig flagg gjør en produksjons-origin om til vanlig HTTP.

Paring beviser en maskin, og en person bekrefter den

Paring er et tosidig bevis. En berettiget person oppretter executoren i Nessie med dens omfang, og Nessie utsteder en registrering: en tilfeldig 256-bits utfordring som Nessie bare lagrer en SHA-256-verifikator av. Den er gyldig i ti minutter og kan brukes én gang.

På maskinen genererer daemonen et Ed25519-nøkkelpar og lagrer det i eierbegrenset lagring som er beskyttet av operativsystemet. Den skriver den nøyaktige signerte forespørselen til disk før den gjør noe nettverkskall. Slik kan et tapt svar forsøkes på nytt med samme forberedte nøkkel, i stedet for at maskinen parer seg to ganger i stillhet. Deretter sender den registrerings-id-en, utfordringen, sin offentlige nøkkel og en bevissignatur. Nessie lagrer den offentlige nøkkelen og fingeravtrykket. Den lagrer aldri den private nøkkelen.

Nessie viser deretter fingeravtrykket til en person, som bekrefter det. Inntil den bekreftelsen og et senere bevis på besittelse av nøkkelen, forblir executoren frakoblet. Paring kan aldri fullføres fra chat-tekst eller en terminalutskrift. Det krever en bevisst handling fra et menneske i web- eller skrivebordsgrensesnittet.

En maskin som mister nøkkelen sin, kan ikke gjenopprette sin executor-post. Den tilbakekalles og registreres på nytt som en ny executor. Nøkkelrotasjon er derimot én transaksjon signert av både den gamle og den nye nøkkelen.

Deskriptoren er maskinens signerte påstand om seg selv

En paret daemon publiserer en deskriptor: en signert, monotont revidert påstand som bare inneholder strukturelle fakta. Den beskriver hvilke operasjonsskjemaer den støtter, sine ressurs- og nettverksgrenser, plattformen og et digest av sin lokale policy. Den inneholder ingen stier på verten og oppretter ingen autoritet i skyen.

En ny revisjon aktiveres aldri ved ankomst. Den lagres som ventende gjennomgang, og en berettiget person må se den og bekrefte den før den kan påvirke hva som er tilgjengelig. Det er det som hindrer at en oppdatering av egenskaper stille gir ny makt: en nyannonsert operasjon starter avslått.

Vær tydelig på hva signaturen beviser. En deskriptor signert av en paret executor-nøkkel beviser at nøkkelen kom med påstanden. Den beviser ikke at verten er ukompromittert, og grensesnittet må si det.

Utsending: kandidat, binding, kommando, kvittering

En agent velger aldri en executor. Før en kjøring kan bruke en, løser Nessie den logiske operasjonen til en ugjennomsiktig, kortlevd tilgjengelighetskandidat. Svaret inneholder ingen executor-id. Databasen lagrer bare et digest av håndtaket, sammen med hvem og hva det ble løst for. Modeller og klienter får et håndtak, ikke en maskin å velge mellom.

Tilgjengelighet er én resolver, brukt likt av API-et, workeren, grensesnittet og 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

Å forbruke kandidaten oppretter en binding under en databaselås. Låsen sjekker alle disse portene en gang til og øker en monotont økende fence-verdi. Utsending sjekker dem igjen. Konsekvensen er at en tilgang som trekkes tilbake, en policy som innsnevres eller en executor som tilbakekalles mellom to steg, stopper arbeidet i stedet for å bli oppdaget i etterkant. Et nytt forsøk kan aldri havne på en annen maskin enn den kjøringen var bundet til.

Selve kommandoen går via Nessies vanlige køjobb og verktøykall-livssyklus, i stedet for en egen. Daemonen henter arbeid ved å spørre over sin autentiserte kontrollkanal. Den blir aldri skjøvet til. En kommando går gjennom fire kvitteringer og ingen andre:

leased → accepted → started → result-acknowledged

Hver ramme binder kommando-id-en, kjøringens proveniens, bindingens fence, egenskapsrevisjonen, en utløpstid, en idempotensnøkkel og digester av både argumentene og nyttelasten. Daemonen avviser en ikke-samsvar, en utdatert policy, en gjentakelse, eller et ekstra resultat for en kommando den allerede har fullført. Argumenter og endelige resultater krypteres med AES-256-GCM i hvile. Databasen lagrer avgrenset chiffertekst og kanoniske digester, ikke innhold.

Hvis en bekreftelse går tapt, antar Nessie ikke at det gikk bra. Kommandoen registreres som et ukjent utfall, og kjøringen følger den vanlige gjenopprettingsveien. Daemonen journalfører hver levert kommando lokalt før den starter arbeid, og vil ikke gjenta bivirkningen. En sen kvittering kan fortsatt løse tvetydigheten ærlig.

Tillitsgrense

Installere og pare en executor

Installer Mac-CLI-en med Homebrew, Mac-appene med Homebrew casks, Linux-CLI-en via APT eller DNF, eller Windows-executoren via WinGet. Hvert sammenkoblede team har egne tillatelser, lagret på datamaskinen. Nessie styrer tilgang innenfor teamet, men den kan ikke endre lokale ressurser.

Installasjons- og paringsveiledningen har nøyaktige kommandoer, den tosidige flyten med åttesifret kode, lokale innstillinger, oppstart, oppdateringer og avinstallering.

Hvor langt hver plattform faktisk er verifisert

Tilstanden til de tre gjestesandkassene er ulik, og forskjellen er vesentlig. macOS er backenden med en fungerende, testet gjestebane. Firecracker-backenden på Linux og Hyper-V-backenden på Windows er implementert og dekket av tester på verten: oppstartssekvensen, diskbildene, kontroll- og utgående transportene og utkastprotokollen. Men ingen gjest har ennå startet på ekte maskinvare i prosjektets kontinuerlige integrasjon. Det krever en maskin med KVM eller Hyper-V, og jobbene som skulle bevise det, har aldri hatt en. Arbeidsområdepakken, som ikke trenger noen gjest, er testet ende-til-ende på Windows mot en ekte kontrollsløyfe. Behandle gjesteoperasjoner på Linux og Windows som uverifisert til du har bevist dem på din egen maskinvare. Paringsskjermen i Nessie sier det samme med sine egne ord.

Sikkerhet og innesperring

Én arbeidsområderot, og stien til den blir på maskinen

Paring velger nøyaktig én kanonisk arbeidsområderot: én katalog, ikke et sett med mapper, og aldri deres nærmeste felles overordnede katalog. Nessie får vite rotens basename, slik at en person kan kjenne igjen grensen i grensesnittet. Hele stien blir i eierbegrenset maskintilstand og lastes aldri opp. Det er mulig å endre roten, men bare etter at alle lokale utkast og sandkasser er fjernet. Endringen gir en ny deskriptorrevisjon som går gjennom samme menneskelige gjennomgang som enhver annen policy-endring. Roten kan aldri stille utvides til en overordnet katalog.

Filoperasjoner godtar bare relative stier. De avviser traversering og alle symbolske lenke-komponenter, sjekker på nytt at den konfigurerte roten fortsatt er en vanlig katalog, og returnerer avgrensede, strukturerte resultater uten noen vertssti.

Skriving går til en kopi, og bare en person kan overføre den

En agent skriver aldri til filene dine. file.write oppretter et avgrenset copy-on-write-tre under daemonens egen tilstandsmappe, knyttet til kjøringen. Senere lesninger og oppslag for den kjøringen ser utkastet. Arbeid i gjesten, også kodeøkter, bruker den samme copy-on-write-midlertidige lagringen.

Å bruke et utkast på det virkelige arbeidsområdet er én enkelt operasjon, workspace.promote. Det er den eneste skrivingen til verten i systemet. Operasjonen har ingen skjema som er vendt mot modeller: ingen agent, ingen assistent og ingen sti oppgitt av kalleren kan gjøre et utkast til en skriving på verten. I stedet åpner en person Dine gjennomgåtte utkast, trykker Gjennomgå overføring og bekrefter med sitt nåværende passord. Serveren sjekker deretter det bekreftede gjennomgangsdigestet, manifestdigestet, den opprinnelige kjøringen, brukeren og agenten, autorisasjonsrevisjonen, operasjonstilgangen og den aktive lokale policyen, før den oppretter kommandoen. På maskinen bygger daemonen manifestet selv på nytt og avviser et digest som har endret seg. Dermed kan en redigering gjort etter gjennomgangen ikke smugle seg inn på gjennomgangens godkjenning.

Selve anvendelsen er deskriptorbasert og journalført. Det native hjelpeprogrammet mottar arbeidsområderoten og utkastet som allerede åpnede katalogdeskriptorer, aldri som stier. Det validerer hver komponent med operasjoner som ikke følger lenker, og avviser symbolske lenker, harde lenker, spesialfiler og monteringspunkter. Det har en journal som enten fullfører eller gjenoppretter alt, slik at et krasj enten fullfører det validerte manifestet eller gjenoppretter originalen før noe annet kjøres.

Gjesten har ingen nettverkskobling, og all utgående trafikk tvinges gjennom en fast vei

Når en operasjon faktisk trenger en gjest, er det en per-økt Linux-mikro-VM uten hjemmemappe fra verten, ingen Docker-socket, ingen SSH-agent, ikke noe arvet miljø og ingen montering fra verten utover arbeidsområdedelingen. Den kjørbare kjøretidsmonteringen er skrivebeskyttet. Den skrivbare arbeidsområdemonteringen forbyr kjøring, så det som kjører, kommer fra den verifiserte kjøretidspakken og ikke fra noe en agent har skrevet. Gjesten senker rettighetene sine til en uprivilegert identitet før den åpner noen socket. En delt mappe eid av root får oppstarten til å feile, i stedet for å la en privilegert arbeidslast kjøre.

Viktigst er at gjesten ikke har noe nettverksgrensesnitt. På Linux konfigurerer oppstartssekvensen bevisst aldri ett, og ingen TAP-enhet opprettes. På Windows fjernes det virtuelle nettverkskortet Hyper-V legger til som standard, under oppsettet. Gjestens eneste vei ut av maskinen er en loopback-proxy inni den, tunnelert over en virtuell socket til en bro på verten. Broen leverer bytene til daemonens egen gateway: en lokal socket-lytter som bare eieren har tilgang til, uten TCP-lytter og uten generell videresendingsmodus. Det er her HTTP-, CONNECT-, WebSocket-, omdirigerings-, origin-, nedlastings- og opplastingspolicy håndheves. Gatewayen bruker Nessies eksisterende pinned-fetch-mekanisme i stedet for en ny implementasjon av de samme reglene. Det finnes ingen NAT-bro og ingen direkte DNS-resolver. Alternativ DNS, rå TCP, QUIC og proxy-omgåelse er alle avslått.

Listen over origins som gatewayen håndhever, er konfigurert på maskinen av eieren, og lastes bevisst aldri opp. Grensesnittet nevner den fraværende listen i stedet for å late som om Nessie er en redigerer for origin-policy. For å vite hva en nettleserexecutor kan nå, spør du personen som eier maskinen.

Legitimasjon

Ingen legitimasjonslagring på verten blir noensinne montert inn i en gjest. Verken nøkkelringen, ~/.codex eller ~/.claude, ikke et globalt CLI-token og ikke en miljøvariabel med en API-nøkkel. Den eneste støttede innloggingen for en administrert kodeøkt er en eierprivat autentiseringsfil. Innholdet i den leses bare av den eierkontrollerte initrd-byggeren, aldri av Nessie, aldri av deskriptoren, aldri av en logg eller et kommandoargument. Filen flyttes én gang inn i en privat hjemmemappe i gjesten, som ødelegges sammen med VM-en. Den gjesten kan nå nøyaktig én origin.

Nettleserexecutoren er enda strengere. Hver økt får en ny privat nettleserprofil, og en profil som er forberedt av arbeidsområdet, avvises. Dermed starter den uten informasjonskapsler, uten utvidelser og uten innloggingstilstand fra omgivelsene.

Rådata fra maskinen kan nå en modellleverandør bare inne i en eksplisitt, avgrenset kjøring. Det Nessie lagrer, er sladdede manifester, digester av argumenter og policy, resultatdigester og strukturert status. Filinnhold, terminalutdata, nettleserens DOM, legitimasjon og autentiseringsfaktorer er forbudt i databaseposter, revisjonsoppføringer, logger, sanntidshendelser og feilrapporter.

Hva en operatør gir, og hvordan de tar det tilbake

Tillatelse til å bruke en executor er ikke én bryter. En agent kan kalle en operasjon bare når den har en tilgang for den nøyaktige executoren og den nøyaktige operasjonen, og den vanlige logiske verktøypolicyen tillater det, og kjøringens omfang stemmer, og maskinens egen lokale policy tillater det. Å gi én executor en operasjon gir derfor ingen rettigheter på en annen. En oppdatering av egenskaper kan heller ikke utvide noe, fordi nye operasjoner kommer inn avslått.

Agenttilgang og deling trer begge i kraft umiddelbart på selve siden, uten godkjenningssteg, passordforespørsel eller ny autentisering. På executorens fane Agenter slår en leder en agents tilgang til maskinen av eller på direkte. Under Deling gir de en person Kan bruke eller Admin, eller utvider bruk til et prosjekt eller til alle i det nåværende teamet, på samme måte. I din egen assistentsamtale kan assistenten i stedet forberede en endring av agenttilgang eller tildeling. Dette gjelder bare der, aldri i en delt kanal, en planlagt jobb eller en annen agents kjøring. Endringen legger et bekreftelseskort i samtalen. Ingenting endres før du trykker Gi tilgang på kortet, og chat-tekst er aldri en bekreftelse.

Tre endringer krever fortsatt at du skriver inn ditt nåværende passord på nytt i øyeblikket du bekrefter: å aktivere en deskriptorrevisjon, en assistent-forberedt tildeling som gir en person, ikke en agent, maskinen, og en fast policy som lar kolleger starte kommandoer på maskinen som eieren, altså policyen for ubemannet oppgavearbeid. Å koble fra eller slette en maskin ber bevisst om ingen av delene, siden en nødbryter aldri må være vanskeligere å nå enn det den stopper. Overføring av et gjennomgått utkast krever alltid passordet. Revisjonsloggen registrerer den handlende personen og assistentens involvering hver for seg.

En executor går gjennom et lite, eksplisitt sett med tilstander:

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

Menyen Maskin i toppfeltet er der en leder forbereder hver livssyklusendring: sette på pause, gjenoppta når den er på pause, koble fra eller slette den. Pause lar executoren være på nettet, men stopper den fra å ta imot kommandoer. Frakobling ugyldiggjør dens klientsertifikater og alle utestående kandidathåndtak, og kan ikke angres. En frakoblet executor må paires på nytt som en ny. Sletting gjør det samme og fjerner i tillegg executoren fra listen. I motsetning til frakobling tilbys sletting uansett executorens tilstand, også ventende paring og allerede frakoblet, fordi det er den eneste måten å forlate listen på. Tømming er en reell tredje tilstand i protokollen: å fullføre arbeidet den allerede har, før den slutter å ta imot mer. Grensesnittet kan vise en maskin i den tilstanden, men ingenting her starter en. Bare et direkte kall til API-et gjør det. Hver bekreftet tilgangsendring, deskriptorgjennomgang og livssyklusovergang, tømming inkludert, øker også daemonens forbindelsesepoke. Daemonens neste kontrollavstemning, høyst ett sekund senere, feiler lukket og stopper hver aktive gjest før den kan koble til igjen. Tilbakekalling er ikke noe maskinen kan velge å ignorere.

Drift av en executor

Sjekke at den er frisk

Nessies eget svar er livstegn. En daemon signerer et heartbeat. En executor hvis siste autentiserte aktivitet er eldre enn seksti sekunder, merkes varig som frakoblet før den kan vises i lister, velges eller få utsendt arbeid. En executor som vises som tilkoblet, har bevist seg selv i løpet av det siste minuttet.

Det finnes ingen helseendepunkt på maskinen. Daemonen lytter ikke på noen port som en operatør kan nå, med vilje. På macOS og Linux spør du CLI-en direkte:

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

På macOS viser statusen hvert teams launchd-agent. systemctl-kommandoen gjelder bare Linux. På Windows er ikonet i systemstatusfeltet det raske svaret, menyen angir årsaken, og tjenestens logg har detaljene. På begge plattformer viser executorens fane Oversikt i Nessie dens godkjente profiler, datagrensen, når den sist ble sett og eventuelle ventende lokale policyforslag som venter på gjennomgang.

Logger

Hver avvisning en person kan handle på, havner der: en usignert eller manipulert kjøretid, en tilstandsmappe som ikke kan sikres, en executor som ikke startet ved oppstart. Det som aldri havner der, er en paringsutfordring, en nøkkel eller utdata fra en underordnet prosess. Det finnes ingen loggnivåinnstilling å skru opp, fordi det ikke finnes noe mer detaljert å slå på.

Mac-CLI-en skriver hvert teams tjenestelogg til ~/Library/Logs/NessieExecutor/<executorId>.log.

Oppgradering

Oppgrader CLI-en via Homebrew, APT eller DNF, og start så hvert teams tjeneste på nytt med disable etterfulgt av enable. WinGet oppgraderer Windows-executoren. Direkte Nessie Desktop-installasjonsprogrammer tilbyr signerte oppdateringer i appen. MSI- og Debian-installasjoner bruker sin pakkebehandler. Paringer og lokale tillatelser består oppgraderinger.

Stopp og fjerning

Stopp er en kontrollert avslutning som daemonen selv eier, ikke en kill. Den mottar et terminasjonssignal, stopper hver gjestøkt, frigjør leien sin og avslutter. På Linux venter enheten femten sekunder på et opprydningsbudsjett på ti sekunder, og eskalerer aldri til et ukontrollerbart kill. Grunnen er at en daemon som blir drept midt i opprydningen, etterlater en mikro-VM og et arbeidsområde-overlay uten noen prosess igjen til å rydde opp i dem. Et stopp som henger, er derfor synlig i systemctl --user status i stedet for stille. Eskalering er en uttrykkelig menneskelig beslutning.

For å fjerne Linux-pakken:

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 stopper og fjerner msiexec /x tjenesten, dens registeroppføringer og oppstartsoppføringen for systemstatusfeltet. På begge plattformer blir den sammenkoblede tilstanden med vilje værende igjen: ~/.local/state/nessie-executor/ på Linux og %ProgramData%\Nessie Executor på Windows. En paring er en maskinnøkkel og en signert policyrevisjon. Avinstallering av et program er ikke en forespørsel om å ødelegge dem, og en ny installasjon finner dem der de var. Slett katalogen manuelt for å glemme en paring. Tilbakekall executoren i Nessie for å avslutte den fra den andre siden.

Systemstatusfeltet på Windows og skrivebordskomponenten tilbyr begge Glem paringen på denne maskinen som en førsteklasses handling. Den stopper den lokale daemonen, fjerner maskinnøkkelen og mappevalget, og sletter de lokale utkastkopiene permanent etter én bekreftelse i det native dialogvinduet. Den serverbaserte executoren og dens revisjonshistorikk beholdes for en eier å beholde eller tilbakekalle.

Vanlige feil