Kunskap

Kontrollerade MCP-verktyg för AI-agenter

Författare: Piotr AdamskiPublicerad: Uppdaterad:

Källa → Kontroll → Beslut → Belägg

Model Context Protocol (MCP) gör det enklare att koppla en modell eller agent till verktyg. Protokollet i sig bestämmer inte huruvida agenten får utföra en viss operation, på vilken resurs och med vilken konsekvens. Applikationslagret måste fortfarande verkställa dessa gränser.

Om en agent kan använda MCP för att läsa en rapport, ändra konfiguration, börja spendera pengar eller radera en resurs behandlar vi den som en privilegierad API‑klient. Prompten beskriver avsikten. Gatewayen verkställer begränsningarna.

I praktiken designar vi den gränsen kring sju principer.

1. Separera operatörsidentitet från mål‑systemets autentiseringsuppgifter

En agent agerar på någon annans vägnar. Vi måste därför svara på minst två separata frågor:

  • vem begärde denna operation och vad får de göra i Brillnet?
  • hur autentiserar Brillnet mot den externa leverantören?

De är inte samma sak.

I vårt interna Brillnet Ads MCP‑verktyg passerar operatören genom Brillnets auktoriseringslager, medan anrop till Google använder en separat tjänsteidentitet. Leverantörstoken är kortlivad och returneras inte via MCP som data till modellen.

Modellen behöver inte känna till någon autentiseringsuppgift för att utföra en tillåten uppgift. Den kan inte heller av misstag klistra in den uppgiften i ett svar om den aldrig har mottagit den.

Regel

En hemlighet ska vara tillgänglig för den komponent som måste använda den, inte för hela exekveringskedjan.

2. Uttryck behörigheter per operation, inte bara per agentnamn

En roll som marketing-agent är lättläst, men i sig säger den väldigt lite om vad systemet faktiskt kommer att tillåta.

Det är mer användbart att separera behörigheter efter konsekvens:

read
→ rapportering och hämtning

write
→ skapa eller ändra en resurs

operate
→ aktivera en operativ konsekvens, såsom spendering eller publicering

destructive
→ radera, koppla bort, återkalla eller göra en annan svår‑återgörlig förändring

En agent kan ha read utan write. Den kan ha write för att förbereda en kampanj men ingen operate, så den kan inte aktivera kampanjen. Radering kan kräva både write + destructive.

Namnen behöver inte vara exakt dessa. Den viktiga distinktionen är mellan att förbereda en förändring och att aktivera dess konsekvens.

Read: Least privilege for AI agents

3. Säkra standardvärden måste fungera utan modellens hjälp

Om utebliven parameter kan aktivera en åtgärd är standardvärdet osäkert.

I vårt interna Brillnet Ads MCP förblir en ny kampanj PAUSED när ingen status uttryckligen anges. Det kan verka litet, men regeln är viktig: saknad information är inte samtycke till att börja spendera.

Samma mönster gäller på andra ställen:

  • dokument utan status → utkast, inte publicerat;
  • ny användare utan roll → ingen åtkomst, inte en standardroll;
  • integration utan bekräftad destination → ingen synkronisering;
  • tvetydig resurs → fel, inte “mest sannolika” post;
  • saknad godkännande för en hög‑risk åtgärd → stopp, inte återförsök.

Ett säkert standardvärde ska förbli säkert när modellen hallucinerar, utelämnar ett fält eller missförstår avsikten.

4. Hög‑påverkande operationer kräver en separat grind

En agent kan förbereda en tekniskt korrekt förändring som ändå är fel affärsmässigt.

Att spendera budget, publicera innehåll, skicka meddelande till en kund, ändra åtkomst eller radera data ger konsekvenser bortom agentens session. Godkännande bör därför vara en oberoende händelse.

Minst ett godkännande‑förhandsgranskning bör visa:

  • mål‑system och resurs;
  • operationstyp;
  • materiella parametrar för förändringen;
  • förväntad konsekvens;
  • om operationen är reversibel;
  • vem som godkänner.

“Fortsätt?” räcker inte. Personen måste veta exakt vad som godkänns.

Read: When should an AI agent require human approval?

5. En återförsök får inte tyst duplicera en skrivning

Agent‑system gör många API‑anrop. Nätverksfel, time‑outs och återförsök är normala. Problemet uppstår när upprepning av samma operation skapar en andra resurs eller utför en andra betalning, publicering eller meddelande.

Där operationen stödjer det använder vi en idempotensnyckel. Gatewayen känner igen samma försök och förhindrar en okontrollerad duplicerad skrivning.

Det bör kombineras med read‑after‑write:

agent begär en förändring
↓
gateway validerar och utför skrivningen
↓
mål‑system svarar
↓
gateway läser det resulterande resurs‑tillståndet
↓
operatören ser det resulterande tillståndet

En leverantör som returnerar HTTP 200 är då inte det enda beviset på att systemet befinner sig i det förväntade tillståndet.

6. En rå gateway får inte bli en bakdörr

Stora API:er skapar ett praktiskt lockelse: istället för att bygga ett dedikerat verktyg för varje endpoint, exponera en mer generell REST‑kapacitet.

Det kan vara rimligt, men bara om den generella vägen ärver samma kontroller.

I Brillnet klassificeras metod, endpoint och begärans egenskaper innan exekvering. En låg‑nivå‑begäran kringgår inte nödvändiga funktionella scopes eller den extra kontrollen för destruktiva operationer.

Anti‑mönstret ser ut så här:

safe MCP tools
→ scoped and validated

raw_http_request
→ can call any endpoint with a full‑access token

I den designen är de tidigare kontrollerna i stort sett kosmetiska. Den bredaste vägen definierar den verkliga säkerhetsgränsen.

7. Revisionsspåret registrerar beslut och resultat, inte hemligheter

Vårt interna verktyg lagrar begärans metadata och resultat i en append‑only, integritets‑kontrollerad revisionskedja. Autentiserings‑headers, credentials och råa personidentifierare exkluderas.

Den distinktionen är viktig. Ett revisionsspår ska kunna återuppbygga en handling, inte duplicera säkerhetskontexten i en annan datalagring.

För en agent‑operation vill vi vanligtvis veta:

  • begäran/uppgift‑ID;
  • operatörs‑ och agent‑identitet;
  • verktyg och operation‑klass;
  • mål‑resurs;
  • auktoriseringsbeslut;
  • godkännande‑ID om godkännande krävdes;
  • leverantörs‑/backend‑resultat;
  • tillstånd observerat efter en skrivning;
  • policy‑ eller konfigurationsversion som tillämpades.

Read: AI agent audit trails

Exempelarkitektur: en agent för Google Ads

Vårt interna fall är avsiktligt smalt. Verktyget används endast för Google Ads‑konton som ägs av Brillnet. Det är ingen byråtjänst och får inte åtkomst till kunders annonskonton.

Flödet kan förenklas till:

Brillnet‑operatör
↓
identitet + profil + scopes
↓
agent / modell
↓
MCP‑verktygs‑anrop
↓
gateway: validering + klassificering + godkännandepolicy
↓
kortlivad leverantörstoken
↓
Google Ads API
↓
normalisering + radering
↓
read‑after‑write / resultat
↓
revisionsspår

Den viktigaste kontrollen finns inte i modellen. Den ligger i lagret mellan avsikt och exekvering.

Bekvämt‑utseende anti‑mönster

En administratörstoken för varje agent

Det förenklar prototypen. Senare blir det svårt att begränsa påverkan av ett fel eller bevisa att en agent skulle ha kunnat nå en resurs alls.

”Modellen frågar användaren om en åtgärd är riskfylld”

Det delegerar säkerhetsbeslutet till samma komponent vars misstag kontrollen är avsedd att begränsa.

Logga hela prompten och svaret som revisionsspår

En konversation är inte ett operativt revisionsregister. Den kan också innehålla information som inte bör kopieras till loggsystemet.

Återförsök varje fel automatiskt

Inte alla fel är övergående. Inte alla skrivningar är idempotenta. Ett oklassificerat återförsök kan öka skadan.

En universell endpoint med full åtkomst ”för framtida funktioner”

Om ett brett verktyg kan kringgå de begränsade verktygen blir det breda verktyget själva behörighetsmodellen.

MCP‑servergransknings‑checklista

Innan produktionsbruk skulle jag verifiera åtminstone:

  • Är operatörsidentiteten känd för varje anrop?
  • Är mål‑systemets autentiseringsuppgifter dolda för modellen?
  • Kan read, write, operate och destructive‑behörigheter separeras?
  • Begränsar auktorisationen resurs/tenant/konto såväl som funktionen?
  • Leder en utebliven parameter till ett säkert tillstånd?
  • Har finansiella, externa och destruktiva operationer oberoende godkännande?
  • Är skriv‑återförsök kontrollerade?
  • Läses målresursen tillbaka efter en skrivning?
  • Använder någon låg‑nivå‑gateway samma auktoriseringsregler?
  • Exkluderar revisionsspåret tokens, hemligheter och råa personuppgifter?
  • Avvisas godtyckliga filsystem‑sökvägar och obegränsade payloads?
  • Kan agent‑ eller operatörsåtkomst återkallas centralt?

MCP 2026‑07‑28 ändrar protokollet, inte behovet av applikationskontroller

MCP‑version 2026-07-28 introducerade, bland annat, en stateless protokollkärna och ytterligare hårdare auktorisation. Dessa förändringar gör kommunikationslagret enklare att skala och resonera kring. De bestämmer inte affärspolicyn för en distribution: huruvida en agent får spendera 5 000 PLN, radera ett konto eller skicka ett meddelande till 10 000 personer.

Applikationen måste fortfarande verkställa det beslutet.

Vem behöver detta designmönster

Processägare, utvecklare och säkerhetsgranskare behöver denna gräns. Tillverknings‑agenter kan utarbeta förändringsförslag; fastighets‑hanterings‑agenter kan organisera dokument; B2B‑agenter kan analysera ärenden. Att skicka boende‑notiser eller ändra kundbehörigheter kräver kontroll av konsekvensen.

Ads‑MCP‑exemplet kommer från intern verktygsdesign‑dokumentation. Det beskriver varken en kund‑annonserings‑kontotjänst eller en oberoende revision av den nuvarande produktionsmiljön.

Identitet och isolering kräver mer än en giltig token

MCP‑auktorisation kräver tokens avsedda för serverns egen resurs. En giltig signatur på en annan tjänsts token är otillräcklig. Kontrollera audience, issuer och giltighet. Avvisa olämpliga tokens innan exekvering.

Kontrollera också resursåtkomst. Jämför ett medfört tenant_id med serverns etablerade identitet snarare än att lita på agentens identifierare. Varje läs‑ och skrivoperation kräver resursauktorisation, inklusive bilagor, export och bakgrundsjobb.

MCP 2026-07-28 har inga sessions‑koncept på protokollnivå. Applikationer kan fortfarande upprätthålla tillstånd, såsom ett förändrings‑förhandsgransknings‑handtag. Ägande får inte ersätta autentisering. Bind handtaget till auktoriserade operatörer, kontrollera varje användning och sätt utgångstid. Ett stulet handtag får inte exponera en annan persons arbetsflöde.

Validera innehåll och kommunikationsdestinationer

Sökresultat, PDF‑filer, e‑post och API‑svar är analysmaterial. Inbäddade instruktioner för att hämta hemligheter eller skicka dokument någon annanstans är inte operatörsgodkännande. För skydd mot prompt‑injektion måste servern avvisa obehöriga resurser, mottagare och operationer även när verktygsargumenten är tekniskt giltiga.

För ett verktyg som accepterar URL:er, definiera tillåtna destinationer och hantering av omdirigeringar. MCP‑vägledningen diskuterar SSRF i OAuth‑metadata‑upptäckt. Bedöm samma problem i egna hämtningsverktyg. Tillstånd att hämta en publik sida får inte exponera en lokal administrations‑tjänst eller moln‑metadata‑endpoint. Skydd beror på nätverksarkitektur; enbart en värdnamnslista kanske inte styr den slutgiltiga anslutningsdestinationen.

För filverktyg, begränsa kataloger och payload‑storlek. Avvisa sökvägar utanför tillåtet område, okända fält och överdrivna exporteringar. Ett explicit fel är att föredra framför tyst utökning av uppdraget.

Ett litet distributionsscenario: service‑ticket‑utkast

Anta att ett företag vill minska förberedelsetiden för utrustnings‑incident‑tickets. Agenten läser en godkänd manual och incident‑historik, och förbereder sedan ett utkast. Att skicka det till en leverantör förblir en separat operation. Detta är ett designscenario, inte ett påstående om att Brillnet för närvarande erbjuder denna funktion.

Tjänsteägaren väljer en utrustningsgrupp och definierar förväntad output: ett utkast som identifierar utrustning, symptom, händelsetid och saknad information. Utvecklaren exponerar två smala verktyg: godkänd‑dokument‑hämtning och utkast‑skapande i ett specificerat projekt. Den första versionen erbjuder varken meddelande‑funktion eller utrustnings‑konfiguration. Säkerhetsgranskaren kontrollerar datascope och central åtkomst‑återkallelse.

Testa en tillåten läsning, ett försök till tvär‑projekt‑läsning, ett dokument med skadlig instruktion och en skriv‑återförsök efter en timeout. Ett litet verktygskatalog räcker för att starta. Det måste verkställa de begränsningar som designen lovar.

Om sändning läggs till senare måste godkännandet omfatta mottagare och innehåll. Ändring av mottagare ogiltigförklarar tidigare godkännande. När en leverantör saknar idempotensstöd, lös en tvetydig timeout genom att kontrollera om meddelandet redan finns. Skicka inte om bara för att agenten inte mottog ett svar.

Vad du gör i morgon med en ägare

Processägaren väljer en handling och dess tillåtna konsekvens. Utvecklaren kartlägger verktyg, operation och resurs, inklusive den bredaste möjliga åtkomstvägen. Säkerhetsgranskaren kontrollerar var operatörsidentiteten slutar, var tjänsteidentiteten börjar och om modellen kan nå credentials. Första dagens leverans bör vara en kort karta och ett utförande vars resulterande tillstånd kan verifieras i mål‑systemet.

Mät accepterad utkastkvalitet, avvisade scope‑överträdelse och mänsklig granskningstid. Fler verktygs‑anrop är inte automatiskt värdefulla. Om korrigering tar längre tid än förberedelse sparar, begränsa uppdraget innan fler funktioner läggs till.

Teknisk vägledning och juridiska förpliktelser

OWASP och NIST erbjuder teknisk vägledning. MCP‑specifikationen definierar protokollkrav. Dessa källor bestämmer inte självständigt ett specifikt företags juridiska skyldigheter eller lagringsperioder för data. Fastställ tillämplig sektor, kontrakts‑ och lagkrav för processen. Denna guide förklarar kontroll‑design och ger ingen efterlevnads‑certifiering.

Gräns

Detta är mönster vi använder i vårt eget arbete. Denna sida påstår inte att hela verktyget är certifierat eller universellt förenligt med OWASP, NIST eller hela MCP‑specifikationen. Varje integration kräver fortfarande en egen hotmodell och säkerhetstest.

Om du vill veta hur Brillnet hanterar åtkomst, data och AI, se Security och Compliance and AI oversight.

Källor

De tekniska källorna stödjer de angivna principerna. Distributionsscenarierna och handlingsplanen är författarens designrekommendationer.

Kunskap

Branschguider och praktiska kontroller för AI-agenter.

Diskutera ditt arbetsflöde →