Minsta privilegium för AI-agenter i ett SaaS med flera hyresgäster

Ett vanligt prototypsgenväg är att ge en agent en token, exponera alla verktyg och begränsa beteendet med en prompt. Det gör en demo enklare. I produktion skapar det ett problem: avsikten som skrivs i prompten blir den främsta barriären mellan ett modellfel och hela kontots kapacitet.

Minsta privilegium för en agent slutar inte med en read‑only‑roll. Som minimum bör vi begränsa fem saker: verktyg, operationstyp, målresurser, data och åtkomstens livslängd/identitet.

1. Begränsa verktygssamlingen

En agent som analyserar annonsresultat behöver inte funktioner för användarhantering. En agent som förbereder en efterlevnadsrapport behöver inte obegränsad skal‑åtkomst. En agent som organiserar filer i en katalog behöver inte hela filsystemet.

Ju bredare verktygskatalogen är, desto större blir ytan för:

• att välja fel verktyg;
• prompt‑injektion som leder till en oönskad åtgärd;
• oväntade kombinationer av verktyg;
• oavsiktlig dataexponering;
• konfigurationsmisstag på modellnivå.

Den första frågan bör därför inte vara “vad kan detta API göra?” utan:

vilka tre eller fem operationer behöver denna agent för just detta jobb?

Allt annat kan hållas osynligt.

2. Separera läs‑, skriv‑, drift‑ och destruktiva effekter

“Har åtkomst till kampanjer” är för brett.

För våra verktyg är en operationsmodell mer användbar:

Omfång	Betydelse	Exempel
read	hämta tillstånd och rapporter	hämta spendering, status eller resurslista
write	förbereda eller ändra konfiguration	skapa utkast, byta namn, ändra en parameter
operate	aktivera en affärskonsekvens	slå på en kampanj, publicera, starta synkronisering
destructive	radera, koppla bort eller återkalla	ta bort en resurs, ta bort åtkomst, utföra svår‑återställningsbar förändring

En agent kan förbereda en konfiguration utan rätt att aktivera den. Den kan läsa fakturering utan att ändra betalningsinställningar. Den kan skapa ett meddelandeutkast utan rätt att skicka det.

Den gränsen är ofta där användbar autonomi finns.

3. Verktygsomfång räcker inte – begränsa även resursen

En behörighet som:

campaign.write

är fortfarande bred om en operatör har tio konton men agenten bara ska arbeta på ett.

Där det är praktiskt bör auktorisation ta hänsyn till:

Auktorisationsbeslutet inkluderar användare, agent, funktion, operationstyp, tenant/konto/projekt, resurs och uppgiftssammanhang.

vem
+ vilken agent
+ vilken funktion
+ vilken operationstyp
+ vilken tenant/konto/projekt
+ vilken resurs
+ vilket uppgiftssammanhang

Vår interna Brillnet Ads MCP kräver explicita konto‑/kundidentifierare inom ett tillåtet gränssnitt. En generell fråga bör inte bara gissa vilket konto som ska bearbetas.

Detta är särskilt viktigt i multi‑tenant SaaS. Att välja fel tenant kan vara allvarligare än ett resonemangsfel i själva modellen.

4. Begränsa in‑ och utdata

Minsta privilegium gäller även data.

En agent kan behöva:

• aggregerad spendering, inte hela listan med användardata;
• uppgiftens status, inte varje bilaga;
• bekräftelse på att en credential finns, inte dess värde;
• en personidentifierare, inte hela profilen;
• utvalda dokumentfält, inte hela arkivet.

Om ett verktyg kan returnera ett minimalt objekt, returnera det minimala objektet. Exponera inte ett komplett leverantörs‑payload för modellen bara för att API‑et gör det tillgängligt.

Samma princip gäller loggning: ett audit‑spår ska innehålla tillräckligt bevis, inte en duplicering av all källdata.

Read: AI‑agent audit trails

5. En credential bör inte leva längre eller bredare än nödvändigt

En långlivad administratortoken i varje komponents miljö är lätt att sätta upp. Den är också svår att begränsa på ett säkert sätt.

Vi föredrar ett mönster som liknar:

1. Agenten får inte hemligheten.
2. Gateway verifierar identitet, omfång och resurs.
3. Den erhåller en kortlivad credential.
4. Den utför ett tillåtet leverantörsanrop.
5. Hemligheten hamnar aldrig i modellens svar eller audit‑post.

Enligt dokumentationen får vår interna Ads MCP kortlivade leverantörstoken vid anropstillfället. Credential‑material hanteras utanför modellkontext och skrivs inte till applikationsloggar.

Kontrollera behörighet vid exekvering

En agent kan ha startat en uppgift medan operatören hade en viss roll. Tio minuter senare kan den rollen ha återkallats. Ett långt arbetsflöde bör inte anta att behörigheten från sessionens början fortfarande gäller.

För materiella operationer kontrolleras auktorisation när verktyget exekveras.

Samma gäller godkännande. Samtycke för en åtgärd är inte behörighet för godtyckliga efterföljande handlingar.

En prompt är inte en ACL

En instruktion som:

du får bara läsa data och får aldrig radera något

kan vara en användbar beteenderegel. Den ersätter inte en kontroll som tekniskt blockerar DELETE.

Om modellen kan nå ett destruktivt verktyg och en credential som tillåter radering, så finns den möjligheten. Prompten ber bara modellen att avstå från att använda den.

En praktisk separation är:

• prompt: vad agenten ska göra;
• auktorisation/policy: vad agenten får göra;
• leverantör/API‑roll: vad den tekniska identiteten kan göra hos leverantören.

Det säkraste arrangemanget är när alla tre lager är i linje men ingen enskild lager är den enda kontrollen.

Profiler i stället för en super‑agent

I vårt interna annonseringsverktyg separerar vi läs‑/planeringskapacitet, kampanjhanteringskapacitet och en ägarnivå för sällsynta administrativa operationer.

Namnen är inte viktiga. Poängen är att vanlig analys inte bör köras kontinuerligt med högsta privilegienivå.

En liknande design någon annanstans kan vara:

Profil	Tillåtet arbete	Ytterligare gräns
research‑agent	söka, läsa, sammanfatta	inga tillståndsändringar
operations‑agent	läsa, skapa utkast, uppdatera godkända fält	operativt omfång
admin‑workflow	administrativa operationer	separat anrop, identitet/omfång, obligatoriskt godkännande, snäv tidsram

Ett kompromiss‑ eller misstag i en agent ger då inte automatiskt åtkomst till varje klass av operation.

Begränsa filsystem och “universella” verktyg

Två kategorier förtjänar särskild uppmärksamhet.

Skal / kommandokörning

Ett obegränsat skal kan kringgå de flesta noggrant designade verktygsmodeller. Om en agent kan köra vilket kommando som helst som en brett privilegierad OS‑användare, ger fin‑granulerade omfång någon annanstans begränsat skydd.

Syftesbyggda verktyg eller vitlistade kommandon i en begränsad miljö är vanligtvis enklare att resonera kring.

Filssystem

En agent som behöver skriva en rapport till /workspace/reports behöver inte /etc, en operatörs hemkatalog eller CI‑hemligheter.

I vår interna Ads MCP är filoperationer begränsade till godkända server‑sidiga platser eller avgränsade payloads. Godtyckliga systemvägar avvisas.

En låg‑nivå‑gateway behöver fortfarande omfång

Ibland är en generell gateway användbar för nya leverantörs‑endpoint innan ett dedikerat verktyg finns. Den får inte bli en flyktväg.

Den bör klassificera:

• HTTP‑metod;
• endpoint;
• resurs;
• payload‑karaktäristik;
• huruvida operationen skriver eller förstör tillstånd.

Endast därefter bör den mappa begäran till erforderliga behörigheter.

Om raw_request kan använda en full‑access‑token utan policy‑kontroller, är den i praktiken administratörs‑åtkomst oavsett hur noggrant de andra verktygen har avgränsats.

Tillfällig upphöjning för hög‑risk‑åtgärder

Istället för att permanent tilldela ett brett omfång kan ett system använda kontrollerad upphöjning:

1. Agenten förbereder operationen;
2. Gateway upptäcker att högre privilegium krävs;
3. En person godkänner exakt parametrar;
4. Systemet beviljar behörighet endast för den operationen eller en kort period;
5. Behörigheten löper ut efter exekvering;
6. Audit‑spår registrerar godkännande och resultat.

Detta är inte obligatoriskt överallt. För kritiska operationer minskar det den tid då bred behörighet existerar.

Read: When should an AI agent require human approval?

Mall för inventering av kapabiliteter

Innan produktion, skriv ner gränsen:

Agent / arbetsflöde	Verktyg	Operation	Resurs	Data	Godkännande	Credential	Audit
kampanjrapportering	Ads‑rapport	read	konto A	metrik utan PII	nej	kortlivad	ja
kampanjförberedelse	kampanjverktyg	write	konto A	konfiguration	nej/konditionell	kortlivad	ja
kampanjaktivering	kampanj‑operate	operate	kampanj X	budget + status	ja	kortlivad	ja
resursradering	admin‑verktyg	destructive	specifik resurs	minimum	ja	upphöjd	ja

Detta är mycket mer användbart än att skriva “agenten har åtkomst till Google Ads”.

Anti‑mönster

En API‑nyckel för hela systemet

Roller kan inte separeras rent och åtkomst för ett arbetsflöde blir svår att återkalla.

Samma verktygssats för varje agent

Den bredaste funktionen i katalogen blir en del av riskytan för varje agent.

“Read‑only” endast i prompten

Om backend fortfarande accepterar skrivningar är read‑only bara en begäran, inte en kontroll.

Automatisk utökning av omfång efter 403

Saknad behörighet är en anledning att stoppa och fatta ett beslut, inte att “försöka igen som admin”.

Credential i modellkontext

En modell behöver inte värdet av en hemlighet för att be en betrodd gateway utföra ett tillåtet anrop.

Checklista för minsta privilegium för en agent

• Agenten ser bara verktyg som krävs för dess roll.
• Läs‑ och skriv‑behörigheter är separerade.
• Att aktivera en operativ effekt har ett annat omfång än att förbereda konfiguration.
• Destruktiva operationer har ett extra hinder.
• Behörigheten är begränsad till tenant/konto/projekt/resurs.
• Otydliga målresurser gissas inte automatiskt.
• Verktyg returnerar minsta nödvändiga data.
• Credential hålls utanför modellkontext.
• Token är kortlivade där det är praktiskt.
• Auktorisation kontrolleras vid exekvering, inte bara vid sessionens start.
• Fil‑ och skal‑åtkomst är begränsad eller ersatt med syftesbyggda verktyg.
• En rå gateway kringgår inte policy.
• Privilegium‑upphöjning är explicit och audit‑bar.
• Åtkomst kan återkallas centralt.

Genomarbetat exempel: kvalitetsrapportering för en produktionslinje

Betrakta ett föreslaget arbetsflöde, inte en implementering som rapporterats här. En tillverkare vill ha en morgensammanfattning av avvikelser för linje L1. Agenten kombinerar räknare, statusar och åtgärdsdeadlines. Den beslutar inte om en produkt får släppas. Kvalitetschefen äger processen; applikationsadministratören äger åtkomstkonfigurationen.

Starta med behörighet att läsa L1‑poster, exklusive bilagor och anställdas detaljer. Spara rapporten i en intern katalog. Ge inte funktioner för att stänga avvikelser, ändra inspektionsresultat eller skicka kundkommunikation bara för att samma API stödjer dem.

Om teamet senare behöver åtgärdsuppgifter, lägg till behörighet att skapa ett utkast för ett namngivet team. Att skapa det utkastet får inte ändra produktstatus. Uppdatera åtkomst‑inventeringen och identifiera vem som hanterar ett felaktigt tilldelat uppdrag. Identifierarna i detta exempel är designantaganden, inte Brillnet‑implementeringsresultat.

Vad MCP‑auktorisation fastställer

Denna guide använder MCP‑specifikationsversion 2026‑07‑28. Dess HTTP‑auktorisationsmodell kräver kontroll att ett access‑token utfärdats för den avsedda servern. Ett giltigt token för en annan tjänst bör inte ge MCP‑åtkomst. MCP‑säkerhetsanvisningar behandlar också vidarebefordran av klient‑token till downstream‑API utan korrekt validering.

Det avgör ändå inte om en användare får läsa kund B:s post. Applikationsauktorisation måste lösa relationen mellan identitet och målresurs. OAuth‑scopes och tenant‑filtrering täcker olika delar av gränsen. Båda är viktiga. Kontrollera protokoll‑detaljer mot de versioner som faktiskt används av din klient och server; “MCP‑compatible” säger lite om åtkomstrestriktioner.

Verifiera avslag lika väl som framgång

En korrekt rapport bevisar att den tillåtna vägen fungerar. Den bevisar inte att andra vägar är stängda. Under acceptans, behåll resultat för ett litet urval av konkreta kontroller:

• begär samma objekttyp från en annan tenant;
• anropa en skrivfunktion via rapporteringsprofilen;
• kör efter att operatörens roll har återkallats;
• nå en fil utanför rapportkatalogen;
• försök samma förbjudna operation via en generell gateway.

Förvänta avslag utan tillståndsändring eller dataexponering. Registrera kontroll‑identifierare, policy‑version och resultat, exklusive hemligheter och fullständiga kundposter. Detta är föreslagna acceptanstester för detta arbetsflöde, inte ett komplett säkerhetstestprogram.

Ha en ägare för behörighetsändringar

Åtkomst tenderar att växa inkrementellt: en ny connector, ett undantag, en extra katalog. Fråga om agenten fortfarande utför samma jobb. En connector som stödjer meddelandesändning får inte tyst utöka en rapporteringsprofil.

Processägaren godkänner affärsbehovet. Administratören provisionerar och återkallar åtkomst. Säkerhetsägaren granskar undantag och kringvägar. I ett litet företag kan en person ha flera roller, men besluten bör vara spårbara. Sätt en granskningsintervall baserad på förändringsfrekvens och möjliga konsekvenser. Ta bort installationsbehörigheter när installationen är klar.

Morgon, inventera en agent. Ta bort en behörighet som dess uppgift inte kräver och verifiera avslag utanför den godkända gränsen. Det ger användbara bevis utan att kräva en fullständig arkitekturreplacering.

Bevis och begränsningar

OWASP‑anvisningar stödjer begränsade verktyg och auktorisationskontroller. NIST publicerar en katalog av säkerhetskontroller. Vår läs‑/skriv‑/operate‑/destructive‑modell och genomarbetade exempel är ingen lagstiftning eller ett efterlevnads‑certifikat, utan tekniska rekommendationer. Fastställ tillämpliga organisatoriska skyldigheter separat. Intern Ads MCP‑dokumentation, version 1.0 daterad 28 juli 2026, beskriver den citerade kontrolldesignen; den bevisar inte oberoende produktionsdrift för en kund.

Gräns

Minsta privilegium minskar den maximala påverkan av ett fel eller missbruk. Det garanterar inte att en tillåten operation är substantivt korrekt. Vi kombinerar därför med indata‑validering, godkännande för hög‑påverkan‑åtgärder och ett audit‑spår.

Återgå till safe AI agents guide eller se Brillnet Security.

Två fiktiva organisationer, en begränsad uppgift

I en dedikerad demonstrationsmiljö, ge en assistent tillstånd att läsa en godkänd procedur i fiktiv organisation A och förbereda ett utkast. Uteslut godkännande, publicering, ändringar av tillstånd och tillgång till organisation B. Den verkställande tjänsten upprättar organisationskontext från den autentiserade aktören och tillåten relation; en ändrad identifierare i begäran är inte behörighet att använda en annan organisations data.

Testa den tillåtna läsningen, ett uteslutet godkännande och en begäran om organisation B. För varje fall, registrera det förväntade resultatet och inspektera det faktiska resultatet. Avslagsmålen måste lämna det förbjudna tillståndet oförändrat och inte returnera några orelaterade hyresgästuppgifter. Behåll policyversionen och den minsta händelsemetadata som behövs för att rekonstruera kontrollen, samtidigt som du utesluter autentiseringsuppgifter och onödigt dokumentinnehåll.

Inkludera en ofarlig instruktion i den syntetiska källan som ber om en icke-relaterad export. Behandla det som dokumentinnehåll. Den godkända uppgiften och serverbehörigheterna förblir grunden för den tillåtna operationen. Detta visar hur hantering av opålitliga instruktioner och åtkomstkontroll måste samverka i den föreslagna designen.

I Pulsar, registrera krav, risk, åtgärd och fiktiva bevis för granskning. Detta testar hur ditt team dokumenterar kontrollen. Det betyder inte att den offentliga Pulsar-prövningen avslöjar en MCP-gateway eller implementerar varje agentbehörighet i din arkitektur. Granska testperioden på 14 dagar, obligatorisk betalningsmetod och avbokningsvillkor och kom överens om en extern integration separat om du behöver en.

Källor

• OWASP AI Agent Security Cheat Sheet. Accessed: 2026-10-02.
• OWASP Authorization Cheat Sheet. Accessed: 2026-10-02.
• Model Context Protocol — The 2026-07-28 Specification. Accessed: 2026-10-02. Källor kontrollerade: 2026-10-10.
• MCP — HTTP authorization specification, 2026-07-28 — Transporttillstånd och resursbundna tokens.
• MCP — security best practices — Integrationssäkerhet och behörighetsgränser.
• NIST SP 800-53 Rev. 5 — Tillträdeskontroll och revisionskontrollprinciper.
• OWASP — LLM01 Prompt Injection — Otillförlitliga dokumentinstruktioner och agentrisker.
• OWASP — Logging Cheat Sheet — Användbara händelseregister och utesluten känslig information.
• Pulsar GRC — data-exchange scope — Gräns ​​för offentliga integrationsanspråk.
• Publicerad produktomfattning och testvillkor — Publicerad produktomfattning och testvillkor.

Granska villkoren och påbörja den 14-dagars provperioden

Granska en AI-operation: auktorisering, resultat och verifierat tillstånd

Livsmedelsproduktion CAPA: från ett resultat till effektivitetsgranskning

En farmaceutisk SOP ändrad: kontrollera utbildnings- och källversionen