Problemet få pratar om kring enterprise-AI-agenter
Din CFO frågar en AI-agent: “Vad spenderade vi på löner förra kvartalet?”
Agenten anropar ert löne-API. API:et returnerar varje medarbetares lön, bonus och personnummer. Agenten sammanfattar det till en tydlig totalsiffra.
Hittills bra — CFO:n får se den datan.
Nu ställer en praktikant samma fråga till samma agent. Agenten anropar samma API. API:et returnerar samma nyttolast. Agenten svarar.
Det här är det tysta fel läget i nästan varje produktionssatt ”enterprise AI agent” i dag.
Varför RBAC på endpoint-nivå inte räcker
De flesta integrationsplattformar — inklusive vår, tills nyligen — säkrar API-åtkomst på endpoint-nivå. Antingen får du anropa GET /payroll/employees eller inte. Den modellen fungerade när människor byggde UI som filtrerade klient-side, och när enda anroparna var betrodda backend-tjänster.
Agenter bryter modellen på två sätt:
- Agenter är generella anropare. De vet inte vilka fält som ska döljas. De sammanfattar allt de får.
- Agenter agerar för många olika användare. En och samma agentprofil kan betjäna VD och lagerarbetare. RBAC på endpoint-nivå kan inte skilja dem åt när anropet väl är auktoriserat.
Resultatet: agenter blir ett ”confused deputy”-problem i industriell skala. En användare utan direkt databasåtkomst kan plocka ut all data agenten når, bara genom att ställa rätt fråga.
Där källsystemets RBAC brister
Standardsvaret är ”låt källsystemet sköta det”. Skicka användarens identitet till lönesystemet. Låt lönesystemet filtrera.
Det fungerar — när källsystemet stödjer det. I praktiken:
- Äldre system har ofta ett enda tjänstekonto med full åtkomst. Det finns ingen per-användardelegering.
- SaaS-API:er från tredje part saknar ofta radnivå-behörigheter. Antingen har du admin-scope eller inget.
- Egna interna API:er byggdes innan AI-agenter fanns. Ingen lade till
filter_by_user. - Aggregationer läcker. Även när radfiltrering finns beräknas summor och medelvärden ofta på hela mängden.
För en CISO betyder det att er datayta nu definieras av den svagaste kopplaren i agentens verktygslåda.
Försvar på djupet: policystyrd svarsfiltrering
Vi har lagt till ett nytt lager i Copyls integrationsplattform: DataAccessPolicy. Det sitter mellan källsystemets svar och agenten, och tillämpar deklarativa regler på det som returneras.
Modellen har tre kärnidéer:
1. Policyer sitter på integrationsåtgärder, inte agenter.
Ett löne-endpoint har en policy. Varje agent — varje användare — som rör endpointen går genom samma utvärderare. En feltolkad agent kan inte kringgå regeln.
2. Regler matchar subjektskontext, inte endpoint.
Utvärderaren ser hela subjektet: användaridentitet, roller, claims, agentprofil, enterprise. En regel kan säga “om användarroll innehåller CEO, tillåt alla rader” eller “om användare är Employee, returnera endast rader där employeeId matchar deras ID.”
3. Push-down när det går, post-filtrering som fallback.
Om käll-API:et stödjer filtrering skriver policyn om anropet — ?employeeId=42 — så att känslig data aldrig lämnar källsystemet. Om push-down inte stöds filtreras svaret på serversidan innan agenten ser det.
Sista punkten spelar roll för regelefterlevnad. Filtrering i frågan är genuint säkrare än efterhandsfiltrering. Post-filtrering är försvar på djupet, inte ersättning för källsystemets kontroller.
Så här ser det ut för Sec/Compliance
Tre egenskaper gör detta styrbart:
Revisionssäkert. Varje utvärdering skriver en revisionspost: vilken policy som körde, vilken regel som matchade, hur många rader som kom in, hur många som gick ut, hur många fält som maskerades. Du kan svara på “vem såg lönedata i tisdags, och vad filtrerades?” med en SQL-fråga.
Versionshanterat. Policyer är utkast → publicerad → arkiverad. Varje ändring är en ny version. Du kan diff:a versioner, återställa gamla och visa vad som var aktivt ett visst datum.
Testbart före publicering. Policyer kan köras i torrkörningsläge — filtret utvärderas och loggas, men svaret ändras inte. Du kan validera mot verklig trafik i två veckor innan du slår på. Publicering kräver godkänt test eller explicit override.
För reglerade branscher (finans, hälso- och sjukvård, offentlig sektor under NIS2/DORA i Europa) blir ”lita på agenten” till ”bevisa agenten”.
Vad det inte löser
Ärlighet om begränsningar spelar roll:
- Delegering i källsystemet är fortfarande bättre när det finns. Använd det först. Policyfiltrering är för när du inte kan.
- Aggregationer är knepiga. Ett radfilter som returnerar en medarbetares lön, tillsammans med ett fält
total: 4 200 000beräknat på alla medarbetare, läcker data. Vår modell upptäcker aggregatfält och antingen felmarkerar, strippar dem eller kräver explicit opt-in. Det finns inget fullt automatiskt svar — det kräver tankegång per endpoint. - Fältmaskering är inte kryptering. Hashade personnummer i ett svar är fortfarande personuppgifter i regulatorisk mening. Maskering minskar skadeverkan; den tar inte bort skyldigheten.
- Policyer är bara så bra som sina regler. Fel subjektsmatchning ger för lite eller för mycket tillstånd. Därför kräver vi testkörningar och revisionsynlighet.
Vad det betyder i praktiken
Om ni kör AI-agenter mot system som saknar RBAC på radnivå — de flesta legacy-ERP, de flesta lönesystem, de flesta egna API:er byggda före 2024 — har ni en exponering som åtkomstkontroll på endpoint-nivå inte kan stänga.
Fixen är strukturell, inte en prompt-trick. Säg åt agenten i systemprompten ”visa bara användarens egna data” och ni har en policy som håller tills nästa jailbreak. Genomdriv det i integrationslagret med en versionshanterad, revisionsbar policy och ni har något en CISO kan skriva under.
Vi rullar ut DataAccessPolicy i Copyls marketplace-agenter nu, med start i löne-, HR- och finansintegrationer. Om ni driver AI-agenter i en reglerad miljö och vill prata igenom var exponeringen sitter i er stack, hör av er.
Copyl är en plattform för att bygga, driftsätta och styra enterprise-AI-agenter. Vår integrationsplattform (CIP) kopplar agenter till affärssystem med policy från ände till ände, revisionslogg och versionskontroll.