Granska poståtkomst innan du distribuerar en AI-agent

Det säkraste ögonblicket att upptäcka att din AI-agent kan läsa varje lönepost i organisationen är innan du distribuerar den — inte när en användare ber den om det. Eftersom en Agentforce-agent ärver åtkomsten för den användare den körs som, är att slå på en agent i praktiken ett beslut att exponera, konversationellt och i maskinhastighet, allt den användaren kan se. Den här checklistan granskar den åtkomsten först.

Varför den här granskningen spelar större roll för agenter än för människor

En människa stöter sällan på den fulla omfattningen av sin åtkomst — de öppnar de poster de arbetar med och struntar i resten. En agent gör inte det. Ställ en fråga till den och den hämtar, sammanfogar och sammanfattar allt inom räckhåll. Agenten skapar ingen ny åtkomst; den blottlägger den åtkomst som redan finns — inklusive den åtkomst alla hade glömt bort.

Så granskningen handlar inte om AI:n. Den handlar om att besvara en gammal fråga med ny brådska: vad kan den här användaren faktiskt se?

Steg 1 — Fastställ agentens körande identitet

Avgör exakt vilken användare (eller användarkonfiguration) agenten körs som. Allt agenten kan läsa definieras av den identitetens behörigheter och delningar. Om den återanvänder en bred mänsklig profil är det redan fynd nummer ett — se Steg 5.

Steg 2 — Granska åtkomst på objektnivå

För den identiteten, granska objektbehörigheterna från dess profil och behörighetsuppsättningar:

CRUD — vilka objekt kan den läsa (Read) / skapa (Create) / redigera (Edit) / ta bort (Delete)?
Fältnivåsäkerhet — vilka känsliga fält är synliga?
View All / Modify All — om någon av dessa finns på ett objekt (eller “View All Data”) kringgås delningsmodellen helt och hållet, och det är det allra viktigaste att hitta.

Objektåtkomsten är grinden; om agenten inte har någon affärsmässig anledning att läsa ett objekt, åtgärda det här innan du bekymrar dig om poster.

Steg 3 — Granska åtkomst på postnivå

För de objekt den kan läsa, avgör vilka poster den ser, över varje delningsmekanism:

Organisationsomfattande standarder — är grundvärdet Private eller Public? En Public OWD innebär att agenten ser varje post av det objektet.
Rollhierarki — sitter identiteten högt upp i hierarkin och ärver alla under sig?
Delningsregler — vilka ägar- och kriteriebaserade regler omfattar den?
Manuella delningar — några engångstilldelningar?
Implicit delning — åtkomst till konton som drar in underordnade poster, det lager granskningar glömmer.

Resultatet du vill ha: här är den faktiska uppsättningen poster den här agenten kan läsa, och mekanismen bakom var och en.

Steg 4 — Jaga alltför bred och föråldrad åtkomst

Med helhetsbilden i handen, leta efter de tilldelningar som inte borde finnas där:

En Public Read-OWD som borde vara Private.
Kriteriebaserade delningsregler som matchar långt mer än avsett.
Behörighetsuppsättningar med “View All” kvar från ett tidigare projekt.
Manuella delningar som var tänkta att vara tillfälliga.

Var och en av dessa är något agenten annars skulle exponera. Rensa bort dem.

Steg 5 — Ge agenten lägsta behörighet

Återanvänd inte en bred mänsklig profil. Tilldela en dedikerad identitet med lägsta behörighet som är avgränsad till agentens uppgift, och lägg attributbaserade policyer ovanpå för finkorniga regler. Agenten bör ha den minsta åtkomst som krävs — inget som ärvts av misstag.

Steg 6 — Granska på nytt vid varje ändring

Den effektiva åtkomsten förändras: en ny delningsregel, en rollförflyttning, en justering av en behörighetsuppsättning, och agentens räckvidd expanderar tyst. Kör granskningen på nytt efter varje delningsändring, och med regelbundna intervall oavsett. “Korrekt avgränsad vid lansering” är inte detsamma som “korrekt avgränsad idag.”

Att förvandla en flerdagars granskning till en fråga

Steg 2–6 är den svåra delen: att rekonstruera en användares sanna effektiva åtkomst över CRUD, fältnivåsäkerhet och sex delningsmekanismer — och sedan hålla den aktuell. För hand är det dagar av arbete och lätt att göra fel.

AgentForceAccess är byggt för exakt detta. Fråga, på vanlig svenska, vad agentens körande användare faktiskt kan se, så spårar verktyget varje tilldelning — objektbehörighet, delningsregel, manuell eller implicit delning — och anger mekanismen. Det förvandlar “vi tror att agenten är rätt avgränsad” till “vi vet att den är det”, innan du distribuerar och efter varje ändring.

Vanliga frågor

Varför granska åtkomst innan en agent ens distribueras?

Eftersom agenten kommer att exponera allt dess körande användare kan nå, omedelbart och på begäran. De flesta organisationer har mer öppen delning än någon minns, så granskningen hittar den latenta åtkomst som agenten annars skulle blottlägga — innan den gör det.

Vad bör granskningen egentligen täcka?

Två lager. Objektnivå: den körande användarens CRUD-behörigheter och fältnivåsäkerhet från profilen och behörighetsuppsättningarna. Postnivå: vilka specifika poster de kan se via organisationsomfattande standarder, rollhierarki, delningsregler, manuella delningar och implicit delning.

Bör agenten använda en riktig anställds konto?

Nej. Tilldela en dedikerad identitet med lägsta behörighet som är avgränsad till agentens uppgift, i stället för att återanvända en bred mänsklig profil. Agenten bör ha den minsta åtkomst den behöver och inget som ärvts av misstag.

Hur ofta bör vi granska på nytt?

Efter varje ändring av organisationsomfattande standarder, delningsregler, rollhierarki, profiler eller behörighetsuppsättningar — och med regelbundna intervall oavsett. Den effektiva åtkomsten förändras över tid, och agentens räckvidd förändras med den.