Tines 3B skriver koden, men modellen ser aldri API-nøkkelen

Kodeagenten din må ha legitimasjon for å nå noe som helst utenfor seg selv, og den legitimasjonen havner som regel i en .env-fil eller et kodelager. Tines har snudd på det i 3B: nøkkelen finnes, men koden modellen skrev leser den aldri.

XDA Developers har hatt tilgang til plattformen en periode og bygget tre ting med den, blant annet et overvåkingspanel for hjemmelabben. Å beskrive hva panelet skulle gjøre tok rundt tjue minutter, medregnet rundene det tok å få en første versjon som faktisk kjørte. Resultatet ble seks steg: en innsamler på to minutters cron, en evaluator som holder tilstand per betingelse slik at et vedvarende problem sender én e-post i stedet for én hvert andre minutt, selve e-poststeget, to API-endepunkter og et React-panel med trendgrafer.

Arkitekturen er poenget. Hvert steg får sin egen undermappe med kode, en config.toml og sin egen Dockerfile, altså sin egen container. I panelet XDA bygde er innsamleren og evaluatoren Python på en frittstående CPython med avhengigheter hentet av uv, mens e-poststeget og begge endepunktene er TypeScript på Bun. Stegene snakker sammen over stdin og stdout. Kobler du ett steg til tre andre, får alle tre samme inndata og kjører parallelt.

Legitimasjonen bor i det Tines kaller en connector, konfigurert langt unna selve arbeidsflyten. Når et steg kaller ut, injiseres nøkkelen i forespørselen av en proxy som sitter utenfor kjøremiljøet. Den genererte koden sier det rett ut i sin egen dokumentasjonsstreng:

«Credentials are injected by the connector attached to this step, so requests are made plain.» — TrueNAS-adapteren generert av Tines 3B

Konsekvensen er konkret. En modell som blir prompt-injisert av en side den nettopp hentet, har ingenting å eksfiltrere. Den kan bruke en nøkkels autoritet mot en tjeneste den har lov til å nå, men ikke lese nøkkelen selv. På toppen ligger en URL-allowlist: Gmail-connectoren slipper gjennom de to Google-vertene Gmail faktisk bruker, avgrenset til Gmails egne API-stier, ikke hele googleapis.com. At problemet er reelt, illustrerer XDA med tall fra Lovables markedsplass, der omtrent én av ti av 1 645 publiserte apper lekket brukerdata gjennom en autorisasjonsfeil.

Under det igjen ligger sandkassen.

«Every step runs in a completely isolated environment, executes, and then disappears.» — Tines, gjengitt av XDA Developers

En vanlig container ville ikke holdt til den påstanden, siden namespaces og cgroups fortsatt lar prosessen gjøre systemkall rett inn i samme kjerne som naboene bruker. Svaret XDA fikk er et egenbygd miljø på gVisor, Googles sandkasse, som implementerer en kjerne i userspace og fanger opp systemkall før de treffer den ekte.

Plattformen har skarpe kanter. Du kan laste ned all koden, men den kjører ikke uendret: hvert steg sender rene HTTP-forespørsler og forventer at noe annet henger på legitimasjonen, så autentiseringen må settes inn igjen i én identifiserbar del av hver adapter. Gratisnivået stopper ved 50 dollar i KI-kreditt og tre aktive arbeidsflyter, og første betalte nivå starter på et sekssifret beløp. Og en NAS som 3B ikke får koblet seg til, får ikke du koblet til heller, nettopp på grunn av sikkerhetsmodellen.

Hva bør du gjøre?

1. Studer connector-mønsteret uavhengig av om du bruker Tines. En proxy som injiserer legitimasjon utenfor kjøremiljøet er noe du kan bygge selv foran dine egne agenter.
2. Regn med eksportjobben før du forplikter deg. Koden er portabel fordi den ikke bærer hemmeligheter, men autentiseringen må legges tilbake i hver adapter.
3. Sjekk prisnivået tidlig hvis prosjektet skal vokse. Spranget fra gratisnivået til første betalte nivå er stort.