Het probleem waar bijna niemand over praat bij enterprise-AI-agenten
Uw CFO vraagt een AI-agent: “Wat hebben we vorig kwartaal aan salarissen uitgegeven?”
De agent roept uw salaris-API aan. De API retourneert salaris, bonus en persoonsnummer van elke medewerker. De agent vat het samen tot een helder totaal.
Tot zover goed — de CFO mag die gegevens zien.
Nu stelt een stagiair dezelfde vraag aan dezelfde agent. De agent roept dezelfde API aan. De API retourneert dezelfde payload. De agent antwoordt.
Dit is de stille foutmodus van bijna elke productie-”enterprise AI agent” vandaag.
Waarom RBAC op endpointniveau niet genoeg is
De meeste integratieplatformen — waaronder het onze, tot voor kort — beveiligen API-toegang op endpointniveau. U mag GET /payroll/employees aanroepen of niet. Dat model werkte toen mensen UI’s bouwden die client-side filterden en de enige aanroepers vertrouwde backends waren.
Agenten doorbreken het model op twee manieren:
- Agenten zijn generieke aanroepers. Ze weten niet welke velden verborgen moeten worden. Ze vatten samen wat ze binnenkrijgen.
- Agenten handelen namens veel verschillende gebruikers. Eén agentprofiel kan CEO en magazijnmedewerker bedienen. Endpoint-RBAC kan ze niet onderscheiden zodra het verzoek is geautoriseerd.
Het resultaat: agenten worden een confused-deputy-probleem op industriële schaal. Een gebruiker zonder directe database-toegang kan alle data extraheren die de agent bereikt — met de juiste vraag.
Waar bron-RBAC tekortschiet
Het standaardantwoord is “laat het bronsysteem het afhandelen”. Gebruikersidentiteit doorgeven aan salaris. Laten filteren.
Dat werkt — als het bronsysteem het ondersteunt. In de praktijk:
- Legacy-systemen hebben vaak één serviceaccount met volledige toegang. Geen delegatie per gebruiker.
- SaaS-API’s van derden missen vaak rijniveau-rechten. Of admin-scope of niets.
- Eigen interne API’s werden gebouwd vóór AI-agenten. Niemand voegde
filter_by_usertoe. - Aggregaties lekken. Zelfs met rijfiltering worden sommen en gemiddelden vaak over de volledige set berekend.
Voor een CISO wordt uw data-expositie-oppervlak nu bepaald door de zwakste connector in de gereedschapskist van de agent.
Verdediging in diepte: beleidsgestuurde responsfiltering
We hebben een nieuwe laag toegevoegd aan Copyls Integration Platform: DataAccessPolicy. Die zit tussen het bronsysteem-antwoord en de agent en past declaratieve regels toe op wat wordt teruggegeven.
Het model heeft drie kernideeën:
1. Beleid hangt aan integratie-acties, niet aan agenten.
Een salaris-endpoint heeft één beleid. Elke agent — elke gebruiker — die het endpoint raakt, doorloopt dezelfde evaluator. Een verkeerd geconfigureerde agent kan de regel niet omzeilen.
2. Regels matchen op subjectcontext, niet op endpoint.
De evaluator ziet het volledige subject: identiteit, rollen, claims, agentprofil, enterprise. Een regel kan zeggen “als gebruikersrol CEO bevat, alle rijen toestaan” of “als gebruiker Employee is, alleen rijen waar employeeId overeenkomt met hun ID.”
3. Pushdown waar mogelijk, post-filter als fallback.
Ondersteunt de bron-API filtering, dan herschrijft het beleid het verzoek — ?employeeId=42 — zodat gevoelige data het bronsysteem niet verlaat. Zonder pushdown wordt server-side gefilterd voordat de agent ziet.
Dat laatste punt telt voor compliance. Filteren op querytijd is echt veiliger dan achteraf. Post-filter is verdediging in diepte, geen vervanging voor broncontroles.
Wat dit betekent voor Sec/Compliance
Drie eigenschappen maken het bestuurbaar:
Auditeerbaar. Elke evaluatie schrijft een auditrecord: welk beleid, welke regel, rijen in/uit, gemaskerde velden. U beantwoordt “wie zag salarisdata dinsdag en wat werd gefilterd?” met SQL.
Versiebeheerd. Concept → gepubliceerd → gearchiveerd. Elke wijziging is een nieuwe versie. Diff, herstel en bewijs wat actief was op een datum.
Testbaar vóór publicatie. Dry-run — filter wordt geëvalueerd en gelogd, respons niet gewijzigd. Valideren tegen echt verkeer gedurende weken. Publiceren vereist geslaagde test of expliciete override.
Voor gereguleerde sectoren (financiële diensten, gezondheidszorg, publieke sector onder NIS2/DORA in Europa) wordt “vertrouw de agent” “bewijs de agent”.
Wat het niet oplost
Eerlijke grenzen:
- Delegatie in het bronsysteem blijft beter wanneer beschikbaar. Gebruik die eerst. Beleidsfiltering is voor wanneer u niet kunt.
- Aggregaties zijn lastig. Rijfilter met salaris van één plus veld
total: 4.200.000over alle medewerkers lekt. Ons model detecteert aggregaatvelden en faalt, strip ze of vereist expliciete opt-in — endpoint-voor-endpoint denken nodig. - Veldmaskering is geen encryptie. Gehashte persoonsnummers blijven PII. Maskering verkleint schade; het haalt verplichtingen niet weg.
- Beleid is zo goed als de regels. Verkeerde subjectmatch geeft te veel of te weinig toestemming. Daarom testruns en audit-zichtbaarheid.
Wat dit praktisch betekent
Als u AI-agenten draait tegen systemen zonder rijniveau-RBAC — de meeste legacy-ERP’s, salaris, eigen API’s vóór 2024 — heeft u een blootstelling die endpoint-controle niet sluit.
De oplossing is structureel, geen prompt-truc. Alleen in de system prompt “toon eigen data” houdt tot de volgende jailbreak. Afdwingen in de integratielaag met versioneerbaar, auditeerbaar beleid is iets waar een CISO achter kan staan.
We rollen DataAccessPolicy uit in Copyls marketplace-agenten, te beginnen met salaris, HR en finance. Werkt u in een gereguleerde omgeving en wilt u bespreken waar de blootstelling in uw stack zit, neem contact op.
Copyl is een platform om enterprise-AI-agenten te bouwen, uit te rollen en te besturen. Onze Integration Platform (CIP) verbindt agenten met bedrijfssystemen met end-to-end policy-enforcement, auditlogging en versiebeheer.