Din MCP-server är säker. Huvudboken bakom den är det inte.

I en nyligen publicerad artikel här på Unite.AI presenterade Gil Feig sex bästa metoder för att bygga en säker MCP-server. De är välgrundade, och alla som lanserar en MCP-server bör följa dem. Hans råd om att ge varje integration ”en egen finkornig roll, strikt begränsad till de behörigheter som krävs” är helt rätt. Det förutsätter också att systemet i andra änden har finkorniga roller. Det pekar på ett mer övergripande antagande som sällan uttalas: att systemen bakom servern kan säkras enligt samma standard.

Inom affärsprogramvara är det ofta inte möjligt. Jag leder utvecklingsteamet bakom ett integrationslager som ansluter till 32 redovisnings- och ERP-system, med en valfri MCP-server ovanpå. Vi ser regelbundet agenter som är väl autentiserade, har tydligt avgränsade behörigheter och loggas ordentligt på vår sida, men som skriver in data i system som inte har något sätt att veta att en agent över huvud taget varit inblandad.

Den här artikeln handlar om problemets andra halva: vad systemen uppströms faktiskt erbjuder, vad du kan styra från integrationslagret och var den kontrollen tar slut.

Där MCP-specifikationen lämnar över ansvaret

Den MCP-specifikationen för auktorisering är tydlig med sina egna gränser. MCP-servern är en OAuth-resursserver för sina klienter. När den anropar ett uppströms-API fungerar den som en separat OAuth-klient, med en separat token utfärdad av uppströmssystemet. Det är uttryckligen förbjudet att vidarebefordra klientens token.

Det är rätt utformning. Det innebär också att allt som rör anropet till det uppströms systemet, inklusive vem som får göra vad och hur det registreras, helt och hållet beror på det systemet. Specifikationen kan inte åtgärda sådant som det uppströms systemet inte erbjuder.

Detsamma gäller OWASP:s vägledning om överdrivet handlingsutrymme. Den rekommenderar att begränsa de behörigheter som en agents tillägg har i andra system till det minsta nödvändiga och att utföra åtgärder i den användares namn som agenten agerar för. Båda råden är goda. Båda förutsätter att det andra systemet har ett sätt att ange minsta nödvändiga behörigheter och användarkontext.

Vad systemen uppströms faktiskt erbjuder

Så här ser de 32 redovisnings- och ERP-system som vi ansluter till ut ur en integratörs perspektiv.

En tredjedel saknar OAuth helt

21 av de 32 använder OAuth. De övriga 11 förlitar sig på statiska inloggningsuppgifter: API-nycklar, användarnamn och lösenord eller ett par token. Vissa av dessa nycklar upphör aldrig att gälla. Ett system som används i stor utsträckning anger i sin API-dokumentation att dess token har obegränsad giltighet så länge användaren finns kvar.

Lång giltighetstid, få möjligheter att återkalla

OAuth hjälper mindre än man skulle hoppas. En leverantör utfärdar uppdateringstoken med en giltighetstid på ungefär 20 år. Det är en autentiseringsuppgift som är utformad för att finnas kvar längre än agenten som använder den, ramverket som agenten byggdes på och mycket väl även personen som klickade på ”tillåt”. I ett annat system upphör inte ens åtkomsttoken att gälla.

När en autentiseringsuppgift väl är i omlopp är frågan vem som kan stänga av den. Standarden för det, återkallande av OAuth-token (RFC 7009), har funnits sedan 2013. Ändå saknar ungefär fyra av tio system ett tekniskt sätt för integratören att återkalla autentiseringsuppgifter. Samtliga system som använder API-nycklar ingår i den gruppen. Den enda återstående kontrollen är att be kunden ta bort åtkomsten manuellt.

Grovt indelade behörighetsomfång, ingen agentidentitet

De flesta statiska nycklar får helt enkelt samma fullständiga behörighet som användaren som skapade dem; bara ett fåtal system låter dig begränsa en nyckel till enskilda slutpunkter. Många OAuth-system har behörighetsomfång, men de brukar vara grovt indelade, ungefär som ”redovisning, läsning och skrivning”. Och i inget av de 32 systemen kunde vi hitta ett sätt att via API:t registrera både agenten och personen som den agerar för i samma transaktion. Externa agenter visas antingen som användaren som anslöt dem eller som en generisk systemanvändare. Talande nog gav en leverantör som byggt in agenter i sin egen produkt, vilket Microsoft har gjort i Business Central, dem särskilda användarkonton. Det är samma upplägg som jag rekommenderar nedan, men reserverat för leverantörens egna agenter.

Vad integrationslagret kan upprätthålla

Det här betyder inte att man ska ge upp. Mellan agenten och redovisningssystemet har du kontroll över nästan allt:

• autentiseringsuppgifter per agent för åtkomst till ditt eget lager
• egna behörighetsomfång, till exempel skrivskyddad åtkomst till fakturor
• en granskningslogg över varje agentanrop, med uppgift om vilken person agenten agerade för
• idempotensnycklar, så att en agent som försöker igen inte bokför samma faktura två gånger
• hastighetsbegränsningar per agent
• godkännandesteg före varje skrivåtgärd

Inget av detta beror på vilka funktioner målsystemet stöder. Det går redan i dag att skapa ett kraftfullt åtkomstlager på integrationsnivå, och om du placerar agenter i närheten av finansiella data bör du bygga ett sådant.

Där kontrollen upphör

Det du inte kan göra är att utöka det lagret bortom systemgränsen. Där brister det på tre punkter.

Spårbarhet

I bokföringssystemet registreras agentens åtgärd under namnet på den som godkände anslutningen, eller som en teknisk användare. Den som granskar systemet ser en bokföringspost från den användaren. Det går inte att avgöra om det var en person eller en agent som skapade posten. I huvudboken ser en agent som bokför 400 fakturor klockan 03.00 precis ut som en mycket flitig ekonomichef. För att återskapa händelseförloppet krävs integratörens loggar, vilket innebär en annan förtroendekedja än den som finns i det officiella redovisningssystemet. Vid en forensisk undersökning eller revision är det en svag utgångspunkt.

De flesta organisationer ligger inte heller före i utvecklingen. I en undersökning från Cloud Security Alliance uppgav endast 28 % av de svarande att de på ett tillförlitligt sätt kunde spåra agenters åtgärder till en person eller ett system i alla miljöer, och 44 % använder eller planerar att använda statiska API-nycklar för sina agenter.

Minsta privilegium

Du kan se till att en agent bara läser fakturor. Men om målsystemet saknar behörighetsomfång har autentiseringsuppgifterna bakom ditt lager fortfarande full åtkomst. Den som kommer över dem kan helt kringgå ditt lager och alla regler du har satt upp där.

Återkallning

Du kan omedelbart stänga av din egen agent. Det hjälper inte om själva autentiseringsuppgifterna till målsystemet har röjts. Och för de fyra av tio system som saknar ett API för återkallning består nödstoppet av att skicka ett mejl till kunden.

Den pragmatiska lösningen: ett särskilt agentkonto

Det mest användbara du kan göra i dag är inte särskilt glamoröst. Skapa ett särskilt användarkonto för agenten i målsystemet och anslut agenten enbart via det kontot.

Det fungerar i alla system där det går att skapa användarkonton och ger tre fördelar som integrationslagret inte kan erbjuda:

• Spårbarhet i det officiella redovisningssystemet. Bokföringsposterna visas som ”AP-agent”, inte under namnet på ekonomichefen som klickade på ”anslut” för sex månader sedan.
• En möjlighet till återkallning, även utan ett API för det. Kunden kan inaktivera användaren i gränssnittet, vilket fungerar även i system som saknar ett API för återkallning.
• Begränsning av privilegier, åtminstone delvis. Om systemet har någon form av rollhantering kan agentens användarkonto ofta begränsas till de moduler som faktiskt behövs.

Kostnaderna är reella. Någon måste skapa användarkontot manuellt under introduktionen, vilket skapar merarbete precis när det passar som sämst. Ungefär hälften av systemen tar betalt för varje extra användare, från några euro i månaden i verktyg för småföretag till mer än hundra euro i ett fullskaligt ERP-system. Flera andra begränsar antalet användare beroende på abonnemang, så ytterligare en användare kan innebära ett dyrare abonnemang för hela företaget. Och ett tjänstekonto som ingen ansvarar för blir en risk i sig, som en del av spridningen av icke-mänskliga identiteter som Unite.AI har skrivit om tidigare. Precis som för alla andra konton behövs en ansvarig och ett datum för översyn.

Det löser inte heller problemet med behörighetsomfång i system som saknar sådana. Men det gör att spårbarhet och återkallning åter hanteras i det system som revisorerna faktiskt granskar.

Den strukturella lösningen: delegerad identitet

Den rätta lösningen finns redan på papperet. OAuth 2.0-tokenutbyte (RFC 8693) skiljer mellan att agera i någons ställe och att delegera. Vid delegering behåller agenten sin egen identitet, och tokenen anger genom anspråket ”act” att den agerar på en persons vägnar.

Tillämpat på bokföring skulle det innebära att:

• huvudboken visar att den här agenten bokförde på den här personens vägnar
• behörighetsomfång beviljas för varje delegering, inte för varje användare
• en enskild delegering kan återkallas utan att personens konto påverkas

Såvitt jag har kunnat hitta stöder inget av de 32 systemen något liknande. Tills vidare får det därför förbli en målsättning, inte ett alternativ. Det innebär att vi måste vända oss till leverantörerna av bokförings- och ERP-programvara snarare än till integratörerna: agenter bokför redan i era huvudböcker, och era API:er bör kunna visa det.

Vad du bör göra innan en agent får tillgång till en huvudbok

Om du ansluter agenter till bokförings- eller ERP-system kan du gå igenom den här korta checklistan:

1. Ta reda på vilken autentiseringsmodell varje målsystem använder. Använder det OAuth eller en statisk nyckel? Hur länge gäller autentiseringsuppgiften, har den ett behörighetsomfång och går den att återkalla?
2. Bygg ditt åtkomstlager ändå. Identitet per agent, behörighetsomfång, idempotens och godkännanden hör hemma på din sida, oavsett vad målsystemet erbjuder.
3. Använd ett särskilt agentkonto där systemet tillåter det. Räkna introduktionsarbetet och licenskostnaden som priset för spårbarhet.
4. Se till att det går att upptäcka om någon manipulerar din egen granskningslogg. För många system blir den den enda dokumentationen av att en agent varit inblandad.
5. Dokumentera den kvarstående risken. Om ett system saknar behörighetsomfång och möjlighet att återkalla åtkomst ska du säga det till kunden och ta upp det i ditt eget riskregister.

Gränsen är själva poängen

Det är nödvändigt att säkra din MCP-server. Men det räcker inte. Säkerheten hos en agent som skriver till en liggare avgörs vid gränsen mellan ditt lager och systemet som utgör den auktoritativa källan, och i dag sätts den gränsen av systemen, inte av dig.

Den goda nyheten är att gapet är tydligt avgränsat. Standarderna finns. Det som saknas är stöd för dem i systemen som för huvudböckerna.