Secure Portal
Oversikt
En skrivebordsassistent som leser en innlogget portal, der modellen kan foreslå en handling, men aldri utføre en.
Detaljer
At a glance
- Type prosjekt
- Lokal skrivebordsapplikasjon
- Min rolle
- Satte sikkerhetsmodellen, designet applikasjonen, og implementerte grensen og skallet rundt den.
- Kategori
- Systemer
- Status
- Under utvikling2026
Hva jeg gjorde
- Skrev de ti invariantene produktet holdes til, og setningen det aldri får si
- Plasserte sikkerhetsgrensen i kode modellen ikke når
- Designet økten, godkjenningsdialogen og eksportflyten
- Bygget den fiendtlige testportalen som prøver å slå den
Bygget med
- Rust: Regelmotoren, sladdingen og revisjonsloggen, den sikkerhetskritiske halvdelen
- Tauri: Skrivebordsskallet
- TypeScript: Grensesnittet og nettleserarbeideren
- Playwright: Styrer den isolerte Chromium-nettleseren
- SQLite: Oppføringer og eksporter, på brukerens egen maskin
- Ollama: Modellen, som kjører lokalt slik at ingenting forlater maskinen
Neste prosjekt
Virksom
Behovet
En bedrift lever på portaler den må logge seg inn i: leverandører, banker, offentlige registre. Informasjonen et menneske faktisk trenger derfra er ofte tjue tall spredt over førti sider, og å hente den ut er en time med kopiering ingen liker og alle av og til gjør feil.
En assistent kunne gjort det. Men en assistent inne i en innlogget portal er en assistent som står ved siden av knappene som legger inn bestillinger og endrer oppføringer, med en aktiv økt den ikke måtte gjøre seg fortjent til.
Beslutning
Modellen foreslår, koden godkjenner
- Bakgrunn
- Promptinjeksjon er ikke noe hypotetisk her. En leverandørs egen PDF, eller en linje tekst på en side, kan skrives for å instruere det som leser den. Er modellen den som avgjør hva som skjer videre, så er det portalens innhold som avgjør hva som skjer videre.
- Hva jeg bestemte
- Modellen kan bare be om ett navngitt verktøy fra en lukket katalog. Hver forespørsel går gjennom en regelmotor, skrevet i Rust, som svarer tillat, spør brukeren, krev ny innlogging, blokker, eller stopp økten. Det finnes ingen vei fra modellen til nettleseren i det hele tatt. Motoren er ikke avhengig av skallet, nettleseren eller noen modellleverandør, så den kan gjennomgås for seg.
- Avveining
- Hver ny evne må legges inn i katalogen og i regelverket for hånd, så produktet vokser saktere enn ett som lar modellen improvisere. Til gjengjeld snakker en side som prøver å gi den en instruksjon til noe som ikke kan handle.
En nettleser uten hukommelse
Applikasjonen åpner sin egen midlertidige Chromium, adskilt fra brukerens ekte nettleser. Den starter uten lagrede passord, utvidelser, autofyll, historikk eller eksisterende økter. Personen logger inn selv, for hånd. Assistenten kobles til først når de sier fra, og hele profilen slettes når økten er over.
Innloggingen har sin egen modus, og mens den er på er assistenten ikke bare uvirksom, men frakoblet: ingen forespørsel gjøres, ingen skjermbilder tas, ingenting på den siden leses. Applikasjonen ber aldri om passord, engangskode eller BankID. Det skrives inn i nettleservinduet og ingen andre steder, og den sier fra om det på den skjermen der noen ellers ville vært i ferd med å skrive det i feil felt.
Når regelmotoren vil ha et menneske, stopper alt og venter. Bare en uttrykt godkjenning utfører handlingen: et tidsavbrudd, et stopp, en blokkering eller en mislykket melding lar den ligge ugjort, så det finnes ingen vei der et tapt svar blir et ja. Hvert svar merkes med spørsmålet det hører til, slik at et sent klikk på en gammel dialog ikke kan godkjenne handlingen som står på skjermen nå. Og en nedlasting kan aldri forhåndsgodkjennes, fordi hver nedlasting skal gjennomgås.
Viser sitt eget arbeid
En økt går i seks steg: logg inn, velg portalen, sett oppgaven, se over den, kjør den, les resultatene. Et panel står ved siden av dem alle og sier hva som holder akkurat nå.
Det sier ikke stol på oss. Det teller. Mens noen logger seg inn melder det null forespørsler til modellen, null skjermbilder tatt, null øyeblikksbilder av siden; og det teller endringer gjort i portalen og handlinger som er blokkert mens assistenten jobber. Det er løpende summer fra økten som står foran deg, ikke påstander om produktet generelt.
Beslutning
Verifisert, håndhevet, eller ikke aktiv ennå
- Bakgrunn
- En sikkerhetssjekkliste med haker nedover siden er det enkleste i programvare å forfalske, fordi en hake ikke sier noe om når den sist var sann. De fleste produkter viser alle grønne fra det øyeblikket vinduet åpner.
- Hva jeg bestemte
- Hver sjekk har én av tre tilstander. Verifisert betyr at den ble målt i denne økten, og målingen vises. Håndhevet betyr at det er en regel koden holder og som ikke kan slås av. Ikke aktiv ennå betyr at den fasen ikke har startet, så det påstås ingenting om den, og de forblir grå og ikke grønne til de er ekte.
- Avveining
- Det betyr at panelet åpner overveiende ikke-grønt, som ser dårligere ut enn en vegg av haker. Det er også den eneste versjonen en sikkerhetsansvarlig kan lese: en sjekk som ennå ikke sier noe er verdt mer enn en sjekk som sier ja før den har kjørt.
De ti invariantene
- Modellen kan ikke utføre en nettleserhandling direkte, og en portaladapter kan ikke gå utenom regelmotoren.
- Innloggingsmodus kan ikke sende modellforespørsler i det hele tatt, så ingenting ser på mens et passord skrives.
- Informasjonskapsler og autentiseringshoder kan aldri legges inn i modellens kontekst.
- Automatikken kan ikke navigere til et opphav som ikke er godkjent, og en ukjent transaksjonshandling kan ikke godkjennes automatisk.
- Lokal modus kan ikke stille falle tilbake på skybasert inferens.
- En nettleserprofil kan ikke gjenbrukes etter at en økt er slettet.
- En eksport kan ikke inneholde et gjenkjent hemmelighetsmønster.
- Fjerninnhold fra portalen kan ikke kalle en systemkommando i skrivebordsskallet.
- Dette testes, det påstås ikke, og bygget feiler blankt hvis et forbudt oppstartsflagg for nettleseren dukker opp noe sted i treet.
- En bevisst fiendtlig testportal finnes for å prøve å bryte hver eneste av dem: falske kontroller, skjulte instruksjoner, en GET som endrer tilstand, søk over POST.
Beslutning
Takk nei til den bedre modellen
- Bakgrunn
- En skymodell ville vært merkbart bedre til å lese. Leverandørgrensesnittet ville tatt imot en uten videre, og stegene for sladding og kontekstminimering kjører allerede før hver forespørsel, så det var ikke et teknisk problem.
- Hva jeg bestemte
- Den ble avslått, og avslaget ble skrevet ned. Å sende sideinnhold til en skyleverandør ville flyttet en kundes innloggede portaldata bort fra maskinen og ut av kundens kontroll, noe som motsier produktets sentrale påstand og er en personvernbeslutning, ikke en teknisk. Lokalt forblir standard. Mellomveien som står åpen er sky bare til planlegging, som ser den innskrevne instruksjonen og aldri siden.
- Avveining
- Produktet er målbart dårligere til å avgjøre hvor det skal se videre, og det er dets svakeste område. Svaret på det er en deterministisk modus der koden velger ruta og modellen bare leser, framfor en bedre modell med et dårligere løfte.
Hvor det står
Seks faser er ferdige, inkludert pakking som kjører fra Finder uten noe oppsett. 341 tester går grønt, ved siden av en ende-til-ende-suite mot en ekte nettleser og direkte tester mot en lokal modell.
Den er ikke lansert. Det finnes ingen verifisert adapter for en ekte leverandørportal, ingen Windows-versjon, ingen kodesignering, og ingen uavhengig sikkerhetsgjennomgang, som prosjektets egen spesifikasjon gjør til en sperre for lansering og ikke noe som er kjekt å ha.
Produktet nekter også å si visse ting. Ikke null risiko. Ikke at applikasjonen ikke kan nå økten. Ikke garantert kun-lesing på ethvert nettsted. Det den vil si er den nøyaktige setningen: den bruker den innloggede økten til å navigere, og autentiseringshemmelighetene må aldri nå modellen, loggene, en server eller en annen nettleserprofil.