Datensatzzugriff prüfen, bevor Sie einen KI-Agenten ausrollen

Der sicherste Moment, um zu entdecken, dass Ihr KI-Agent jeden Gehaltsdatensatz in der Org lesen kann, liegt vor dem Rollout – nicht dann, wenn ein User ihn danach fragt. Da ein Agentforce-Agent den Zugriff des Users erbt, unter dem er läuft, ist seine Aktivierung in Wahrheit die Entscheidung, alles, was dieser User sehen kann, im Dialog und in Maschinengeschwindigkeit offenzulegen. Dieses Playbook prüft genau diesen Zugriff – zuerst.

Warum dieses Audit bei Agenten wichtiger ist als bei Menschen

Ein Mensch stößt selten an die volle Reichweite seines Zugriffs – er öffnet die Datensätze, an denen er arbeitet, und ignoriert den Rest. Ein Agent tut das nicht. Stellen Sie ihm eine Frage, und er ruft alles in Reichweite ab, verknüpft es und fasst es zusammen. Der Agent schafft keinen neuen Zugriff; er legt den bereits vorhandenen Zugriff offen – einschließlich des Zugriffs, den alle vergessen hatten.

Beim Audit geht es also nicht um die KI. Es geht darum, eine alte Frage mit neuer Dringlichkeit zu beantworten: Was kann dieser User tatsächlich sehen?

Schritt 1 – Die ausführende Identität des Agenten festnageln

Bestimmen Sie exakt, als welcher User (oder welche User-Konfiguration) der Agent ausgeführt wird. Alles, was der Agent lesen kann, wird durch die Berechtigungen und Freigaben dieser Identität definiert. Wenn er ein weit gefasstes menschliches Profil wiederverwendet, ist das bereits Befund Nummer eins – siehe Schritt 5.

Schritt 2 – Zugriff auf Objektebene prüfen

Prüfen Sie für diese Identität die Objekt-Berechtigungen aus Profil und Permission Sets:

• CRUD – welche Objekte kann sie lesen (Read) / erstellen (Create) / bearbeiten (Edit) / löschen (Delete)?
• Field-Level Security – welche sensiblen Felder sind sichtbar?
• View All / Modify All – jede dieser Berechtigungen auf einem Objekt (oder “View All Data”) umgeht das Sharing-Modell vollständig und ist das, was Sie mit höchster Priorität finden müssen.

Der Objektzugriff ist das Tor; wenn der Agent kein fachliches Recht hat, ein Objekt zu lesen, beheben Sie das hier, bevor Sie sich um Datensätze kümmern.

Schritt 3 – Zugriff auf Datensatzebene prüfen

Bestimmen Sie für die Objekte, die er lesen darf, welche Datensätze er sieht – über jeden Sharing-Mechanismus hinweg:

• Org-Wide Defaults – ist die Grundeinstellung Private oder Public? Ein Public-OWD bedeutet, dass der Agent jeden Datensatz dieses Objekts sieht.
• Rollenhierarchie – sitzt die Identität weit oben in der Hierarchie und erbt damit den Zugriff aller darunter?
• Sharing Rules – welche eigentümer- und kriterienbasierten Regeln schließen sie ein?
• Manuelle Freigaben – gibt es einmalige Gewährungen?
• Implizites Sharing – Zugriff auf Accounts, der untergeordnete Datensätze mitzieht: die Ebene, die Audits gern vergessen.

Das gewünschte Ergebnis: Hier ist die tatsächliche Menge an Datensätzen, die dieser Agent lesen kann, und der Mechanismus hinter jedem einzelnen.

Schritt 4 – Zu weit gefassten und veralteten Zugriff aufspüren

Mit diesem Gesamtbild suchen Sie nach den Gewährungen, die nicht da sein sollten:

• Ein Public-Read-OWD, das Private sein sollte.
• Kriterienbasierte Sharing Rules, die weit mehr treffen als beabsichtigt.
• Permission Sets mit einem “View All”, das aus einem vergangenen Projekt übrig geblieben ist.
• Manuelle Freigaben, die eigentlich nur temporär gedacht waren.

Jeder dieser Punkte ist etwas, das der Agent sonst offenlegen würde. Bereinigen Sie sie.

Schritt 5 – Dem Agenten Least Privilege geben

Verwenden Sie kein weit gefasstes menschliches Profil wieder. Richten Sie eine eigene Least-Privilege-Identität ein, die auf die Aufgabe des Agenten zugeschnitten ist, und legen Sie für feingranulare Regeln attributbasierte Richtlinien darüber. Der Agent sollte den minimal erforderlichen Zugriff haben – nichts, was er versehentlich erbt.

Schritt 6 – Bei jeder Änderung erneut prüfen

Der effektive Zugriff verändert sich: eine neue Sharing Rule, eine Rollenänderung, eine Anpassung am Permission Set – und die Reichweite des Agenten wächst leise mit. Führen Sie das Audit nach jeder Sharing-Änderung erneut durch, und unabhängig davon in regelmäßigen Abständen. “Beim Start korrekt eingegrenzt” ist nicht dasselbe wie “heute korrekt eingegrenzt”.

Ein mehrtägiges Audit in eine Frage verwandeln

Die Schritte 2–6 sind der schwierige Teil: den wahren effektiven Zugriff eines Users über CRUD, Field-Level Security und sechs Sharing-Mechanismen hinweg zu rekonstruieren – und ihn dann aktuell zu halten. Von Hand ist das tagelange Arbeit und leicht falsch zu machen.

AgentForceAccess ist genau dafür gebaut. Fragen Sie in einfachem Deutsch, was der ausführende User des Agenten tatsächlich sehen kann, und das Tool verfolgt jede Gewährung – Objektberechtigung, Sharing Rule, manuelle oder implizite Freigabe – und nennt den jeweiligen Mechanismus. Es macht aus “Wir glauben, der Agent ist richtig eingegrenzt” ein “Wir wissen es” – vor dem Rollout und nach jeder Änderung.

Häufig gestellte Fragen

Warum überhaupt den Zugriff prüfen, bevor man einen Agenten ausrollt?

Weil der Agent alles offenlegt, was sein ausführender User erreichen kann – sofort und auf Anfrage. Die meisten Orgs haben mehr offene Freigaben, als irgendjemand noch weiß. Das Audit findet diesen latenten Zugriff, den der Agent sonst preisgeben würde – bevor es passiert.

Was sollte das Audit konkret abdecken?

Zwei Ebenen. Objektebene: die CRUD-Berechtigungen und die Field-Level Security des ausführenden Users aus Profil und Permission Sets. Datensatzebene: welche konkreten Datensätze er über Org-Wide Defaults, Rollenhierarchie, Sharing Rules, manuelle Freigaben und implizites Sharing sehen kann.

Sollte der Agent das Konto eines echten Mitarbeiters verwenden?

Nein. Richten Sie eine eigene Least-Privilege-Identität ein, die auf die Aufgabe des Agenten zugeschnitten ist, statt ein weit gefasstes menschliches Profil wiederzuverwenden. Der Agent sollte den minimal nötigen Zugriff haben – und nichts, was er versehentlich erbt.

Wie oft sollten wir erneut prüfen?

Nach jeder Änderung an Org-Wide Defaults, Sharing Rules, Rollenhierarchie, Profilen oder Permission Sets – und unabhängig davon in regelmäßigen Abständen. Der effektive Zugriff verändert sich mit der Zeit, und die Reichweite des Agenten verändert sich mit ihm.