Umgehen Agentforce-Agenten das Salesforce-Sharing?

Jedes Sicherheitsgespraech ueber Agentforce beginnt mit derselben Frage: Umgehen die Agenten unsere Sharing-Regeln? Die kurze Antwort lautet nein - und zu verstehen, warum, erklaert sowohl, warum Agentforce von Grund auf sicher ist, als auch, wo das eigentliche Risiko liegt.

Agenten laufen als Benutzer - und erben dessen Zugriff

Ein Agentforce-Agent hat keinen eigenen, magischen Blick auf Ihre Daten. Er wird als Salesforce-Benutzer ausgefuehrt, und jeder Datenabruf, den er durchfuehrt, wird gegen Folgendes dieses Benutzers geprueft:

• Objektberechtigungen (Profil + Permission Sets)
• Field-Level Security
• Sharing auf Datensatzebene - Org-Wide Defaults, Rollenhierarchie, Sharing-Regeln sowie manuelle und implizite Freigaben

Wenn der ausfuehrende Benutzer einen Datensatz nicht sehen kann, kann es der Agent auch nicht. Agentforce arbeitet innerhalb desselben Enterprise-Sicherheitsmodells - Profile, Permission Sets, Sharing, rollenbasierter Zugriff -, das auch den Rest Ihrer Org steuert. Darueber hinaus unterstuetzt es attributbasierte Richtlinien fuer Regeln wie “nur EU-Vertriebsmitarbeiter duerfen diesen Workflow ausloesen”.

Agentforce-Agenten umgehen keine Salesforce-Berechtigungen. Sie nutzen jeden bereits vorhandenen Zugriff aggressiv aus.

Dieser zweite Satz ist die ganze Geschichte.

Das eigentliche Risiko: verstaerkte Offenlegung, keine Umgehung

Hier kommt der unangenehme Teil. Die meisten Orgs haben weit mehr offenes Sharing, als sich irgendjemand bewusst konfiguriert zu haben erinnert - jahrelange Sharing-Regeln, breite Permission Sets, Roll-ups ueber die Rollenhierarchie und “voruebergehende” manuelle Freigaben, die nie entfernt wurden.

Ein Mensch stoesst fast nie auf das volle Ausmass dessen, worauf er technisch zugreifen kann. Er oeffnet die Datensaetze, an denen er arbeitet, und ignoriert den Rest. Ein Agent nicht. Stellen Sie ihm eine Frage, und er ruft alles ab, verknuepft und fasst es zusammen, was in Reichweite des ausfuehrenden Benutzers liegt - einschliesslich Daten, von denen dieser Benutzer vergessen hatte, dass er sie sehen konnte.

Der Agent gewaehrt also keinen neuen Zugriff. Er legt den Zugriff offen, den Sie bereits hatten - konversationell und sofort. Zu weit gefasstes Sharing, das jahrelang verborgen war, ist nur noch einen einzigen Satz als Prompt entfernt.

Warum Agenten die Risikorechnung veraendern

Zwei Dinge machen den Unterschied zu einer Person mit denselben Berechtigungen aus:

1. Geschwindigkeit und Skalierung. Ein Agent liest und kombiniert Datensaetze weit schneller als jeder Mensch, sodass eine falsch zugeschnittene Berechtigung sofort und wiederholt ausgenutzt wird.
2. Kein Freigabe-Checkpoint. Einmal ausgerollt, handeln Agenten anhand von Konfiguration und Kontext, ohne fuer eine menschliche Pruefung innezuhalten - und entfernen damit einen Checkpoint, auf den sich das traditionelle Sicherheitsmodell stillschweigend verlassen hat.

Das Berechtigungsmodell wurde nicht schwaecher. Was es nutzt, wurde nur weitaus gruendlicher.

Was Sie vor dem Deployment tun sollten

Die Loesung besteht nicht darin, Agentforce zu misstrauen - sondern zu wissen, was sein Benutzer sehen kann, bevor Sie ihn einschalten:

1. Fuehren Sie einen Access Review fuer den ausfuehrenden Benutzer des Agents durch - auf Objekt- und Datensatzebene. Die entscheidende Frage ist dieselbe, um die es in diesem gesamten Blog geht: Wer kann was sehen, und warum. Ein Schritt-fuer-Schritt-Leitfaden findet sich unter Datensatzzugriff pruefen, bevor Sie einen KI-Agenten ausrollen.
2. Verschaerfen Sie die Baseline. Setzen Sie die Org-Wide Defaults so restriktiv, wie es das Geschaeft zulaesst; von dort aus wird der Zugriff nur erweitert.
3. Bereinigen Sie Sharing-Regeln und Permission Sets. Entfernen Sie die breiten, veralteten Berechtigungen, die der Agent andernfalls erben wuerde.
4. Geben Sie dem Agent eine eigene Least-Privilege-Identitaet statt eines breiten menschlichen Profils, ergaenzt um attributbasierte Richtlinien.
5. Pruefen Sie nach jeder Sharing-Aenderung erneut - Zugriffe driften, und damit auch das, was der Agent erreichen kann.

Verstehen, was der Agent sehen kann - in einfachem Deutsch

Die Schritte 1 und 5 sind die schwierigen: den tatsaechlichen effektiven Zugriff eines Benutzers ueber CRUD, Field-Level Security und sechs Sharing-Mechanismen hinweg zu rekonstruieren und ihn aktuell zu halten, waehrend sich die Org veraendert.

Genau das leistet AgentForceAccess. Fragen Sie in einfachem Deutsch, was ein Benutzer - oder der ausfuehrende Benutzer Ihres Agents - tatsaechlich sehen kann, und es verfolgt jede Berechtigung zurueck und nennt den dahinterstehenden Mechanismus. Es ist der Access Review, der aus “wir glauben, der Agent ist korrekt zugeschnitten” ein “wir wissen es” macht - bevor Sie live gehen.

Häufig gestellte Fragen

Ignorieren Agentforce-Agenten Sharing-Regeln und laufen als Admin?

Nein. Ein Agent wird als ein bestimmter Salesforce-Benutzer ausgefuehrt und ist an dessen Profil, Permission Sets, Field-Level Security und das Datensatz-Sharing-Modell gebunden. Er kann keine Datensaetze sehen, die dieser Benutzer nicht sehen koennte. Ist der ausfuehrende Benutzer jedoch ueberprivilegiert, erbt der Agent genau diese ueberhoehten Rechte.

Warum gilt KI-Zugriff dann als Sicherheitsrisiko, wenn er Berechtigungen respektiert?

Weil die meisten Orgs mehr offenes Sharing angesammelt haben, als irgendjemand ahnt. Ein Mensch stoesst selten auf jeden einzelnen Datensatz, auf den er technisch zugreifen darf; ein Agent ruft sie auf Anfrage bereitwillig ab und fasst sie zusammen. Der Agent schafft keinen neuen Zugriff - er legt den Zugriff offen, den Sie bereits hatten.

Was ist das Wichtigste, das man vor dem Deployment eines Agents tun sollte?

Pruefen Sie, was der ausfuehrende Benutzer des Agents tatsaechlich sehen kann - Objekt fuer Objekt und auf Datensatzebene. Verschaerfen Sie Org-Wide Defaults, Sharing-Regeln und Permission Sets, sodass der Benutzer (und damit der Agent) nur den noetigen Zugriff hat, und gehen Sie dann live.

Kann ich einem Agent engeren Zugriff geben als dem Benutzer, der ihn ausfuehrt?

Ja. Richten Sie fuer den Agent einen dedizierten Benutzer oder eine Permission-Set-Konfiguration nach dem Least-Privilege-Prinzip ein, statt ein breites menschliches Profil wiederzuverwenden, und legen Sie attributbasierte Richtlinien darueber. Der Agent sollte nur den fuer seine Aufgabe minimal erforderlichen Zugriff haben.