MCP-serveren din er sikker. Det er ikke hovedboken bak den.

I en nylig artikkel her på Unite.AI la Gil Feig fram seks beste praksiser for å bygge en sikker MCP-server. Dette er gode råd, og alle som lanserer en MCP-server, bør følge dem. Rådet hans om å gi hver integrasjon «sin egen finmaskede rolle, strengt begrenset til nødvendige tillatelser» er helt riktig. Det forutsetter også at systemet i den andre enden har finmaskede roller. Dette peker på en bredere antakelse som sjelden blir uttalt: at systemene bak serveren kan sikres etter samme standard.

I forretningsprogramvare er det ofte ikke mulig. Jeg leder utviklingsteamet bak et integrasjonslag som kobler til 32 regnskaps- og ERP-systemer, med en valgfri MCP-server på toppen. Vi ser jevnlig agenter som er godt autentisert, har tydelig avgrensede tilganger og loggføres godt på vår side, men som skriver til systemer som ikke har noen mulighet til å vite at en agent i det hele tatt var involvert.

Denne artikkelen handler om den andre delen av problemet: hva oppstrømssystemene faktisk tilbyr, hva du kan kontrollere fra integrasjonslaget, og hvor denne kontrollen tar slutt.

Der MCP-spesifikasjonen overlater ansvaret videre

Selve MCP-autorisasjonsspesifikasjonen er tydelig på grensene for sitt eget virkeområde. MCP-serveren er en OAuth-ressursserver for klientene sine. Når den kaller et oppstrøms-API, fungerer den som en separat OAuth-klient med et eget token utstedt av oppstrømssystemet. Det er uttrykkelig forbudt å sende klientens token videre.

Det er riktig utforming. Det betyr også at alt ved kallet til oppstrømssystemet, inkludert hvem som har lov til å gjøre hva, og hvordan dette loggføres, utelukkende avhenger av oppstrømssystemet. Spesifikasjonen kan ikke rette opp i det oppstrømssystemet ikke tilbyr.

Det samme gjelder OWASP-veiledningen om overdreven autonomi. Den anbefaler å begrense tillatelsene agentens utvidelser har i andre systemer, til det som er strengt nødvendig, og å utføre handlinger i konteksten til brukeren agenten handler på vegne av. Begge deler er gode råd. Begge forutsetter at det andre systemet kan uttrykke minimumstillatelser og brukerkontekst.

Hva oppstrømssystemene faktisk tilbyr

Slik ser de 32 regnskaps- og ERP-systemene vi kobler til, ut fra en integratørs ståsted.

En tredel har ikke OAuth i det hele tatt

21 av de 32 bruker OAuth. De øvrige 11 baserer seg på statiske påloggingsopplysninger: API-nøkler, brukernavn og passord eller et par med tokener. Noen av disse nøklene utløper aldri. Ett mye brukt system opplyser at API-tokenene har ubegrenset levetid så lenge brukeren eksisterer.

Lang levetid, få muligheter til å tilbakekalle

OAuth hjelper mindre enn man skulle håpe. Én leverandør utsteder oppdateringstokener med en levetid på omtrent 20 år. Dette er en legitimasjon som er utformet for å vare lenger enn agenten som bruker den, rammeverket agenten ble bygget på, og kanskje til og med personen som klikket på «tillat». I et annet system utløper heller ikke tilgangstokenene.

Og når en legitimasjon først er på avveie, er spørsmålet hvem som kan deaktivere den. Standarden for dette, tilbakekalling av OAuth-tokener (RFC 7009), har eksistert siden 2013. Likevel gir omtrent fire av ti systemer ikke integratøren noen teknisk mulighet til å tilbakekalle legitimasjon. Alle systemer som bruker API-nøkler, tilhører denne gruppen. Den eneste muligheten som gjenstår, er å be kunden om å fjerne tilgangen manuelt.

Grove tilgangsområder, ingen agentidentitet

De fleste statiske nøkler arver ganske enkelt alle rettighetene til brukeren som opprettet dem; bare noen få systemer lar deg begrense en nøkkel til bestemte endepunkter. Mange OAuth-systemer har tilgangsområder, men disse er som regel grovt inndelt, for eksempel «regnskap, lesing og skriving». Og i ingen av de 32 systemene fant vi noen måte å registrere både agenten og personen den handler på vegne av, på samme transaksjon via API-et. Eksterne agenter vises enten som brukeren som koblet dem til, eller som en generisk systembruker. Det er talende at en leverandør som har bygget agenter inn i sitt eget produkt, slik Microsoft har gjort i Business Central, har gitt dem egne brukerkontoer. Det er samme framgangsmåte som jeg anbefaler nedenfor, men her er den forbeholdt leverandørens egne agenter.

Hva integrasjonslaget kan håndheve

Dette betyr ikke at man må gi opp. Mellom agenten og regnskapssystemet har du kontroll over nesten alt:

• egen legitimasjon for hver agent overfor ditt eget lag
• egne tilgangsområder, for eksempel skrivebeskyttet tilgang til fakturaer
• en revisjonslogg over hvert agentkall, med opplysninger om personen agenten handlet på vegne av
• idempotensnøkler, slik at en agent som prøver på nytt, ikke bokfører samme faktura to ganger
• frekvensbegrensninger per agent
• godkjenningstrinn før enhver skriveoperasjon

Ingen av disse tiltakene avhenger av hva målsystemet støtter. Det er mulig å bygge et avansert tilgangslag på integrasjonsnivå allerede i dag, og hvis du lar agenter komme i nærheten av økonomiske data, bør du bygge et slikt lag.

Hvor kontrollen stopper

Det du ikke kan gjøre, er å utvide dette laget forbi systemgrensen. Der oppstår det problemer på tre områder.

Sporbarhet

I regnskapssystemet ser det ut som om det er den som godkjente tilkoblingen, eller en teknisk bruker, som har gjort registreringen. Alle som reviderer systemet, ser en postering fra denne brukeren. De kan ikke se om det var en person eller en agent som utførte den. For hovedboken ser en agent som bokfører 400 fakturaer kl. 03, nøyaktig ut som en svært pliktoppfyllende økonomiansvarlig. For å rekonstruere hendelsesforløpet må man bruke integratorens logger, som utgjør en annen tillitskjede enn systemet som er autoritativ kilde. Det er et svakt utgangspunkt for etterforskning eller revisjon.

De fleste organisasjoner ligger heller ikke i forkant på dette området. I en undersøkelse fra Cloud Security Alliance svarte bare 28 % av respondentene at de pålitelig kunne spore agenthandlinger tilbake til en person eller et system på tvers av alle miljøer, og 44 % bruker eller planlegger å bruke statiske API-nøkler for agentene sine.

Prinsippet om minste privilegium

Du kan sørge for at en agent bare leser fakturaer. Men hvis målsystemet ikke har tilgangsomfang, har påloggingsinformasjonen bak laget ditt fortsatt full tilgang. Alle som får tak i den, kan omgå hele laget ditt og alle reglene du har satt opp der.

Tilbakekalling

Du kan umiddelbart deaktivere din egen agent. Det hjelper ikke hvis selve påloggingsinformasjonen til målsystemet er kompromittert. Og for de fire av ti systemene som ikke har et endepunkt for tilbakekalling, består nødbryteren av en e-post til kunden.

Den pragmatiske løsningen: En egen bruker for agenten

Det mest nyttige du kan gjøre i dag, er ikke særlig glamorøst. Opprett en egen bruker for agenten i målsystemet, og koble agenten til systemet bare gjennom denne brukeren.

Dette fungerer i alle systemer der du kan opprette brukere, og gir deg tre ting som integrasjonslaget ikke kan tilby:

• Sporbarhet i systemet som er autoritativ kilde. Posteringene vises som «AP-agent», ikke som økonomiansvarlig som klikket på «koble til» for seks måneder siden.
• En mulighet for tilbakekalling, selv uten et API for dette. Kunden kan deaktivere brukeren i grensesnittet, noe som fungerer også i systemer uten et endepunkt for tilbakekalling.
• Delvis etterlevelse av prinsippet om minste privilegium. Hvis systemet har en eller annen form for rolleadministrasjon, kan agentbrukeren ofte begrenses til modulene den faktisk trenger.

Kostnadene er reelle. Noen må opprette brukeren manuelt under oppstarten, noe som skaper ekstra friksjon akkurat når det passer dårligst. Omtrent halvparten av systemene tar betalt for hver ekstra bruker, fra noen få euro i måneden for verktøy for småbedrifter til over hundre euro for et komplett ERP-system. Flere andre begrenser antall brukere ut fra abonnementet, slik at én ekstra bruker kan bety et dyrere abonnement for hele selskapet. Og en tjenestebruker som ingen har ansvar for, blir en risiko i seg selv, som en del av spredningen av ikke-menneskelige identiteter som Unite.AI har omtalt tidligere. Den trenger en ansvarlig eier og en dato for gjennomgang, akkurat som enhver annen konto.

Dette løser heller ikke problemet med manglende tilgangsomfang i systemer som ikke har dette. Men det flytter ansvaret for sporbarhet og tilbakekalling tilbake til systemet som revisorene faktisk undersøker.

Den strukturelle løsningen: Delegert identitet

Den riktige løsningen finnes allerede på papiret. OAuth 2.0-tokenutveksling (RFC 8693) skiller mellom imitasjon og delegering. Ved delegering beholder agenten sin egen identitet, og tokenet registrerer gjennom «act»-påstanden at den handler på vegne av en person.

Brukt i regnskapssystemer ville det bety at:

• hovedboken registrerer at denne agenten bokførte på vegne av denne personen
• tilgangsomfang tildeles for hver delegering, ikke for hver bruker
• en enkelt delegering kan tilbakekalles uten å berøre personens konto

Så vidt jeg kunne finne, støtter ingen av de 32 systemene noe lignende. Foreløpig er det derfor en ønsket retning, ikke et tilgjengelig alternativ. Dermed er dette en oppfordring til leverandørene av regnskaps- og ERP-programvare, ikke en oppgave for integratorene: Agenter skriver allerede i hovedbøkene deres, og API-ene deres bør kunne vise det.

Hva du bør gjøre før en agent får tilgang til hovedboken

Hvis du kobler agenter til regnskaps- eller ERP-systemer, kan du gå gjennom denne korte sjekklisten:

1. Kartlegg påloggingsmodellen for hvert målsystem. Bruker det OAuth eller en statisk nøkkel? Hvor lenge er påloggingsinformasjonen gyldig? Har den et definert tilgangsomfang, og kan du tilbakekalle den?
2. Bygg tilgangslaget ditt uansett. Identitet for hver agent, tilgangsomfang, idempotens og godkjenninger hører hjemme på din side, uansett hva målsystemet tilbyr.
3. Bruk en egen agentbruker der systemet tillater det. Godta arbeidet med oppstarten og lisenskostnaden som prisen for sporbarhet.
4. Sørg for at ditt eget revisjonsspor gjør manipulering synlig. For mange systemer vil dette være den eneste dokumentasjonen på at en agent var involvert.
5. Skriv ned restrisikoen. Hvis et system mangler tilgangsomfang og mulighet for tilbakekalling, må du si fra om det til kunden og føre det opp i ditt eget risikoregister.

Det er grensen som er poenget

Det er nødvendig å sikre MCP-serveren din. Men det er ikke tilstrekkelig. Sikkerheten til en agent som skriver til en hovedbok, avgjøres ved grensen mellom laget ditt og det autoritative kildesystemet. I dag bestemmes denne grensen av systemene, ikke av deg.

Den gode nyheten er at mangelen er tydelig avgrenset. Standardene finnes. Det som mangler, er støtte for dem i systemene som fører hovedbøkene.