Sikkerhed by Design: Sådan Holder Assembly Line Protocol AI-Agenter i Skak
Der er en god grund til, at de fleste organisationer ikke har ladet AI-agenter i nærheden af produktionssystemer. Det er ikke skepsis over for AI'en — det er en fornuftig frygt for, hvad der sker, når et ikke-deterministisk system får privilegeret adgang. En agent, der kan læse din database, kan misforstå instruktioner. En agent, der kan pushe til produktion, kan pushe det forkerte. Konsekvensen er ikke et lidt forkert svar. Det er en irreversibel handling.
Assembly Line Protocol (ALP) er vores svar på det problem. Ikke med adgangskontrolregler, der er hæftet på efterfølgende — men med en arkitektur, hvor sikkerhedsegenskaberne følger direkte af strukturen.
Den centrale indsigt: privilegium og ikke-determinisme er omvendt fordelt på tværs af de fire lag.
Laget med mest adgang er det mest deterministiske. Laget, der må improvisere, har mindst adgang. Det er ikke en politik. Det er systemets form.
De Fire Lag
Server — Task Queue'en
Serveren er der, hvor arbejde kommer ind i systemet. Det er en task queue: en liste over ting, der skal laves, med en titel, en beskrivelse og lidt metadata. Det er det hele.
Serveren har nul sensitiv adgang. Den har ingen credentials, kan ikke eksekvere noget, og er ligeglad med, hvordan opgaver bliver løst. Du kan implementere den oven på, hvad end du allerede bruger til projektledelse — Jira, Azure DevOps, GitHub Issues eller en brugerdefineret service. ALP definerer protokollen; du bringer backloggen.
Fordi Serveren ikke har privilegeret adgang, er den en sikker inputzone. Alle kan indsende en opgave. Det værste en dårligt udformet opgave kan gøre, er at forvirre de efterfølgende trin — og de trin er designet til at håndtere det.
Runner — Privilegeret men Deterministisk
Runneren er der, hvor tingene faktisk sker. Den har adgangen: credentials, netværk, evnen til at provisionere sandboxes, evnen til at nå dine produktionssystemer, hvis du konfigurerer det sådan. I referenceimplementeringen er det pks-cli — open source, muligt at auditere.
Men Runneren improviserer aldrig. Der kører ingen sprogmodel inde i Runneren. Den poller Serveren for opgaver, evaluerer transitionsregler, provisionerer sandboxes, injicerer credentials, router output og flytter opgaver mellem stationer. Hvert trin er deterministisk kode. Du kan læse det, ræsonnere over det og forudsige dets adfærd.
Det er den afgørende egenskab: den mest privilegerede komponent i systemet er også den mest forudsigelige. En ingeniør, der gennemgår Runnerens adfærd, behøver ikke gætte på, hvad den måske beslutter — den følger sine regler, hver gang.
Operator — Protokolhåndhæveren
Operatoren kører inde i den sandbox, Runneren stiller til rådighed. Det er laget mellem Runneren og Agenten, og dens job er deterministisk protokolhåndhævelse.
Operatoren kommunikerer med Runneren over ALP spec-protokollen — en typet kontrakt, der præcist definerer, hvilke beskeder der kan flyde i hvilken retning: opgaveparametre ind, statusopdateringer og resultater ud. Operatoren validerer, at alt, Agenten producerer, overholder denne kontrakt, inden det forlader sandboxen.
Operators er pluggbare og kan implementeres af tredjeparter. ALP Operator-spec'en er en offentlig grænseflade, ikke en intern detalje. vibecast er reference-Operatoren — den ved, hvordan man driver Claude Code. Et andet team kunne bygge en Operator, der driver Codex, GitHub Copilot CLI eller en anden agent runtime. Hver Operator erklærer en capability spec: hvilke agenter den understøtter, og hvad den kan instruere dem til at gøre.
Det betyder, at tillid er eksplicit. Du stoler ikke bare på "AI-agenter" i det abstrakte. Du vælger en specifik Operator, du ved, hvilke agenter den driver, og du ved, hvilken protokolflade den eksponerer. Hvis du ikke stoler på en Operator, bruger du den ikke.
Agent — Ikke-Deterministisk men Indeholdt
Agenten — Claude Code, Codex, Copilot CLI, hvad end du har sat op — er der, hvor den faktiske intelligens bor. Den læser opgaven, ræsonnerer over den, skriver kode, kører værktøjer og producerer output. Den er ikke-deterministisk by design: det er præcis det, der gør den nyttig.
Men Agenten er den mindst privilegerede komponent i kæden. Den opererer inde i sandboxen. Den kan kun kommunikere gennem Operatorens protokolflade. Den kan ikke direkte nå Runneren, kan ikke ændre opgavets tilstand og kan ikke eskalere sine egne tilladelser. Ethvert output, der ikke overholder Operatorens forventede protokol, afvises, inden det forlader sandboxen.
Agenten må være kreativ inden for et præcist afgrænset rum. Det er ikke en begrænsning — det er det, der gør det sikkert at deploye.
Inversionen
Animationen øverst viser det direkte. Uden for sandboxen sidder den mest privilegerede komponent i systemet — uden en eneste sprogmodel i nærheden. Inde i sandboxen sidder LLM'en, med det laveste privilegieniveau af alle lag.
Grænsen mellem Runneren og Operatoren er en sikkerhedsgrænse, ikke bare en arkitektonisk grænse. Inden for den grænse er systemet sandboxet, protokolbegrænset og overvåget. Det eneste, der krydser den, er struktureret output, som Runneren eksplicit accepterer.
Hvorfor Det Virker
Traditionelle tilgange til AI-agentsikkerhed forsøger at tilføje sikkerhedsforanstaltninger omkring en agent, der allerede har adgang. Du får en liste over tilladte værktøjer, et prompt injection-filter, et sæt regler, agenten formodes at følge. Det er alle runtime-politikker, der håndhæves af det samme system, du forsøger at begrænse.
ALP tager den modsatte tilgang. Sikkerhed håndhæves ikke på Agenten — det er strukturelt umuligt for Agenten at overtræde, fordi arkitekturen ikke giver den midlerne til det. Agenten kan ikke nå produktionscredentials, fordi den er i en sandbox. Den kan ikke pushe dårligt output til Runneren, fordi Operatoren validerer protokollen. Den kan ikke eskalere sine egne tilladelser, fordi Operatoren ikke har nogen at eskalere.
Trusselmodellen er ærlig: en AI-agent vil på et tidspunkt gøre noget uventet. Spørgsmålet er, om din arkitektur begrænser eksplosionsradius. ALPs svar er, at det uventede sker inde i en sandbox, valideres af en deterministisk Operator, inden det forlader den, og routes af en deterministisk Runner, der har eksplicitte regler for, hvad der sker som det næste.
Byg på ALP
Protokollen er designet til at være lige så nem at adoptere som MCP. Serveren er bevidst overladt til dig — implementer den oven på, hvad du allerede bruger til opgavestyring. Runneren (pks-cli) er open source: læs den, fork den, auditér den. Operator-spec'en er offentlig: byg din egen, hvis du har en anden agent runtime eller specifikke capability-krav.
Målet er en verden, hvor det at køre AI-agenter i produktion ikke kræver blind tillid til en black box. Du kan inspicere hvert lag, forstå hver grænse og ræsonnere over, hvad der sker, når noget går galt.
Det er sikkerhed by design — ikke sikkerhed by hope.
Assembly Line Protocol er udviklet af agentics.dk. Reference-Runneren (pks-cli) og Operatoren (vibecast) er open source.
