Recordtoegang auditen voordat je een AI-agent uitrolt

Het veiligste moment om te ontdekken dat je AI-agent elk salarisrecord in de org kan lezen, is voordat je hem uitrolt — niet wanneer een gebruiker hem dat vraagt. Omdat een Agentforce-agent de toegang erft van de gebruiker waaronder hij draait, is hem aanzetten in feite de beslissing om alles wat die gebruiker kan zien conversationeel en op machinesnelheid bloot te leggen. Dit playbook audit die toegang eerst.

Waarom deze audit voor agents belangrijker is dan voor mensen

Een mens stuit zelden op de volle omvang van zijn toegang — hij opent de records waar hij aan werkt en negeert de rest. Een agent niet. Stel hem een vraag en hij haalt alles binnen handbereik op, koppelt het en vat het samen. De agent creëert geen nieuwe toegang; hij toont de toegang die er al is — inclusief de toegang die iedereen vergeten was.

De audit gaat dus niet over de AI. Hij gaat over het beantwoorden van één oude vraag met nieuwe urgentie: wat kan deze gebruiker echt zien?

Stap 1 — Bepaal de draaiende identiteit van de agent

Stel precies vast onder welke gebruiker (of gebruikersconfiguratie) de agent draait. Alles wat de agent kan lezen, wordt bepaald door de permissies en shares van die identiteit. Hergebruikt hij een breed menselijk profiel, dan is dat al bevinding nummer één — zie Stap 5.

Stap 2 — Audit toegang op objectniveau

Beoordeel voor die identiteit de objectpermissies uit het profiel en de permission sets:

• CRUD — welke objecten mag hij Read / Create / Edit / Delete?
• Field-level security — welke gevoelige velden zijn zichtbaar?
• View All / Modify All — al deze rechten op een object (of “View All Data”) omzeilen het sharing-model volledig en hebben de hoogste prioriteit om te vinden.

Objecttoegang is de poort; heeft de agent zakelijk niets te zoeken in een object, los het dan hier op voordat je je druk maakt over records.

Stap 3 — Audit toegang op recordniveau

Bepaal voor de objecten die hij wel mag lezen welke records hij ziet, over elk sharing-mechanisme heen:

• Org-wide defaults — is de basislijn Private of Public? Een Public OWD betekent dat de agent elk record van dat object ziet.
• Rollenhiërarchie — zit de identiteit hoog in de hiërarchie, waardoor hij alles eronder erft?
• Sharing rules — welke ownership- en criteria-based regels nemen hem mee?
• Handmatige shares — eenmalige toekenningen?
• Impliciete sharing — toegang tot accounts die child records meetrekt, de laag die audits vergeten.

Het gewenste resultaat: hier is de werkelijke set records die deze agent kan lezen, en het mechanisme achter elk ervan.

Stap 4 — Jaag op te brede en verouderde toegang

Met dit beeld in handen zoek je naar de toekenningen die er niet horen te zijn:

• Een Public Read OWD die Private zou moeten zijn.
• Criteria-based sharing rules die veel meer matchen dan bedoeld.
• Permission sets waarop “View All” is blijven staan van een vorig project.
• Handmatige shares die tijdelijk hadden moeten zijn.

Elk hiervan is iets dat de agent anders zou blootleggen. Snoei ze weg.

Stap 5 — Geef de agent minimale rechten

Hergebruik geen breed menselijk profiel. Richt een eigen identiteit met minimale rechten in, afgestemd op de taak van de agent, en leg daar attribute-based policies overheen voor fijnmazige regels. De agent hoort de minimaal vereiste toegang te hebben — niets dat per ongeluk meekomt.

Stap 6 — Audit opnieuw bij elke wijziging

Effectieve toegang verschuift: een nieuwe sharing rule, een rolwissel, een aanpassing aan een permission set, en het bereik van de agent breidt stilletjes uit. Draai de audit opnieuw na elke sharing-wijziging, en sowieso op een vast ritme. “Bij de lancering correct afgebakend” is niet “vandaag correct afgebakend.”

Een meerdaagse audit terugbrengen tot één vraag

Stappen 2–6 zijn het lastige deel: het reconstrueren van de werkelijke effectieve toegang van een gebruiker over CRUD, field-level security en zes sharing-mechanismen — en die actueel houden. Met de hand is dat dagen werk en gemakkelijk fout te doen.

AgentForceAccess is precies hiervoor gebouwd. Vraag in gewoon Nederlands wat de draaiende gebruiker van de agent echt kan zien, en het traceert elke toekenning — objectpermissie, sharing rule, handmatige of impliciete share — en benoemt het mechanisme. Het maakt van “we denken dat de agent goed is afgebakend” een “we weten het zeker”, voordat je uitrolt en na elke wijziging.

Veelgestelde vragen

Waarom überhaupt toegang auditen voordat je een agent uitrolt?

Omdat de agent alles toont wat zijn draaiende gebruiker kan bereiken, direct en op verzoek. De meeste orgs hebben meer open sharing dan iemand zich herinnert, dus de audit vindt de latente toegang die de agent anders zou blootleggen — voordat het gebeurt.

Wat moet de audit eigenlijk dekken?

Twee lagen. Objectniveau: de CRUD-permissies en field-level security van de draaiende gebruiker, uit zijn profiel en permission sets. Recordniveau: welke specifieke records hij ziet via org-wide defaults, rollenhiërarchie, sharing rules, handmatige shares en impliciete sharing.

Moet de agent het account van een echte medewerker gebruiken?

Nee. Richt een eigen identiteit met minimale rechten in, afgestemd op de taak van de agent, in plaats van een breed menselijk profiel te hergebruiken. De agent hoort de minimale toegang te hebben die hij nodig heeft en niets dat per ongeluk meekomt.

Hoe vaak moeten we opnieuw auditen?

Na elke wijziging in org-wide defaults, sharing rules, rollenhiërarchie, profielen of permission sets — en sowieso op een vast ritme. Effectieve toegang verschuift in de loop van de tijd, en het bereik van de agent verschuift mee.