Din MCP-server er sikker. Det er regnskabet bag den ikke.

I en nylig artikel her på Unite.AI beskrev Gil Feig seks bedste praksisser for at bygge en sikker MCP-server. De er gode råd, og alle, der lancerer en MCP-server, bør følge dem. Hans anbefaling om at give hver integration »sin egen rolle med detaljerede rettigheder, der er strengt begrænset til de nødvendige tilladelser«, er helt rigtig. Den forudsætter også, at systemet i den anden ende har roller med detaljerede rettigheder. Det peger på en bredere antagelse, som sjældent bliver nævnt: at systemerne bag serveren kan sikres efter samme standard.

I forretningssoftware kan de ofte ikke det. Jeg leder ingeniørteamet bag et integrationslag, der forbindes til 32 regnskabs- og ERP-systemer, med en valgfri MCP-server ovenpå. Vi ser jævnligt agenter, der er godt autentificeret, har velafgrænsede rettigheder og logges grundigt på vores side, men som skriver til systemer, der ikke på nogen måde kan vide, at en agent har været involveret.

Artiklen handler om den anden halvdel af problemet: hvad de bagvedliggende systemer faktisk tilbyder, hvad du kan styre fra integrationslaget, og hvor den kontrol ophører.

Hvor MCP-specifikationen overlader ansvaret

Den MCP-specifikationen for autorisation er tydelig om sin egen afgrænsning. MCP-serveren er en OAuth-ressourceserver for sine klienter. Når den kalder et API på opstrømssiden, fungerer den som en separat OAuth-klient med et separat token, der er udstedt af systemet på opstrømssiden. Det er udtrykkeligt forbudt at videresende klientens token.

Det er det rigtige design. Det betyder også, at alt ved kaldet til det bagvedliggende system – herunder hvem der må gøre hvad, og hvordan det registreres – udelukkende afhænger af det pågældende system. Specifikationen kan ikke rette op på det, som systemet ikke tilbyder.

Det samme gælder OWASP’s vejledning om overdreven handlefrihed. Den anbefaler, at man begrænser agentudvidelsers tilladelser i andre systemer til det nødvendige minimum og udfører handlinger på vegne af den bruger, de handler for. Begge dele er gode råd. Begge forudsætter, at det andet system kan angive minimumstilladelser og brugerens kontekst.

Hvad de bagvedliggende systemer faktisk tilbyder

Sådan ser de 32 regnskabs- og ERP-systemer, vi forbinder til, ud fra en integrators perspektiv.

En tredjedel har slet ikke OAuth

21 af de 32 bruger OAuth. De resterende 11 benytter statiske legitimationsoplysninger: API-nøgler, brugernavn og adgangskode eller et par tokens. Nogle af nøglerne udløber aldrig. Ét udbredt system oplyser i sin API-dokumentation, at dets API-tokens har ubegrænset gyldighed, så længe brugeren eksisterer.

Lang levetid, begrænsede muligheder for tilbagekaldelse

OAuth hjælper mindre, end man kunne håbe. En udbyder udsteder refresh-tokens med en levetid på omkring 20 år. Det er en adgangsoplysning, der er designet til at overleve den agent, der bruger den, det framework, agenten blev bygget på, og muligvis også den person, der klikkede på »Tillad«. I et andet system udløber selv adgangstokens ikke.

Og når en adgangsoplysning først er udstedt, er spørgsmålet, hvem der kan deaktivere den. Standarden for det, tilbagekaldelse af OAuth-tokens (RFC 7009), har eksisteret siden 2013. Alligevel giver omkring fire ud af ti systemer ikke en integrator nogen teknisk mulighed for at tilbagekalde adgangsoplysninger. Alle systemer med API-nøgler hører til den gruppe. Den eneste tilbageværende mulighed er at bede kunden om selv at slette adgangen.

Grove tilladelsesområder, ingen agentidentitet

De fleste statiske nøgler arver ganske enkelt alle rettigheder fra den bruger, der oprettede dem; kun få systemer giver mulighed for at begrænse en nøgle til bestemte slutpunkter. Mange OAuth-systemer har tilladelsesområder, men de er typisk grove, f.eks. »regnskab, læsning og skrivning«. Og i ingen af de 32 systemer kunne vi finde en måde at registrere både agenten og den person, den handler på vegne af, på den samme transaktion via API’et. Eksterne agenter vises enten som den bruger, der forbandt dem, eller som en generisk systembruger. Det er sigende, at når en leverandør har indbygget agenter i sit eget produkt, som Microsoft har gjort i Business Central, har leverandøren givet dem dedikerede brugerkonti. Det er det samme mønster, som jeg anbefaler nedenfor, blot forbeholdt leverandørens egne agenter.

Hvad integrationslaget kan håndhæve

Det betyder ikke, at man skal give op. Mellem agenten og regnskabssystemet har du kontrol over næsten alt:

• adgangsoplysninger pr. agent til dit eget lag
• dine egne tilladelsesområder, f.eks. skrivebeskyttet adgang til fakturaer
• en revisionslog over hvert agentkald med angivelse af, hvilken person agenten handlede på vegne af
• idempotensnøgler, så en agent, der prøver igen, ikke bogfører den samme faktura to gange
• hastighedsbegrænsninger pr. agent
• godkendelsestrin før enhver skrivehandling

Intet af dette afhænger af, hvad målsystemet understøtter. Det er allerede i dag muligt at etablere et effektivt adgangslag på integrationsniveauet, og hvis du lader agenter komme i nærheden af finansielle data, bør du bygge et.

Hvor kontrollen stopper

Det, du ikke kan gøre, er at føre dette lag videre på den anden side af systemgrænsen. Her går tre ting galt.

Tilskrivning

I regnskabssystemet fremstår agentens registrering som foretaget af den, der godkendte forbindelsen, eller af en teknisk bruger. Alle, der reviderer systemet, ser en postering foretaget af den bruger. De kan ikke se, om det var en person eller en agent, der foretog den. I regnskabet ser en agent, der bogfører 400 fakturaer kl. 3 om natten, præcis ud som en meget omhyggelig økonomichef. Det kræver logfiler fra integrationsleverandøren at rekonstruere forløbet, og det er en anden tillidskæde end systemet, hvor registreringerne føres. Ved digital efterforskning eller en revision er det et svagt udgangspunkt.

De fleste organisationer er heller ikke nået længere. I en undersøgelse fra Cloud Security Alliance svarede kun 28 %, at de pålideligt kunne spore agenters handlinger til en person eller et system på tværs af alle miljøer, og 44 % bruger eller planlægger at bruge statiske API-nøgler til deres agenter.

Mindst mulige privilegier

Du kan håndhæve, at en agent kun læser fakturaer. Men hvis målsystemet ikke understøtter adgangsområder, har legitimationsoplysningerne bag dit lag stadig fuld adgang. Alle, der får fat i dem, omgår hele dit lag og alle de regler, du har skrevet til det.

Tilbagekaldelse

Du kan øjeblikkeligt afskære din egen agent. Det hjælper ikke, hvis selve legitimationsoplysningerne til målsystemet er kompromitteret. Og for de fire ud af ti systemer, der ikke har et endepunkt til tilbagekaldelse, består nødstopfunktionen i at sende kunden en e-mail.

Det pragmatiske svar: En særskilt bruger til agenten

Det mest nyttige, du kan gøre i dag, er ikke særlig glamourøst. Opret en særskilt bruger til agenten i målsystemet, og forbind kun agenten via denne bruger.

Det fungerer i alle systemer, hvor du kan oprette brugere, og giver dig tre ting, som integrationslaget ikke kan:

• Tilskrivning i systemet, hvor registreringerne føres. Posteringer vises som »AP-agent« og ikke som den økonomichef, der klikkede på »tilslut« for seks måneder siden.
• En mulighed for tilbagekaldelse, selv uden en API til det. Kunden kan deaktivere brugeren i brugergrænsefladen, hvilket fungerer i systemer, der ikke har et endepunkt til tilbagekaldelse.
• Delvis begrænsning af privilegier. Hvis systemet overhovedet har en rollemekanisme, kan agentens bruger ofte begrænses til de moduler, den faktisk har brug for.

Omkostningerne er reelle. Nogen skal oprette brugeren manuelt under onboarding, hvilket skaber friktion på præcis det værst tænkelige tidspunkt. Omkring halvdelen af systemerne opkræver betaling for hver ekstra bruger, fra nogle få euro om måneden i værktøjer til små virksomheder til over hundrede euro i et komplet ERP-system. Flere andre begrænser antallet af brugere afhængigt af abonnementet, så én bruger mere kan betyde et dyrere abonnement for hele virksomheden. Og en servicebruger, som ingen har ansvaret for, udgør i sig selv en risiko og bliver en del af den spredning af ikke-menneskelige identiteter, som Unite.AI tidligere har skrevet om. Ligesom enhver anden konto skal den have en ansvarlig ejer og en dato for gennemgang.

Det løser heller ikke problemet med adgangsområder i systemer, der ikke har dem. Men det flytter tilskrivning og tilbagekaldelse tilbage til det system, som revisorerne faktisk kigger i.

Det strukturelle svar: Delegeret identitet

Det rigtige svar findes allerede på papiret. OAuth 2.0-tokenudveksling (RFC 8693) skelner mellem efterligning og delegering. Ved delegering beholder agenten sin egen identitet, og tokenet angiver via »act«-claimet, at den handler på vegne af en person.

Anvendt på regnskabssystemer ville det betyde:

• at regnskabet registrerer, at denne agent foretog posteringen på vegne af denne person
• at adgangsområder tildeles for hver delegering, ikke for hver bruger
• at en enkelt delegering kan tilbagekaldes uden at berøre personens konto

Så vidt jeg kunne finde ud af, understøtter ingen af de 32 systemer noget tilsvarende. Indtil videre er det derfor en retning, ikke en mulighed. Det gør det til en opfordring til leverandørerne af regnskabs- og ERP-software snarere end en opgave for integrationsleverandører: Agenter skriver allerede i jeres regnskaber, og jeres API’er bør kunne angive det.

Hvad du bør gøre, før en agent får adgang til et regnskab

Hvis du forbinder agenter med regnskabs- eller ERP-systemer, kan du følge denne korte tjekliste:

1. Kortlæg hvert målsystems model for legitimationsoplysninger. Bruger det OAuth eller en statisk nøgle? Hvor længe er legitimationsoplysningerne gyldige? Har de adgangsområder, og kan de tilbagekaldes?
2. Byg alligevel dit eget adgangslag. Identitet for hver agent, adgangsområder, idempotens og godkendelser hører hjemme hos jer, uanset hvad målsystemet tilbyder.
3. Brug en særskilt bruger til agenten, når systemet tillader det. Accepter arbejdet med onboarding og licensomkostningerne som prisen for tilskrivning.
4. Sørg for, at jeres eget revisionsspor gør manipulation synlig. For mange systemer vil det være den eneste registrering af, at en agent var involveret.
5. Dokumentér den resterende risiko. Hvis et system hverken har adgangsområder eller mulighed for tilbagekaldelse, skal du gøre kunden og dit eget risikoregister opmærksom på det.

Grænsen er afgørende

Det er nødvendigt at sikre din MCP-server. Men det er ikke tilstrækkeligt. Sikkerheden for en agent, der skriver i en hovedbog, afgøres ved grænsen mellem dit lag og det autoritative registreringssystem, og i dag er det systemerne – ikke dig – der fastlægger den grænse.

Den gode nyhed er, at manglen er klart afgrænset. Standarderne findes. Det, der mangler, er understøttelse af dem i de systemer, der fører regnskaberne.