Drei inzwischen behobene Schwachstellen in Salesforce Agentforce zeigen, wie aus gewöhnlichen CRM-Daten ein Steuerkanal für einen privilegierten Unternehmensagenten werden kann.
Zenity Labs veröffentlichte die Angriffskette am 24. September unter dem Namen SalesBleed. Ein externer Angreifer konnte eine manipulierte Information über ein öffentliches Salesforce-Web-to-Lead-Formular in das CRM schreiben. Sobald Agentforce diesen Datensatz später verarbeitete, interpretierte der Agent die darin versteckten Anweisungen als Teil seiner Aufgabe.
Nach Angaben der Forscher ließ sich damit sensible CRM-Information ohne weiteren Klick eines Mitarbeiters an Infrastruktur des Angreifers übertragen. Eine dritte Schwachstelle betraf die Slack-Integration und erlaubte es, Nachrichten unter der Identität des Agenten zu versenden, ohne den tatsächlichen Auftraggeber für Empfänger sichtbar zu machen.
Salesforce hat die von Zenity gemeldeten Probleme behoben. Zenity bestätigte den Abschluss der Fixes am 21. September. Ein Missbrauch außerhalb der Sicherheitsforschung ist bislang nicht dokumentiert.
Ein öffentliches Lead-Formular wurde zum indirekten Prompt
Der Einstieg in die Datenexfiltration benötigte nach Zenitys Beschreibung keinen kompromittierten Salesforce-Account.
Salesforce-Kunden können Web-to-Lead-Formulare öffentlich bereitstellen, damit Interessenten Kontaktdaten an das CRM senden. Genau diese legitime Eingabefläche nutzten die Forscher.
Der manipulierte Lead enthielt neben normalen Daten Anweisungen für den AI-Agenten. Wenn ein Mitarbeiter Agentforce anschließend mit einer Aufgabe beschäftigte, bei der dieser Datensatz in den Kontext gelangte, konnte das Modell die fremde Anweisung ausführen.
Das ist eine indirekte Prompt Injection: Der Angreifer spricht nicht direkt mit dem Agenten. Er verändert Daten, die der Agent später als vertrauenswürdigen Arbeitskontext liest.
Bei einem normalen CRM-Eintrag wäre das zunächst nur untrusted text. Für einen Agenten mit Such- und Aktionsrechten kann derselbe Text Entscheidungen beeinflussen.
Trusted URLs verhinderten die Exfiltration nicht zuverlässig
Agentforce besitzt Kontrollen für externe URLs. Sie sollen verhindern, dass ein Agent Daten beliebig an nicht freigegebene Ziele überträgt.
Zenity fand nach eigenen Angaben mehrere Möglichkeiten, diese URL-Prüfung zu umgehen. Die Forscher konnten dadurch sensible CRM-Werte in extern geladenen Ressourcen unterbringen. Der Browser beziehungsweise die Agentenoberfläche löste anschließend die Anfrage an die Infrastruktur des Forschers aus.
Der entscheidende Punkt ist die Kombination zweier getrennt sinnvoll wirkender Funktionen: Der Agent darf interne Daten lesen und Inhalte darstellen, während die URL-Kontrolle externe Ziele begrenzen soll.
Wenn die zweite Grenze umgangen wird, wird die Leseberechtigung des Agenten zum Exfiltrationskanal.
Zenity meldete die Probleme am 1. Juni an Salesforce. Nach Angaben der Forscher wurden die URL-bezogenen Fixes über die folgenden Monate ausgerollt; am 21. September waren alle drei gemeldeten Schwachstellen geschlossen.
Die Slack-Aktion verbarg, wer eine Nachricht ausgelöst hatte
Die dritte Schwachstelle lag nicht im Datenzugriff, sondern in der Identität des Agenten.
Agentforce kann über Slack Aktionen ausführen. Zenity stellte fest, dass viele schreibende Slack-Aktionen Schutzmechanismen besaßen: eine Bestätigung vor dem Versand und eine Kennzeichnung, welcher Nutzer die Aktion veranlasst hatte.
Bei der untersuchten Funktion zum Antworten in einem Thread fehlten diese Kontrollen laut Zenity.
Damit konnte ein Nutzer den Agenten dazu bringen, eine Nachricht in einen vorhandenen Slack-Thread zu schreiben, ohne dass der Empfänger erkennen konnte, wer die Aktion ursprünglich ausgelöst hatte. Kombiniert mit der indirekten Prompt Injection ließ sich derselbe Mechanismus von extern beeinflussen.
Das Problem ist damit nicht einfach „AI kann Phishing schreiben“. Entscheidend ist, dass die Nachricht unter einer bereits vertrauenswürdigen internen Agentenidentität erscheint.
Salesforce ergänzte nach Zenitys Angaben eine Bestätigung und eine Kennzeichnung des auslösenden Nutzers.
Datenherkunft und Aktionsrecht brauchen getrennte Policies
SalesBleed zeigt einen wiederkehrenden Fehler in Unternehmensagenten: Berechtigungen werden häufig danach vergeben, was ein Agent für seine legitime Aufgabe können soll. Weniger sichtbar ist, welche Daten seine Entscheidungen beeinflussen dürfen.
Ein Sales-Agent muss möglicherweise CRM-Datensätze lesen. Daraus folgt nicht, dass jeder Text in jedem CRM-Feld als Anweisung behandelt werden darf.
Dasselbe gilt für Tool Calls. Ein Agent kann die Berechtigung benötigen, Slack-Nachrichten zu senden. Die Berechtigung beantwortet aber nicht, ob eine Nachricht aufgrund eines extern eingereichten Lead-Datensatzes versendet werden darf.
Für Agenten entsteht deshalb neben klassischem RBAC eine zweite Kontrollfrage: Woher stammt der Kontext, der eine privilegierte Aktion ausgelöst hat?
Eine brauchbare Policy kann eine Aktion nicht allein anhand des ausführenden Agenten bewerten. Sie muss auch berücksichtigen, ob die Entscheidung aus internen Daten, einem externen Formular, einer E-Mail oder einer anderen nicht vertrauenswürdigen Quelle entstanden ist.
Prompt Injection wurde erst durch die Tool-Rechte zum Datenleck
Die manipulierte Eingabe allein hätte keine CRM-Daten exfiltriert. Dafür benötigte der Agent Zugriff auf interne Datensätze und einen Weg, Informationen nach außen zu übertragen.
Das unterscheidet SalesBleed von vielen Prompt-Injection-Demos, bei denen lediglich eine unerwünschte Textantwort erzeugt wird.
Hier trafen drei Ebenen aufeinander: untrusted CRM input, privilegierter Datenzugriff und eine ausführbare externe Aktion. Die Sicherheitskontrolle für externe URLs sollte diese Ebenen voneinander trennen, ließ sich in Zenitys Tests aber umgehen.
Salesforce hat die konkret gemeldeten Schwachstellen geschlossen. Das Architekturproblem bleibt allgemeiner: Ein Agent kann gleichzeitig Datenbankleser, Entscheidungssystem und ausführender Nutzer sein.
Je mehr dieser Rollen ein Agent übernimmt, desto weniger darf die Vertrauensentscheidung allein beim Modell liegen. Datenherkunft, Ziel der Aktion und Nutzerfreigabe müssen außerhalb des Prompts kontrollierbar bleiben.