Noget stille, men betydningsfuldt skete i enterprise-software det seneste år. De store platformleverandører - Microsoft, AWS, Google, Salesforce, SAP, ServiceNow - blev enige om en fælles måde for AI-agenter at tale med hinanden på. Konkurrerende forslag blev slået sammen til ét. I praksis er standarden på plads.
Overfladisk set er det gode nyheder. Det betyder, at en agent finance bygger kan overlevere arbejde til en agent indkøb har bygget, som igen kan nå en agent hos en leverandør. Ingen skræddersyet integration for hvert par. De finder hinanden, udveksler opgaver og kommer i gang.
Hvis du har ansvar for sikkerhed eller teknologi i organisationen, burde det sidste afsnit gøre dig lidt urolig. Ikke fordi teknologien er dårlig - men fordi den besvarer et spørgsmål, du ikke var bekymret for, mens et større spørgsmål står helt åbent.
Interoperabilitet løser “kan de tale sammen.” Den løser ikke “skal de.”
Den nye standard er meget god til at lade agenter forbinde. Den siger næsten intet om governance. Når agenter fra forskellige teams, leverandører og clouds frit kan nå hinanden, skal nogen kunne besvare tre spørgsmål til enhver tid:
- Hvem må ringe til hvem?
- Hvilke data må hver agent røre, når den gør det?
- Hvem dokumenterede, at det skete?
Det er ikke spørgsmål protokollen besvarer. Det er spørgsmål I besvarer - eller ikke. Og i det øjeblik jeres agenter kan nå ud over jeres egne fire vægge, bliver “eller ikke” en revisionsanmærkning, der venter på at ske.
En konkret version af problemet
Her er scenariet, der gør det virkeligt, uden tekniske detaljer.
En agent dukker op og præsenterer sig for jeres systemer som agenten tilhørende en betroet leverandør. Den kommer med credentials - papirarbejde, effektivt - der siger “jeg er den, jeg påstår mig for at være.” Jeres agenter er konfigureret til at stole på den leverandør. Så den nye agent får deltage: den kan få opgaver, bede om data, handle.
Spørgsmålet, der afgør, om I har et sikkerhedsprogram eller et ansvar, er enkelt: verificerer jeres system faktisk, at papirarbejdet blev udstedt af leverandøren - eller tager I agentens ord for det?
En falsk introduktion er nem. En angriber kan præsentere en agent, der påstår sig at være jeres leverandør, og levere egne credentials, der understøtter påstanden. Et naivt system tjekker, at papirarbejdet er internt konsistent, ser at det er, og vinker agenten igennem. Bedrageren er nu inde i jeres workflow, betroet, og handler på rigtige data.
Et system bygget til governance gør det modsatte. Det behandler hver ekstern agent som ubevist, indtil identiteten er verificeret mod den part, den påstår sig at repræsentere - ikke mod credentials agenten selv har medbragt. Den rigtige leverandørs agent kommer ind. Bedrageren stoppes ved døren, og afvisningen skrives til en log, I kan vise en revisor.
Forskellen - at verificere identitet mod den påståede kilde, ikke mod den, der påstår sig selv - er hele forskellen mellem et åbent agentnetværk og en åben dør. Den er uglamorøs, usynlig når den virker, og det er det, de fleste teams endnu ikke har bygget.
”Kan vi ikke bare bruge vores cloud-leverandørs agentplatform?”
Det kan I. Flere tilbyder nu agentstyring med governance vedhæftet, og for en organisation, der lever helt inde i en cloud og med en AI-model, kan det være nok.
De fleste organisationer lever ikke så. Jeres agenter vil køre i mere end en cloud. De bygges på mere end en AI-model - fordi den bedste model til en opgave sjældent er den bedste til næste, og fordi at satse hele jeres agentstrategi på en enkelt AI-leverandør er den slags afhængighed, I kan fortryde resten af karrieren. Og i stigende grad skal jeres agenter interagere med agenter uden for organisationen.
Et governance-lag, der kun virker inden for en leverandørs mure, kan ikke se noget af det. Det styrer de agenter leverandøren hoster, på leverandørens model, og bliver blindt i det øjeblik en agent træder ud. Det er ikke governance - det er et hegn omkring en mark, mens flokken vandrer over tre.
Governance-laget, der faktisk beskytter jer, skal være neutralt: uafhængigt af hvilken cloud agenten kører i, uafhængigt af hvilken AI-model den er bygget på, og i stand til at anvende de samme identitetskontroller, adgangsregler og audit-spor på hver agent uanset hvor den kom fra. Neutralitet er ikke en feature her. Det er forudsætningen for, at hele satsningen er værd noget.
Det er ikke jeres brand i dag. Det bliver det snart.
Vær ærlig om timing. Hvis organisationen har tre agenter, og de alle kører samme sted, har I ikke problemet endnu. Den, der siger huset brænder, sælger noget.
Men retningen er ikke tvivlsom. Standarden er på plads, hver stor leverandør leverer understøttelse, og antallet af agenter i en typisk virksomhed går kun én vej. Teams, der tænker identitet, adgang og audit før spredningen, bruger en eftermiddag. Teams, der venter, bruger et kvartal på at få det udredt - sandsynligvis efter noget går galt.
Governance er dramatisk billigere at installere, før I har fyrre agenter, end bagefter. Det er hele argumentet. Ikke frygt - rækkefølge.
Hvad I skal spørge
I behøver ikke forstå protokollen for at stille de rigtige spørgsmål til den, der ejer jeres agentstrategi:
- Når en ekstern agent præsenterer sig for vores systemer, hvordan verificerer vi, at den er det, den påstår sig for at være - og verificerer vi mod kilden, eller stoler vi på dens egne credentials?
- Hvis vi skulle vise en revisor hver agent, der har rørt et givet datasæt, kunne vi det?
- Virker vores agent-governance på tværs af vores clouds og AI-modeller - eller kun inde i en leverandør?
- Kan vi besvare alt ovenstående i dag, eller kun i en præsentation?
Hvis svarene er solide, er I foran de fleste. Hvis ikke, er den gode nyhed, at opgaven er langt mindre nu end om et år.
Agenterne begynder at tale med hinanden uanset. Det eneste valg I har, er om nogen tjekker ID ved døren.
Brug for et neutralt governance-lag for agenter på tværs af clouds, modeller og leverandører? Fortæl om jeres setup i formularen nedenfor - vi går identitet, adgang og audit igennem ud fra jeres egen arkitektur.