Når AI-agenter handler selv, hvorfor identitet ikke er nok
Enterprise AI er skiftet spor. VentureBeat formulerer det skarpt: “Enterprise AI has entered a new era.” Organisationer bevæger sig væk fra passive assistenter, der svarer på spørgsmål, og over til autonome agenter, der kan ræsonnere, invokere værktøjer, tilgå enterprise-applikationer, koordinere med andre agenter og færdiggøre flertrins-workflows med minimal menneskelig indblanding. Det er ikke bare en ny label. Det ændrer, hvordan software opfører sig i produktion.
Kernen er beslutningstagning i farten. VentureBeat skriver, at agenter “dynamically determine how to achieve an objective. They decide which tools to use, which APIs to call, what information to retrieve, and how to sequence actions based on context.” Ikke en playbook kodet én gang for alle, men løbende valg truffet ud fra kontekst. Det giver fart og fleksibilitet — og nye angrebsoverflader midt i kørslen.
Hvad er der sket
Den gamle sikkerhedstrekant svarede pænt på tre spørgsmål: “Who are you, what can you access, and what actions are you authorized to perform.” Med Identity Providers, MFA, RBAC og zero trust-arkitekturer har virksomheder et robust fundament. VentureBeat peger på, at “traditional security controls provide very little visibility” efter autentifikation, når en agent selvstændigt fortsætter. Pointen kondenseres af sætningen: “Authentication establishes identity, not trust.” Det er kontant formuleret og passer til den nye virkelighed.
VentureBeat skubber derfor på et skifte i mindset: “runtime trust.” Det betyder kontinuerlig vurdering af, om agentens handlinger stadig stemmer med brugerens hensigt og virksomhedens politik, mens tingene sker. Ikke bagefter i en log. Ikke kun ved login. Under eksekvering.
Hvorfor identitet ikke er nok
Zero trust (NIST SP 800-207) er fortsat det rigtige pejlemærke for identitet og adgang. Dokumentet sætter principperne, og mange implementeringer leverer mærkbare forbedringer i segmentering og mindst mulig adgang. Men NIST-teksten går ikke i dybden med kontinuerlig verifikation af autonome agenters beslutningssekvenser i runtime. Det er en tolkning, ikke en direkte udmelding fra NIST, men den matcher, hvad man typisk ser i praksis: fokus på, hvem der må hvad, mindre fokus på, hvad der faktisk sker i femte kald i et dynamisk forløb.
Forestil dig et forløb i ServiceNow. En agent logger ind legitimt, henter en liste over tickets, krydsrefererer med kundedata i Salesforce, ændrer SLA-tags, åbner et nyt change request og pinger en Slack-webhook for at opdatere et team. Alt sammen inden for tilladte scopes. Hvor går det galt? Hvis agenten pga. målslip begynder at justere konfigurationer ud over det nødvendige. Hvis hukommelsen er forgiftet. Eller hvis agenten overfortolker en politik og kalder et admin-endpoint i et forsøg på at være “hjælpsom”. Traditionel IAM fangede intet, for hvert kald var isoleret set autoriseret.
Den nye risikoklasse i runtime
NIST SP 800-207 dækker, at hver anmodning bør evalueres dynamisk i en policy decision point. Det harmonerer delvist med behovet. Men agenters løbende planlægning og værktøjsvalg skaber en sekvens, hvor hvert kald påvirker det næste. Der ligger et hul mellem per-request-kontrol og sekvensforståelse. Kilderne modsiger ikke hinanden, men de taler forbi hinanden: NIST på principniveau, VentureBeat på den operative virkelighed med autonome løkker.
Hvad betyder det teknisk
Runtime trust kræver mekanik, ikke paroler. For det første telemetri om handlinger på et højere abstraktionsniveau end API-kald alene: Hvad var målet, hvilken plan blev valgt, hvilke værktøjer blev aktiveret, og i hvilken rækkefølge. For det andet en policy-motor, der kan evaluere mønstre i sekvenser — ikke kun tjekke et enkelt scope. For det tredje signering eller attestering af action-calls, så man kan knytte handlinger til en specifik agentidentitet og dens politikversion i det øjeblik, handlingen udføres.
Og der mangler standarder. VentureBeat peger på behovet for et sprog for “runtime trust”, men industrien har stadig ikke fælles API-kontrakter for agentidentitet eller “agent runtime attestations”. Uden det ender hvert program med proprietære felter i logs og specialbyggede dashboards, der ikke rejser godt mellem teams. Det lyder småt, men det er dér, de store compliance-problemer starter.
Kontrol ved kontekst og nødstop
Politikker bør kobles til kontekst: tidspunkt, datafølsomhed, risikoscore for det kaldte værktøj, og om handlingen ligger uden for det deklarerede mål. Her giver realtidsafbrydere mening. Et “break-glass”-mønster, hvor kritiske handlinger kræver menneskelig bekræftelse eller eskalerer til en vagtgående rolle, før agenten må fortsætte. Ikke for at bremse alt, men for at fange de 1 procent af forløb, hvor noget er på vej sidelæns.
Logikken kan være enkel i starten: hvis en agent forlader sit erklærede målområde, eller hvis successiv brug af et admin-endpoint overstiger en tærskel, så stop, tag en snapshot, eskalér. Den slags simple hegn sparer faktiske skader — og gør efterforskning mulig, når noget går galt.
Drift og infrastruktur: konkrete trade-offs
Skiftet til agenter presser også drift og placering. Salesforce beskriver i et AWS-blogindlæg, hvordan Agentforce skulle være højtilgængelig på tværs af Availability Zones. Amazon SageMaker AI Inference Components kunne skære i GPU-udgifterne, men standardplaceringen “didn’t guarantee the Multi-AZ resilience Salesforce’s compliance bar required.” Gevinsten var reel: “an 8x reduction in infrastructure costs by co-hosting multiple models on shared GPUs.” Men der opstod et nyt spørgsmål: hvordan gør man IC-endpoints højtilgængelige på tværs af flere AZ’er uden at miste den besparelse.
Problemet var, at algoritmen fordeler komponenter pr. deployment-operation, ikke på tværs, hvilket kan skabe “single points of failure” for en model. Salesforce krævede “2-AZ support for every production model.” Løsningen kom, da AWS introducerede “the SchedulingConfig parameter in the CreateInferenceComponent API”, som giver finere kontrol over placering. Det lyder meget infrastrukturelt, fordi det er det. Men for agentplatforme i produktion er det forskellen på, om et enkelt AZ-udfald lammer både orkestrering og værktøjslag.
Hvorfor det her gør ondt i praksis
Når agenter orkestrerer tværgående forløb, forplanter infrastrukturvalg sig ind i forretningen. Vælger man aggressiv co-hosting for at spare GPU-timer, stiger risikoen for kaskadefejl, hvis en AZ går ned eller en instans ryger. Vælger man streng Multi-AZ-balancering, stiger omkostninger og mulig latency. I et CRM-flow kan det være forskellen på opdateringstid fra sekunder til halve minutter. Det er ikke teoretisk; Salesforce-casen dokumenterer kompromiserne med konkrete API-mekanismer og compliance-barer.
Driftslaget skal derfor planlægge for agenters tilgængelighed som en produktfunktion, ikke som et datacenter-ansvar, man kan udlicitere til en default. Der ligger også styring i, hvor tæt værktøjer og modeller placeres på data. Fejlplaceret data-gravitationspunkt giver både højere regning og mere skrøbelighed i agentkæder.
Governance og organisationsmæssige konsekvenser
Den organisatoriske del halter ofte efter. Når agenter ændrer ting i ServiceNow, GitHub eller ERP, skal der være klare ejerskaber og audit trails. Det kræver nye roller i driften: nogen der ser på agentmønstre i realtid, ikke kun på alarmer fra CPU og hukommelse. Kald det en runtime trust-analytiker eller agent-ops. Navnet er mindre vigtigt end ansvaret.
Change control må også opdateres. En agent-release er ikke kun ny kode; det er også nye beslutningsmønstre, nye værktøjstilladelser og måske en ændret hukommelsesstrategi. Det bør gennem test i sandboxes, hvor policyer køres som håndbremsen: Hvad gør agenten, hvis et centralt API svarer langsomt? Hvis et tool returnerer uventet format? Hvis hukommelsen siger én ting, men kilden siger noget andet? Iteration, ikke big bang.
Hvad betyder det for sikkerhedsteams
Zero trust-principperne hjælper stadig: mindst mulig adgang, segmentering, kontinuert evaluering. Forskellen er, at adgangspolitikker skal suppleres af ræsonnementspolitikker: Hvilke værktøjer må bruges sammen? Hvilke handlinger må udføres, hvis agenten er ved at nå en KPI? Hvornår skal mennesket på banen?
Praktiske anbefalinger for beslutningstagere
- Kortlæg 5–10 kritiske workflows, hvor agenter er oplagte. Beskriv mål, acceptable handlinger og datakilder. Understøttes af VentureBeats fokus på mål og sekvenser samt manualbriefens anbefaling om at starte i højværdi-forløb.
- Definér acceptable handlingsmønstre pr. agent. Hvad må kaldes i hvilken rækkefølge, og hvornår skal der eskaleres. VentureBeat anbefaler runtime trust for netop at fange målslip og “excessive tool invocation”.
- Indfør telemetri og realtids policy-evaluering. Log mål, plan, værktøjsvalg og beslutningsgrunde. Evaluer sekvenser, ikke kun enkeltkald. Det følger direkte af kravet om synlighed “during execution”.
- Sikre API-kontrakter og permissions-scoping. Begræns admin-endpoints, og brug token-scopes pr. værktøj. NIST 800-207’s princip om mindst mulig adgang gælder her, selv om runtime-verifikation er et ekstra lag.
- Test i kontrollerede sandboxes med negative scenarier. Mål for målslip, hukommelsesforgiftning og værktøjsmisbrug. Manualbriefen peger på iterative forløb og overvågning som praksis.
- Planlæg Multi-AZ deployment og omkostningsanalyse. Brug erfaringen fra Salesforce/SageMaker: overvej “the SchedulingConfig parameter in the CreateInferenceComponent API” og vær eksplicit om 2-AZ-krav versus co-hosting-besparelser.
- Etabler break-glass og menneskelig godkendelse på risikofyldte handlinger. Små friktioner, stor risikoreduktion.
- Lav et auditspor, der binder agentidentitet, politikversion og handlinger sammen. Så er efterprøvning mulig ved afvigelser.
Uafklarede spørgsmål
Der mangler kvantitative målinger: hvor ofte ser man alvorlige agentfejl i produktion, og hvad koster det at bygge et modent runtime trust-lag. Kilderne peger på behovet, men ikke tallene. Der mangler også standarder for agentidentitet og “runtime attestations”. Uden fælles sprog bliver værktøjer og logs usammenlignelige på tværs af platforme.
Flere uafhængige cases end Salesforce vil styrke billedet af infrastruktur-trade-offs. Hvordan håndterer finans, sundhed og industri Multi-AZ og model-cohosting uden at blæse budgettet? Og på sikkerhedssiden: hvilke signaturer måler de bedste teams på for at opdage målslip i tide? Der er arbejde til standardiseringsfora og cloud-leverandører her.
Modsat synspunkt og nuancer
Nogle vil hævde, at en konsekvent zero trust-implementering kan dække det meste, hvis per-request-evaluering gøres granuleret nok. Det er rigtigt, at 800-207 ikke forbyder sekvensforståelse. Men VentureBeats pointe om “very little visibility” efter autentifikation rammer en praksis, hvor værktøjsvalg og ræsonnement ikke indgår i policybeslutningen. Det er en nuancering, ikke en konflikt: principperne er kompatible, men implementeringerne halter efter agent-virkeligheden.
Andre vil pege på, at gateways med dybe inspektionsmuligheder kan løse meget. Måske. Men uden eksplicit viden om mål, plan og acceptable sekvenser bliver inspektion en blind gættekonkurrence. Det interessante er, at flere sikkerhedslag her kræver forretningskontekst, ikke kun netværks- eller API-telemetri.
Det haster mere, end man tror
Agenter er allerede inde i mail, CRM, ITSM, kodebaser. Identitet, MFA, RBAC og zero trust er nødvendige, men utilstrækkelige til at skabe tillid til den løbende adfærd. Uden runtime-verifikation risikerer virksomheder både driftstab og compliance-brud, selv når alt ser korrekt ud på login-niveau. Man mærker forskellen første gang en agent går i ring på et admin-endpoint en søndag aften.
Næste skridt for dækningen er at tale med sikkerhedschefer, der allerede kører agenter i produktion, leverandører af agentplatforme om deres telemetri og policy-motorer, samt NIST og lignende fora om, hvordan zero trust-praksis kan udvides til sekvensverifikation. Indtil da er rådet enkelt: byg runtime trust, før skaden lærer jer det.
