Cybersikkerhetsstrategier for utvikling av KI-agenter med lavkode og høykode

Når organisasjoner tar i bruk KI-agenter på tvers av forretningssystemer, blir utviklingshastighet og sikkerhetsoppfølging tett forbundet. Cybersikkerhetsstrategier for utvikling av KI-agenter med lavkode og høykode må ta høyde for hvordan hver tilnærming gir tilgang til informasjon og gjør det mulig å utføre handlinger. Målrettede sikkerhetstiltak kan håndtere disse forskjellene, samtidig som felles styring sørger for at agentenes aktivitet holder seg innenfor godkjente oppgaver etter hvert som utrullingen øker.

Hva skiller utvikling av KI-agenter med lavkode fra utvikling med høykode

Lavkodeplattformer lar utviklere sette sammen agenter ved hjelp av visuelle grensesnitt og forhåndsbygde koblinger som knytter sammen forretningstjenester. Høykodeutvikling gir programmerere større frihet til å definere agentenes atferd gjennom tilpasset kode, verktøyintegrasjoner og kjøremiljøer. Begge tilnærmingene krever oppfølging av hvilken informasjon agentene får tilgang til, og hvilke handlinger de kan utføre.

Sikkerhetsansvaret varierer fordi kontrollen ligger på ulike steder. Utviklere som bruker lavkode, arbeider innenfor plattforminnstillinger som styrer deling og tilgang til koblinger, og derfor er konfigurasjonsvalgene spesielt viktige. Høykodeteam har større ansvar for programvaren og miljøene som utfører instruksjonene til agentene, inkludert begrensninger for tilgang til filer og påloggingsopplysninger.

The Cybersecurity and Infrastructure Security Agency peker på flere risikoer knyttet til agentisk KI som gir et nyttig rammeverk for begge tilnærmingene. En utvidet angrepsflate innebærer flere inngangspunkter, mens gradvis utvidelse av tilgangsrettigheter viser til at tilgangen hoper seg opp. Atferdsmessige avvik innebærer at agentene går utenfor de tiltenkte oppgavene, og uklare hendelseslogger gjør etterforskning vanskeligere. En mye brukt kobling og et kommandolinjeverktøy uten begrensninger kan føre til ulike varianter av de samme problemene.

Sikkerhetsrisikoer og tiltak for KI-agenter med lavkode

Lavkode gjør det enkelt for ansatte utenfor tradisjonelle utviklingsteam å lage agenter. Sikkerhetsoppfølgingen må også omfatte disse utviklerne, slik at praktiske koblinger brukes i tråd med godkjente forretningsformål.

Sikkerhetsbegrensninger i lavkodemiljøer

Utviklere uten formell programmeringsbakgrunn kan koble en agent til delte filer eller forretningsapplikasjoner uten å forstå agentens tillatelser fullt ut. Tilgang som gis gjennom disse koblingene, kan føre til at sensitiv informasjon eksponeres eller gjøre det mulig å utføre handlinger som går utover den tiltenkte arbeidsflyten. Omfattende deling og uklart eierskap kan forsterke denne eksponeringen.

Omfanget av innføringen gjør det viktig å sørge for konsekvent oppfølging på tvers av avdelinger. I en markedsanalyse fra 2024 rapporterer Forrester at 87 % av utviklerne i store virksomheter bruker lavkodeplattformer i deler av utviklingsarbeidet. Dette funnet gjelder utvikling generelt. Det viser derfor hvor utbredte plattformene er, men måler ikke spesifikt hvor mange som tar i bruk KI-agenter.

Praktiske tiltak for å styrke sikkerheten til lavkodeagenter

Team bør gå gjennom koblingstillatelsene for hver agent opp mot agentens tildelte oppgave og følge prinsippet om minste privilegium. Et sentralt register bør inneholde ansvarlig eier og tilknyttede tjenester for hver utrulling, og sensitive handlinger bør kreve godkjenning. Dette gir sikkerhetsteamene et grunnlag for å identifisere uregistrerte agenter og undersøke upassende tilgang.

Microsofts tilnærming til datastyring legger vekt på kontrollert tilgang til forretningsinformasjon. Naveen Jangir, ledende arkitekt hos Microsoft Digital, anbefaler at organisasjoner «styrer og beskytter informasjonen med hensiktsmessige tilgangsbegrensninger». Disse kontrollene gjør det mulig for autoriserte brukere og KI-funksjoner å bruke den uten unødvendig eksponering innenfor etablerte tilgangsgrenser. Ved å kombinere retningslinjer for koblinger med tydelig ansvarlig eierskap kan disse begrensningene bli en del av det daglige utviklingsarbeidet.

Sikkerhetsrisikoer og tiltak for KI-agenter med høykode

Når team bruker KI-kodeagenter til å bygge tilpassede systemer, kan genererte endringer komme raskere enn folk rekker å gjennomgå dem. Sikkerhet ved høykodeutvikling krever derfor kontroll både over utviklingsprosessen og over miljøene der agentene utfører oppgaver.

Særlige sikkerhetsutfordringer ved høykodeutvikling

Kodeagenter kan utsettes for indirekte promptinjeksjon når de leser eksterne kodearkiver som inneholder instruksjoner fra en angriper. Hvis en agent følger slike instruksjoner samtidig som den har tilgang til utviklingsverktøy, kan den kjøre usikre kommandoer eller eksponere påloggingsopplysninger. De mulige konsekvensene avhenger delvis av hvilke filer, verktøy og eksterne mål kjøremiljøet gir agenten tilgang til.

NVIDIAs veiledning om sandkasseisolering tar for seg eksponering av påloggingsopplysninger innenfor denne kjøremiljøgrensen. Der står det at «sandkassemiljøer bør basere seg på eksplisitt innsetting av hemmeligheter» for å begrense tilgangen til påloggingsopplysninger. Agenter bør ikke arve alle påloggingsopplysningene fra miljøet når oppgavene deres bare krever begrenset tilgang. Team bør opprette påloggingsopplysninger for den spesifikke oppgaven og sørge for at uvedkommende hemmeligheter forblir utenfor agentens rekkevidde.

Strategier for å styrke sikkerheten i agentpipelines med mye kode

Begrensede kjøringsmiljøer bør begrense filtilgang og utgående tilkoblinger i tråd med oppgaven. Team bør også utføre statisk applikasjonssikkerhetstesting av generert kode. Uavhengige kontrollører bør undersøke autorisasjonsbeslutninger eller forretningslogikk som automatiserte kontroller kan overse. Disse lagene håndterer grensene for kjøringsmiljøet og svakheter i den resulterende programvaren.

Amazon Web Services anbefaler å skille kodegenerering fra evaluering i rammeverket sitt for kontroller av kodeagenter. De påpeker at «en separat økt bidrar til å unngå bekreftelsesbias».kan ha de samme underliggende blindsonene under gjennomgangen, selv om begge øktene bruker samme modell. Når det er praktisk mulig, kan en annen modell for gjennomgang og menneskelig vurdering av sikkerhetsfølsomme endringer gi ytterligere granskning.

Å utforme en sikkerhetsstrategi som dekker begge tilnærmingene

KI-sikkerhet i utvikling av agenter med lavkode og mye kode krever et felles overblikk over aktiviteten der agenter utveksler informasjon. En arbeidsflyt med lavkode kan for eksempel sende innhold til en egenutviklet agent, som deretter kaller en annen forretningstjeneste. Hvis hver komponent vurderes separat, kan sikkerhetsteam mangle konteksten de trenger for å forstå hele hendelsesforløpet.

KI-sikkerhetsekspertene hos Darktrace mener at organisasjoner må undersøke ledetekster og økter i tillegg til svarene, på tvers av generative KI-verktøy for bedrifter og begge utviklingstilnærmingene. Perspektivet deres omfatter også miljøer for programvare som tjeneste og sikker tilgang via tjenesteedge. Med dette innsynet får organisasjoner kontekst som gjør at «de kan oppdage sofistikerte samtalebaserte promptangrep og ondsinnet kjeding».

Darktraces syn støtter en bredere KI-sikkerhetsstrategi for utvikling av agenter med lavkode og mye kode, fordi innsyn i ledetekster, overvåking av økter og kontroll med identiteter hjelper team med å forstå hvordan agenter samhandler på tvers av tilkoblede verktøy. Sikkerhetsteam bør undersøke hvordan instruksjoner endres gjennom sammenkoblede økter, og om påfølgende handlinger fortsatt er i samsvar med den opprinnelige autorisasjonen. De bør også vurdere hvor sensitiv informasjonen som oppbevares for undersøkelser, er.

Styring og overvåking for langsiktig sikkerhet for KI-agenter

Hver agent bør ha en ansvarlig eier og et definert omfang av tillatt arbeid, uansett hvordan den er utviklet. Styringen bør også angi hvem som kan godkjenne endringer i dette omfanget, og hvem som kan stanse aktiviteten hvis en agent oppfører seg uventet.

Forskning på agentstyring tyder på at agenter trenger myndighet som kan autentiseres og revideres for å sikre slik ansvarliggjøring. Denne tilnærmingen knytter personen som gir tillatelsen, til oppgavene en agent kan utføre. Organisasjoner kan dermed kontrollere en handling opp mot denne autorisasjonen.

Team bør føre aktivitetslogger som knytter delegerte tillatelser til verktøybruk og resultater. Regelmessige gjennomganger bør ta opp disse tillatelsene på nytt etter hvert som funksjonaliteten endres, fjerne tilganger som gjenstår etter fullført arbeid, og bekrefte at eierforholdet fortsatt er oppdatert. Utviklings- og sikkerhetsteam kan bruke disse gjennomgangene til å sikre at operative kontroller fortsatt samsvarer med agentens godkjente formål.

Hold tritt med sikkerhetsrisikoene knyttet til KI-agenter

Utvikling med lavkode krever nøye styring av plattformtillatelser og koblinger, mens utvikling med mye kode krever særlig oppmerksomhet på tilpassede kjøringsmiljøer og kodegjennomgang. Sentralisert overvåking og tydelig ansvarliggjøring gir et felles grunnlag for å følge med på hvordan agenter får tilgang til informasjon og handler på tvers av tilkoblede forretningssystemer. Etter hvert som funksjonaliteten utvides, bør utviklere vurdere sikkerhetstiltakene på nytt i takt med endringer i agentenes verktøy og ansvarsområder, slik at det er tydelig hvilke aktiviteter som er tillatt for hver utrulling gjennom hele livssyklusen.