7 misstag med dataintegritet för AI-agenter som tyst läcker ditt företags data (och hur du undviker dem)

De flesta dataläckor från AI-agenter beror inte på att modellen i hemlighet memorerar ditt företag. De kommer från konfigurations- och arkitekturmisstag som du kan namnge och åtgärda. De stora: att köra på ett konto på konsumentnivå vars standardinställningar tränar på dina indata, att låta en agent ärva en persons breda behörigheter, att koppla en publik agent till interna system, och att lämna den "dödliga triaden" intakt (privat data, opålitligt innehåll och en extern sändväg) så att en enda prompt injection kan läsa din data och mejla ut den. Det sista mönstret är precis hur EchoLeak (CVE-2025-32711) exponerade känslig data genom Microsoft 365 Copilot från ett preparerat mejl, utan ett enda klick. Lösningarna är inte exotiska, och nästan alla är beslut som fattas innan agenten lanseras, inte en checklista som lämnas över till dig efter att något har läckt.

Det här är listan vi går igenom innan vi placerar en agent vi byggt inuti ett annat företags stack, skriven så att en icke-teknisk ägare kan upptäcka samma misstag i sin egen uppsättning eller hos en leverantör. Om du hellre vill att vi håller den här linjen där den ska vara åt dig, se hur vi driver ansvarsfull AI-styrning och riskhantering. Allt nedan är ditt att använda hur som helst.

Först en distinktion som nästan varje artikel om ämnet suddar ut, eftersom att missa den är misstag noll. Det finns två helt olika sätt som data lämnar genom en agent, och de har helt olika lösningar:

• Leverantörens datahantering. Lagrar eller tränar modelleverantören på dina indata? Det här är ett avtal du skriver under och en kontonivå du väljer. Det löses med villkor och konfiguration.
• Exfiltrering vid körning. Kan agenten luras, i det ögonblick den körs, att skicka din data någonstans den inte borde gå? Det här löses med arkitektur, inte med ett avtal.

Enkätsiffrorna visar att köpare känner detta även när de inte kan sätta ord på det. I Clouderas undersökning av nästan 1 500 seniora IT-ledare i 14 länder planerar 96 procent att utöka sin användning av AI-agenter under det kommande året, men 53 procent (mer än hälften) anger dataintegritet som sitt främsta hinder för införande. De sju misstagen nedan är där den rädslan blir en verklig läcka, och där lösningen finns.

Misstag 1: att köra produktionsagenter på konton på konsumentnivå

Det här är det billigaste misstaget att göra och det enklaste att åtgärda. Någon kopplar ett arbetsflöde till ett personligt ChatGPT- eller Gemini-konsumentkonto för att det redan finns där, och nu styrs ditt företags data av konsumentvillkor som aldrig var avsedda för den.

Klyftan mellan konsument- och företagsnivåer är skarp. På företagssidan är mönstret konsekvent mellan leverantörer: ingen träning på din data som standard, ett kort lagringsfönster för missbruksövervakning, och starkare alternativ på begäran. OpenAI:s API lagrar data i 30 dagar för missbruksövervakning och raderar den sedan, och tränar inte på den som standard. Från och med den 14 september 2025 kortade Anthropic ned API-loggarnas lagring från 30 dagar till 7 dagar, och API-indata och -utdata används aldrig för träning. Googles Vertex AI (företagsnivån) är konfigurerbar utan träningsanvändning. På konsumentsidan vänds standardinställningarna: ChatGPT för konsument lagrar konversationer på obestämd tid om du inte raderar dem, och Gemini för konsument har en lagring på upp till 36 månader och kan användas för att förbättra produkter.

Lösningen: placera varje produktionsagent på ett företags-API eller företagskonto, aldrig en personlig inloggning. Tekniken är identisk. Villkoren är det inte, och villkoren är hela skillnaden mellan data som förblir styrd och data som tyst blir träningsmaterial.

Misstag 2: alltför breda behörigheter som agenten ärver

Den vanligaste läckan vid körning är inte smart. En agent får en anställds åtkomst, eller värre, en administratörsnyckel, så att den tekniskt sett kan se allt den personen kan se. Sedan ställs en fråga till den, eller den luras till en, som sträcker sig långt bortom dess arbete.

Microsofts Cloud Adoption Framework anger regeln tydligt: "Ge agenter åtkomst endast till de specifika datakällor som krävs för deras funktion. Ge inte bred åtkomst till all organisationsdata." En supportagent behöver inte ditt lönesystem. En schemaläggningsagent behöver inte kunddatabasen. När en agent agerar å en persons vägnar bör den ärva den personens behörigheter genom att säkert vidarebefordra dennes identitet, så att en helpdeskagent visar en anställd bara dennes egen HR-post, inte allas.

Lösningen: ge varje agent en egen identitet, avgränsad till minsta möjliga privilegier, och låt den ärva den agerande användarens behörigheter i stället för att bära med sig en stående övermängd. Testet är enkelt. Om agenten luras i morgon avgränsas skadan av den smala uppsättning den beviljats, inte av allt som ett överprivilegierat konto kunde nå.

Misstag 3: publika agenter kopplade till intern data

En chatbot på din webbplats och en agent som skriver utkast till interna rapporter är två olika säkerhetsvärldar, och läckan sker i samma ögonblick som någon låter dem dela en backend. En publik agent tar emot indata från vem som helst på internet. Om samma agent också kan fråga intern affärsdata har du byggt en dörr från det öppna webben rakt in i dina privata system.

Microsofts ramverk drar den hårdaste linjen här: "Publika agenter får inte ha åtkomst till intern affärsdata." Håll konfidentiellt och publikt åtskilt med en fysisk eller logisk gräns (deras exempel använder separata hanteringsgrupper för "corp" och "online"). Poängen är att gränsen är strukturell, inte en förhoppning om att prompten ska hålla.

Lösningen: lägg en verklig gräns mellan agenter som tar emot opålitliga publika indata och agenter som rör konfidentiell data. Om en enda agent verkligen måste göra båda, så är det den mest riskfyllda design du kan välja, och den behöver de triadbrytande kontrollerna i nästa misstag, inte bara en noggrann systemprompt.

Misstag 4: att ignorera den dödliga triaden

Det här är misstaget som förvandlar de tre första till en faktisk exfiltrering. Simon Willison, den oberoende experten som myntade begreppet "prompt injection", namngav den "dödliga triaden" för AI-agenter: tre villkor som, tillsammans, gör att en enda injicerad instruktion kan stjäla din data.

När alla tre finns på plats gömmer en angripare en instruktion inuti det opålitliga innehållet. Modellen, med Willisons ord, "kommer gladeligen att följa vilka instruktioner som än når den, oavsett om de kom från operatören eller från någon annan källa." Den läser din privata data och skickar ut den, och inget i prompten sa åt den att inte lita på mejlet.

Den krassa delen, och anledningen till att det här är arkitektur och inte ett prompt-engineering-problem: "vi vet fortfarande inte hur man förhindrar detta till 100 procent på ett pålitligt sätt." Dokumenterade angrepp har drabbat Microsoft 365 Copilot, GitHubs MCP-server och GitLab Duo. Under en vecka i januari 2026 avslöjades sårbarheter för indirekt prompt injection i fyra AI-produktivitetsverktyg, alla med samma triadmönster.

Lösningen: bryt ett ben. Neka den externa sändvägen så att stulen data inte har någonstans att ta vägen, eller låt aldrig en agent som läser opålitligt innehåll samtidigt ha åtkomst till privat data i samma kontext. Du behöver inte vinna den ovinnbara kampen att fånga varje injection. Du behöver se till att även en lyckad injection inte har någon väg ut.

Misstag 5: att behandla EchoLeak som någon annans problem

Det är värt att namnge en verklig incident, eftersom "den dödliga triaden" låter abstrakt tills du ser den utförd. EchoLeak (CVE-2025-32711) var en zero-click-attack mot Microsoft 365 Copilot. En angripare skickade ett preparerat mejl. Copilot, som gjorde sitt vanliga jobb, bearbetade det mejlet (opålitligt innehåll), hade åtkomst till användarens interna data (privat data), och hade ett sätt att skicka information utåt (extern kommunikation). Den dolda instruktionen fullbordade exponeringen av känslig data utan någon användarinteraktion alls. Ingen klickade på någonting.

Misstaget här är att anta att en läcka kräver en oförsiktig anställd. EchoLeak krävde ingen. Försvaret som spelade roll var inte "utbilda personalen att upptäcka nätfiske", eftersom det inte fanns något för en människa att upptäcka. Försvaret var arkitektoniskt: en agent som inte kan både läsa angriparkontrollerat innehåll och exfiltrera kan inte vändas mot dig på det här sättet.

Lösningen: anta att zero-click är hotmodellen, inte undantaget. Om din agent läser något en utomstående kan påverka (mejl, webbinnehåll, uppladdade filer, ärenden) och den också kan skicka data utåt, så har du ett EchoLeak-format hål tills du stänger en av de två förmågorna eller hårt inhägnar sändvägen.

Misstag 6: ingen gräns för dataresidens eller lagring

Vissa läckor är inte dramatiska exfiltreringar, de är långsam drift. Data hamnar lagrad i en region du aldrig gick med på, eller ligger kvar i loggar längre än din policy tillåter, helt enkelt för att ingen satte gränsen. Microsofts ramverk listar detta som grundläggande styrning: identifiera platsen för varje datakälla, agentkörning och utdatalagring, håll data i regioner eller on-prem som matchar din residenspolicy, och håll den krypterad i vila.

Den lugnande nyheten, som nästan ingen artikel säger rakt ut, är hur mycket du kan låsa fast. Företagsmönstret mellan leverantörer är ingen-träning-som-standard plus ett kort lagringsfönster plus starkare garantier på begäran. Anthropic erbjuder kvalificerade företag ett avtal om noll datalagring (Zero Data Retention, ZDR), under vilket indata och utdata inte lagras längre än vad som behövs för att screena för missbruk. OpenAI erbjuder ZDR via ett förhandlat avtal och dataresidens. Båda låter dig välja var data bor. Att själv hosta en öppen modell (till exempel med Ollama) håller data helt lokal med noll lagring hos tredje part.

Lösningen: besluta och dokumentera gränsen före lansering. Vilken region som håller datan, hur länge loggar lever, om du behöver ZDR, och om känslig hämtning ska köras i din egen VPC eller on-prem. ZDR är vanligtvis endast för API och förhandlas, och det täcker inte automatiskt varje produkt om du inte lägger till det, så detaljen spelar roll.

Misstag 7: att behandla integritet som en checklista du lämnar över

Det sista misstaget är strukturellt. Den mesta vägledningen, inklusive det utmärkta Microsoft-ramverket, antar att du själv bygger och styr agenten, så den ger dig en 3 000 ord lång hög med Entra-identiteter, Purview-etiketter och hanteringsgrupper. Det är rätt svar för ett stort IT-team. För de flesta företag är det en checklista som ingen har tid eller specialistkunskap att fullt ut implementera, så den levereras halvfärdig, och luckorna är precis där data läcker.

Misstaget är att behandla kontrollerna som dokumentation snarare än som en arkitektur som någon äger från början till slut. En checklista som listar "isolera konfidentiell data" och "begränsa externa integrationer till betrodda MCP-servrar" är bara så bra som personen som kopplar in den, validerar varje extern kommunikation, och bygger upp incidentplanen för att snabbt inaktivera en agent när något går fel.

Lösningen: se till att en part faktiskt äger gränsen, inte bara dokumentet. Antingen bygger du den interna förmågan att implementera och underhålla hela stacken, eller så låter du en operatör designa bort de här felmönstren och driva dem, med en publicerad gräns du kan peka på. Den felaktiga mellanvägen är en lista över kontroller och ingen som är ansvarig för att de håller.

Hur de sju misstagen och lösningarna hänger ihop

Här är alla sju på ett ställe, sorterade efter om lösningen är ett avtal du skriver under eller en arkitektur du bygger. Den uppdelningen är det snabbaste sättet att veta vilket team som äger var och en.

Lägg märke till att bara två av de sju löses med ett avtal. De andra fem är arkitektur och ägarskap, vilket är den del en PDF med bästa praxis inte kan göra åt dig. Det är också den ärliga anledningen till att de auktoritativa källorna lämnar en lucka: de talar om för dig vad du ska bygga, inte vem som ska bygga det rätt inuti dina specifika system.

Vad som faktiskt aldrig lämnar, när gränsen är byggd rätt

Det är lätt att läsa sju misstag och dra slutsatsen att AI-agenter är ett integritetsminfält. Det är de inte, när linjen dras medvetet. På företagsvillkor är dina indata inte träningsdata, och lagringen är dagar, inte för evigt (7 för Anthropics API, 30 för OpenAI, sedan raderad). Med ZDR lagras de inte längre än missbruksscreeningen. Med dataresidens fastlåst stannar de i din region. Med VPC- eller on-prem-hämtning lämnar känslig data aldrig din perimeter alls. Med maskering vid gränsen strippas de fält som aldrig borde resa innan något skickas. Med avgränsning till minsta möjliga privilegier som ärver användarens behörigheter kan agenten bara någonsin nå det som den agerande personen redan kunde nå.

Det är en specifik, försvarbar gräns, och att kunna formulera den tydligt är hela poängen. Faran var aldrig att modellen tyst absorberade ditt företag. Det är de sju konfigurations- och arkitekturmisstagen ovan, vart och ett möjligt att förebygga innan den första agenten går live.

Det här är arbetet vi gör inuti andra företags stackar: att välja villkoren, avgränsa identiteterna, isolera det publika från det konfidentiella, bryta triaden, och äga gränsen så att den håller. Om du vill ha de här misstagen bortdesignade ur dina agenter innan de rör något verkligt, boka en kostnadsfri konsultation nedan så kartlägger vi din gräns tillsammans.