Agent-governance i datalaget - EDB

Den klassiske model for it-sikkerhed bygger på, at et menneske eller et system godkender en handling, før den udføres. Det virker fint, når handlinger er få og langsomme. Men en agent, der er sat til at overvåge lagerbeholdning, opdatere kunderegistre eller trigge betalinger, arbejder ikke i det tempo. Den kan stille tusindvis af forespørgsler i løbet af en arbejdsdag, og hver enkelt godkendelse ville bremse hele formålet med at sætte agenten i drift.

Problemet er strukturelt, ikke et spørgsmål om bedre processer. Så snart kontrollen ligger uden for det system, agenten faktisk arbejder i, opstår der et gab mellem beslutning og handling. Det gab er præcis der, hvor fejl, misbrug og utilsigtede konsekvenser opstår, fordi ingen når at reagere, før skaden er sket.

Den praktiske konsekvens er, at en agent ikke længere kan behandles som en forlængelse af en brugers rettigheder. Den skal have sin egen identitet i systemet, ligesom en medarbejder eller en tjeneste har det. Det betyder et separat sæt tilladelser, et separat spor af, hvad den har gjort, og en klart afgrænset ramme for, hvad den overhovedet kan bede databasen om.

Det lyder som en teknisk detalje, men det ændrer hele modellen for ansvar. Når en agent er sin egen identitetsprincipal, kan man se præcis, hvilke handlinger der stammer fra den, adskilt fra de handlinger, en menneskelig bruger har foretaget under samme session eller integration. Det er en forudsætning for overhovedet at kunne undersøge en hændelse bagefter, og det er en forudsætning for at kunne begrænse skaden, mens den sker.

Når reglerne flytter ind i datalaget, betyder det konkret, at adgangskontrol, rate limits og valideringsregler defineres som en del af databasens eget regelsæt, ikke som noget en applikation eller et separat governance-lag skal huske at tjekke. Row-level security, roller med snævert afgrænsede rettigheder og indbyggede grænser for, hvor mange rækker en given identitet kan røre inden for et tidsrum, gør det muligt at stoppe en agent, der opfører sig forkert, i det øjeblik den overskrider sin ramme, uden at nogen skal opdage det manuelt først.

Det er en vigtig forskel fra den traditionelle model, hvor sikkerhed sidder i applikationslaget og kan omgås, hvis nogen finder en anden vej ind i databasen. Når reglen sidder i selve datalaget, gælder den uanset hvilken vej en forespørgsel kommer ind ad, og det lukker en af de mest almindelige svagheder i agent-arkitekturer: at kontrollen kun findes ét sted i kæden.

Det er ikke tilfældigt, at Postgres står centralt i den her udvikling. Databasen har i årevis bygget sit rettighedssystem ud med finkornet kontrol, og fordi det er åben kildekode, kan sikkerhedslag som row-level security, audit-udvidelser og skræddersyede politikker bygges direkte ind i databasen uden at vente på en leverandørs roadmap. Det giver virksomheder mulighed for at tilpasse governance-modellen til deres egne agenter, i stedet for at presse agenternes adfærd ind i en generisk skabelon fra en lukket platform.

Den åbne tilgang betyder også, at man kan revidere og verificere, hvordan kontrollerne rent faktisk virker, hvilket bliver stadig vigtigere, i takt med at flere agenter får adgang til produktionsdata. Man skal kunne stole på reglerne, ikke bare på leverandørens ord for, at de holder.

For virksomheder inden for finans, sundhed og offentlig forvaltning er den her udvikling ikke kun teknisk interessant. Det er en direkte forudsætning for overhovedet at kunne tage agenter i brug i systemer med persondata eller følsomme forretningsdata. Revisionsspor, adgangsbegrænsning og evnen til at bevise, hvad en agent har gjort og hvorfor, er ikke et nice-to-have i disse brancher. Det er det, en tilsynsmyndighed vil spørge om, hvis noget går galt.