Problemet, næsten ingen taler om ved enterprise-AI-agenter
Din CFO spørger en AI-agent: “Hvad brugte vi på løn sidste kvartal?”
Agenten kalder jeres løn-API. API’et returnerer hver medarbejders løn, bonus og personnummer. Agenten opsummerer det til et klart totalbeløb.
Indtil videre fint — CFO’en må se dataene.
Nu stiller en praktikant samme spørgsmål til samme agent. Agenten kalder samme API. API’et returnerer samme payload. Agenten svarer.
Det er den stille fejltilstand i næsten enhver produktions-”enterprise AI agent” i dag.
Hvorfor RBAC på endpoint-niveau ikke er nok
De fleste integrationsplatforme — inklusive vores, indtil for nylig — sikrer API-adgang på endpoint-niveau. Enten må du kalde GET /payroll/employees eller også ikke. Den model fungerede, da mennesker byggede UI’er der filtrerede på klienten, og de eneste kaldere var betroede backend-tjenester.
Agenter bryder modellen på to måder:
- Agenter er generelle kaldere. De ved ikke, hvilke felter der skal skjules. De opsummerer alt, de modtager.
- Agenter handler på vegne af mange brugere. Én agentprofil kan betjene CEO og lagerarbejder. Endpoint-RBAC kan ikke skelne, når anmodningen først er autoriseret.
Resultatet: agenter bliver et confused-deputy-problem i industriel skala. En bruger uden direkte databaseadgang kan udtrække alle data, agenten kan nå — ved at stille det rigtige spørgsmål.
Hvor kilde-systemets RBAC kommer til kort
Standardsvaret er “lad kildesystemet håndtere det”. Send brugerens identitet til lønsystemet. Lad det filtrere.
Det virker — når kildesystemet understøtter det. I praksis:
- Legacy-systemer har ofte én servicekonto med fuld adgang. Ingen per-bruger-delegering.
- Tredjeparts SaaS-API’er mangler ofte række-niveau-tilladelser. Enten admin-scope eller intet.
- Egne interne API’er blev bygget før AI-agenter. Ingen tilføjede
filter_by_user. - Aggregationer lækker. Selv med rækkefiltrering beregnes summer og gennemsnit ofte på hele datasættet.
For en CISO betyder det, at jeres dataeksponeringsflade nu defineres af den svageste connector i agentens værktøjskasse.
Forsvar i dybden: policy-drevet svarsfiltrering
Vi har tilføjet et nyt lag til Copyls integrationsplatform: DataAccessPolicy. Det sidder mellem kildesystemets svar og agenten og anvender deklarative regler på returnerede data.
Modellen har tre kerneidéer:
1. Politikker knyttes til integrationshandlinger, ikke agenter.
Et løn-endpoint har én politik. Hver agent — hver bruger — der rører endpointet, gennemløber samme evaluator. En fejlkonfigureret agent kan ikke omgå reglen.
2. Regler matcher emnekontekst, ikke endpoint.
Evaluatoren ser hele emnet: brugeridentitet, roller, claims, agentprofil, enterprise. En regel kan sige “hvis brugerrolle indeholder CEO, tillad alle rækker” eller “hvis bruger er Employee, returner kun rækker hvor employeeId matcher deres ID.”
3. Push-down når muligt, post-filter som fallback.
Understøtter kilde-API filtrering, omskriver politikken anmodningen — ?employeeId=42 — så følsomme data ikke forlader kildesystemet. Uden push-down filtreres serverside før agenten ser det.
Det sidste punkt betyder noget for compliance. Filtrering ved forespørgselstid er reelt mere sikkert end bagefter. Post-filter er forsvar i dybden, ikke erstatning for kildesystemets kontroller.
Sådan ser det ud for Sec/Compliance
Tre egenskaber gør det styrbart:
Revisionssikkert. Hver evaluering skriver en revisionspost: hvilken politik kørte, hvilken regel matchede, rækker ind/ud, maskerede felter. I kan svare på “hvem så løndata tirsdag, og hvad blev filtreret?” med SQL.
Versionsstyret. Udkast → publiceret → arkiveret. Hver ændring er ny version. Diff, gendannelse og bevis for aktiv politik på en dato.
Testbart før publicering. Dry-run — filter evalueres og logges, svar ændres ikke. Valider mod reel trafik i uger. Publicering kræver bestået test eller eksplicit override.
For regulerede brancher (finans, sundhed, offentlig sektor under NIS2/DORA i Europa) bliver “stol på agenten” til “bevis agenten”.
Hvad det ikke løser
Ærlige begrænsninger:
- Delegering i kildesystemet er stadig bedre når tilgængelig. Brug det først. Policyfiltrering er til når I ikke kan.
- Aggregationer er tricky. Rækkefilter plus felt
total: 4.200.000over alle medarbejdere lækker. Vores model opdager aggregate-felter og fejler, fjerner dem eller kræver eksplicit opt-in — endpoint-for-endpoint tankegang kræves. - Feltdmaskering er ikke kryptering. Hashede personnumre er stadig PII. Maskering reducerer skade; den fjerner ikke forpligtelser.
- Politikker er kun så gode som deres regler. Forkert emnematch giver for meget eller for lidt. Derfor testkørsler og revisionssynlighed.
Hvad det betyder i praksis
Kører I AI-agenter mod systemer uden række-RBAC — de fleste legacy-ERP’er, løn, egne API’er før 2024 — har I en eksponering endpoint-kontrol ikke lukker.
Løsningen er strukturel, ikke prompt-tricks. “Vis kun brugerens egne data” kun i systemprompten holder til næste jailbreak. Gennemtving i integrationslaget med versioneret, revisionssikker politik er noget en CISO kan skrive under på.
Vi ruller DataAccessPolicy ud i Copyls marketplace-agenter, startende med løn, HR og finans. Opererer I i regulerede miljøer og vil gennemgå, hvor eksponeringen sidder i jeres stack, så kontakt os.
Copyl er en platform til at bygge, udrulle og styre enterprise-AI-agenter. Vores Integration Platform (CIP) forbinder agenter til forretningssystemer med policy fra ende til ende, audit-logning og versionskontrol.