AI-agentdelegering – du kan ikke delegere det du ikke kontrollerer

Jeg har gravd i agentidentitet, autentiserings-/autorisasjonsmønstre og hvordan det passer inn i eksisterende teknologi (OAuth 2.0, OIDC, SPIFFE, etc) og hvor det kan trenge nye løsninger. Noen gjorde et poeng rundt identitet og delegering til meg nylig som skinner litt av virkeligheten på dette området:

You can’t delegate what you don’t control.

Det vil si at AI-agenter avslører sprekker eller udefinerte områder i autorisasjonsgrunnlaget vårt raskere enn vi kan dekke dem.

La oss gå gjennom hva som faktisk går galt.

Identitet er et rot – og det er å være sjenerøs

Tenk deg at Sarah er markedssjef i en mellomstor bedrift. Hun logger seg på den bærbare datamaskinen (ved hjelp av Active Directory/LDAP). Hun gjennomgår data, og kjører kampanjer i Salesforce og HubSpot. Hun får tilgang til interne rapporter gjennom et internt analysedashbord. Et sted tidligere ga noen henne tilgang til en AWS S3-bøtte for å migrere noen data for et prosjekt. Ingen husker det. Sarah gjør sannsynligvis ikke det heller.

Så hvemerSarah?

I teorien, når en AI-agent handler «på vegne av Sarah», vil vi at den skal arve tillatelsene hennes. Men det forutsetter at det er en enhetlig idé om «Sarah» som systemet forstår.

I praksis er «Sarah» spredt over et halvt dusin systemer, hvert med sin egen pålogging, autorisasjonslogikk og roller. Identiteten hennes er ikke en person, det er et lappeteppe av artefakter som driver/råtner over tid. Det er ikke noe rent grensesnitt å delegere fra. Ingen sammenhengende definisjon av hva «å handle på vegne av Sarah» betyr.

Dette er det første strukturelle problemet:

We don’t have real user identities

Vi har identitetsfragmenter, og agenter kan ikke delegere rent på tvers av fragmenter.

Hvem eier egentlig tilgang? Ingen og alle!

La oss si at vi beveger oss forbi identitet og stiller et vanskeligere spørsmål:

Who decides what an agent is allowed to do?

Ta kundedata. Eies det av salg? Markedsføring? Støtte? Lovlig?

Hvert team, og spredning av søknader, vil gjenspeile en lokal beslutning. I én app kan Sarah godkjenne kjøp på $5K. I en annen, $50K. Et annet sted har hun ingen grenser i det hele tatt. Det finnes ingen global sannhet. Bare en rekke frakoblede autorisasjonsbeslutninger bakt inn i kode, APIer, regneark og stammekunnskap.

Så når du bygger en agent for å få tilgang til kundedata eller bruke penger eller starte kampanjer på vegne av Sarah, hva arver den? Hvem setter grensene?

De fleste virksomheter kan liste opp hvilke brukerehatilgang til en ressurs, men svært få kan forklare hvorfor de har det, hvor den politikken er definert, eller hvem som er ansvarlig for den.

Dette er det andre store problemet:Autorisasjon er ikke regulert. Og hvis ingen eier tilgang, hvordan kan du trygt delegere den?

Agenter bryter IAM i en skala vi ikke er klare for

Det tredje problemet handler ikke om korrekthet, det handler om skala.

IAM-systemer ble designet for en verden av mennesker. HR legger til noen få ansatte hver måned. Kanskje en entreprenør kommer om bord. Legitimasjon klargjøres og tilbakekalles i sykluser som mennesker kan håndtere.

Se for deg en verden der et AI-system spinner opp tusenvis av flyktige agenter hver time. Hver agent trenger legitimasjon for å kalle API-er, godkjenne til tjenester, lese fra databaser og oppdatere systemer. De fleste av dem lever bare i noen få minutter. AI-copiloter for utviklere, markedsførere og støtterepresentanter blir innebygd i hvert verktøy. Disse agentene ikke bare leser, de handler.Og de vil prøve alle tillatelser du gir dem.

Eksisterende IAM-systemer kan rett og slett ikke holde tritt. Hemmeligheter kan ikke utstedes raskt nok. Og selv om de kan, vil du at de skal dele ut statiske, langvarige passord? Legitimasjonen henger igjen. Tilbakekalling går for sakte. Det verste av alt er at det ikke er noen kontekstuell struping på hvilke agenterburdevære i stand til å gjøre i utgangspunktet.

Vi bruker verktøy i menneskelig skala for å løse problemer i maskinskala. Det fungerer ikke.

Så hvor begynner vi?

Til tross for alt dette, organisasjonerboksBygg nyttige, sikre AI-agenter i dag. Men de må være strategiske når det gjelder omfang.

Start med etterligning av ett system

Den mest praktiske tilnærmingen akkurat nå er å holde seg innenfor ett enkelt system. La agenten arve brukerens legitimasjon og jobbe innenfor kjente rekkverk.

For eksempel kan en ingeniørs Kubernetes-token brukes av en feilsøkingsagent. En salgsagent kan bruke brukerens Salesforce-legitimasjon til å oppdatere salgsemner. En DBA kan starte en optimaliseringsagent som opererer innenfor de kjente begrensningene i databasen.

Ingen fancy delegasjon. Ingen identitetssøm på tvers av systemer. Bare praktisk verdi innenfor en pålitelig grense.

Utvid gradvis til multisystemagenter

Etter hvert som organisasjoner bygger tillit, kan de strekke disse grensene.

Du har kanskje en markedsføringsagent som bruker Sarahs Salesforce-token til å hente potensielle kunder, HubSpot-legitimasjonen hennes for å kjøre en kampanje og Google Analytics-tilgangen hennes til å generere en rapport.

Ja, det er fortsatt legitimasjonsspredning. Men det fungerer. Og den gir umiddelbar verdi samtidig som den respekterer eksisterende godkjenningsgrenser. På solo.io, der jeg jobber, jobber vi med løsninger for å gjøre dette renere.

Sikt på delegering senere, når du er klar

Etter hvert, etter hvert som bedrifter modner IAM-praksisen sin, vil de kunne støtte reell delegering på tvers av systemer. Det betyr konsekvent identitet, styrt autorisasjon, skalerbar legitimasjonsadministrasjon og kontekstbevisste retningslinjer.

Men det er ikke noe du begynner med. Det vil si noe du tjener ved å løse de grunnleggende problemene først. Når du er klar, er det noen interessante delegeringsmønstre (OAuth RFC 8693) og distribuert identitet og delegering (MCP-I) Det kan være nyttig.