Omzeilen Agentforce-agents Salesforce-sharing?

Elk beveiligingsgesprek over Agentforce begint met dezelfde vraag: omzeilen de agents onze sharingregels? Het korte antwoord is nee — en begrijpen waarom verklaart zowel waarom Agentforce veilig is van opzet als waar het echte risico zit.

Agents draaien als een gebruiker — en erven diens toegang

Een Agentforce-agent heeft geen eigen magische kijk op je data. Hij wordt uitgevoerd als een Salesforce-gebruiker, en elke dataopvraging die hij doet, wordt getoetst aan de:

• Objectrechten van die gebruiker (profiel + permission sets)
• Field-level security
• Record-level sharing — org-wide defaults, role hierarchy, sharingregels, handmatige en impliciete shares

Als de uitvoerende gebruiker een record niet kan zien, kan de agent dat ook niet. Agentforce opereert binnen hetzelfde enterprise-beveiligingsmodel — profielen, permission sets, sharing, role-based access — dat de rest van je org regelt. Het ondersteunt daarbovenop ook attribuutgebaseerde policies, voor regels als “alleen EU-salesagents mogen deze workflow starten.”

Agentforce-agents omzeilen Salesforce-rechten niet. Ze maken agressief gebruik van alle toegang die al bestaat.

Die tweede zin is het hele verhaal.

Het echte risico: versterkte blootstelling, geen omzeiling

Hier komt het ongemakkelijke deel. De meeste organisaties hebben veel meer open sharing dan iemand zich herinnert te hebben geconfigureerd — jaren aan sharingregels, brede permission sets, role-hierarchy roll-ups en “tijdelijke” handmatige shares die nooit zijn verwijderd.

Een mens stuit bijna nooit op de volledige reikwijdte van wat hij technisch kan benaderen. Hij opent de records waar hij aan werkt en negeert de rest. Een agent niet. Stel hem een vraag en hij haalt alles op, koppelt en vat het samen wat binnen het bereik van de uitvoerende gebruiker valt — inclusief data waarvan die gebruiker vergeten was dat hij ze kon zien.

De agent verleent dus geen nieuwe toegang. Hij brengt de toegang naar boven die je al had, conversationeel en ogenblikkelijk. Te ruime sharing die jarenlang sluimerde, is nu één prompt verwijderd.

Waarom agents de risicorekensom veranderen

Twee dingen maken dit anders dan een persoon met dezelfde rechten:

1. Snelheid en schaal. Een agent leest en combineert records veel sneller dan enig mens, dus een verkeerd afgebakend recht wordt onmiddellijk en herhaaldelijk misbruikt.
2. Geen goedkeuringsmoment. Eenmaal uitgerold handelen agents op basis van configuratie en context zonder te pauzeren voor menselijke beoordeling — waarmee een controlemoment verdwijnt waar het traditionele beveiligingsmodel stilzwijgend op leunde.

Het rechtenmodel werd niet zwakker. Datgene wat het gebruikt, werd veel grondiger.

Wat te doen voordat je uitrolt

De oplossing is niet om Agentforce te wantrouwen — het is om te weten wat zijn gebruiker kan zien voordat je hem aanzet:

1. Voer een toegangsreview uit voor de uitvoerende gebruiker van de agent — op object- én recordniveau. De relevante vraag is dezelfde waar deze hele blog over gaat: wie kan welk record zien, en waarom. Voor een stap-voor-stap-playbook, zie recordtoegang auditen voordat je een AI-agent uitrolt.
2. Scherp de basislijn aan. Stel org-wide defaults zo restrictief in als het bedrijf toelaat; toegang wordt alleen vanaf daar verbreed.
3. Snoei sharingregels en permission sets. Verwijder de brede, verouderde toekenningen die de agent anders zou erven.
4. Geef de agent zijn eigen identiteit met de minste rechten in plaats van een breed menselijk profiel, plus attribuutgebaseerde policies.
5. Controleer opnieuw na elke sharingwijziging — toegang verschuift, en daarmee ook wat de agent kan bereiken.

Weten wat de agent kan zien — in gewone taal

Stap 1 en 5 zijn de lastige: het reconstrueren van de werkelijke effectieve toegang van een gebruiker over CRUD, field-level security en zes sharingmechanismen heen, en die actueel houden naarmate de org verandert.

Dat is precies wat AgentForceAccess doet. Vraag, in gewone taal, wat een gebruiker — of de uitvoerende gebruiker van je agent — daadwerkelijk kan zien, en het traceert elke toekenning en benoemt het mechanisme erachter. Het is de toegangsreview die “we denken dat de agent correct is afgebakend” verandert in “we weten het” voordat je uitrolt.

Veelgestelde vragen

Negeren Agentforce-agents sharingregels en draaien ze als admin?

Nee. Een agent wordt uitgevoerd als een specifieke Salesforce-gebruiker en is gebonden aan diens profiel, permission sets, field-level security en het record sharing-model. Hij kan geen records zien die die gebruiker niet kon zien. Maar als de uitvoerende gebruiker te veel rechten heeft, erft de agent die overmatige rechten.

Waarom wordt AI-toegang dan als beveiligingsrisico gezien als de rechten worden gerespecteerd?

Omdat de meeste organisaties meer open sharing hebben opgebouwd dan iemand beseft. Een mens stuit zelden op elk record waartoe hij technisch toegang heeft; een agent haalt ze op verzoek probleemloos op en vat ze samen. De agent creëert geen nieuwe toegang — hij legt de toegang bloot die je al had.

Wat is het allerbelangrijkste om te doen voordat je een agent uitrolt?

Controleer wat de uitvoerende gebruiker van de agent daadwerkelijk kan zien — object voor object, en op recordniveau. Scherp org-wide defaults, sharingregels en permission sets aan zodat de gebruiker (en dus de agent) alleen de toegang heeft die nodig is, en rol dan pas uit.

Kan ik een agent minder toegang geven dan de gebruiker die hem uitvoert?

Ja. Richt een dedicated gebruiker of permission-set-configuratie met de minste rechten in voor de agent in plaats van een breed menselijk profiel te hergebruiken, en leg daar attribuutgebaseerde policies overheen. De agent zou de minimale toegang moeten hebben die zijn taak vereist.