Agent Blast Radius — die Daten, die ein Agentforce-Agent wirklich erreichen kann
Ein statischer Zero-Credit-Analyzer, der die echte Datenzugriffsfläche eines Agenten auf der Ebene der Ausführungssemantik berechnet — apiVersion-Defaults, USER_MODE-Klauseln, Sharing-Deklarationen, Flow-Run-Modes —, sie gegen die eigenen Berechtigungen des laufenden Benutzers difft und die Lücke mit den GDPR-Labels der Org schneidet. Die Kopfzahl: der Escalation Gap.
- Jahr
- 2026
- Rolle
- Salesforce Developer — Agent Security Research
- Technologien
- Agentforce (authority analysis)Python (static analyzer)Apex execution semanticsUSER_MODE / apiVersion precedenceFlow runInMode analysisPermission & FLS resolutionGDPR / ComplianceGroup intersectionDeterministic HTML + Markdown reports47 unit tests
Eckdaten
- Die Frage, die kein Tooling beantwortet: nicht was ein Agent darf (Config-Ebene — AppOmni, Zenity, Security Center auditieren genau das), sondern was sein Code wirklich erreichen kann — denn auf Salesforce entscheidet der Ausführungsmodus, nicht der laufende Benutzer
- Die Kopfzahl ist der Escalation Gap: die Felder, die der Code des Agenten über seinen eigenen laufenden Benutzer hinaus erreicht — geschnitten mit den GDPR/PII-ComplianceGroup-Labels der Org
- Das Vorrang-Gesetz (explizite Klausel → apiVersion-Default → Sharing-Deklaration) wurde von Hand in einer Live-Org bewiesen, bevor es programmiert wurde: sechs Experimente, drei verbreitete Annahmen widerlegt — ein versionsblinder Scanner schlägt bei modernem Code falschen Alarm
- Gegen den Live-Agenten HealthRecord Assistant gelaufen: einen System-Mode-Read auf einem Private-Objekt (PS501) und ein GDPR-gelabeltes Diagnose-Feld gefangen, das am FLS des Benutzers vorbei das Modell erreicht (PS506) — für null Flex Credits
- Ehrliche Unbekannte sind Findings, kein Schweigen: dynamisches SOQL und opake Managed Actions werden markiert (PS504/PS507), nie als sauber geraten
- Deterministische, fingerprint-gebundene Reports (Markdown + ein dunkles HTML-Dashboard) — neu generiert bei jeder Änderung an Config, Apex, Flow oder Permissions; läuft bei jedem Commit
- 47 Unit-Tests über Resolver, Introspektoren, Analyzer und Report — grün verifiziert
- Ehrliche Einordnung: Design-Time-Analyse, die den möglichen Blast Radius begrenzt; sie ergänzt Runtime-Monitoring, und Record-Level-Leckage wird als Haltung berichtet, nicht als exakte Zahl. Zurückgestellt: DML-Operationen, Selector-Ketten, Trigger-Kaskaden
Funktionen im Detail
Der Live-Report — ein GDPR-Feld jenseits des Benutzers
Das Dashboard für den deployten HealthRecord-Assistant-Agenten: der Zwei-Kreise-Escalation-Gap (der Code des Agenten erreicht ein Feld, das sein laufender Benutzer nicht sehen kann — und es ist GDPR-gelabelt), die Reichweiten-Zusammenfassung und die Findings mit konkreten Fixes: eine Pre-v67-Klasse, die ein Private-Objekt im System-Mode liest (PS501), und das Diagnose-Feld — ComplianceGroup PII;GDPR;HIPAA — das am FLS des Benutzers vorbei ans Modell geht (PS506). Erzeugt durch statische Analyse: kein Agent aufgerufen, null Flex Credits, gebunden an den Fingerprint der Config.
Das Problem
Salesforce sagt: Gib Agenten Least Privilege — und eine ganze Produktkategorie (AISPM) auditiert Agenten-Berechtigungen, auf der Konfigurationsebene: was der Agent darf. Nichts davon liest, was der Code des Agenten wirklich tun kann. Auf Salesforce unterscheiden sich die beiden tatsächlich, denn der Ausführungsmodus — nicht der laufende Benutzer — entscheidet, ob eine Action diesen Benutzer respektiert: das Apex einer Action kann vor API v67 stammen und standardmäßig im System-Mode laufen; eine WITH-USER_MODE-Klausel überschreibt eine without-sharing-Deklaration; der runInMode eines Flows kann still System-Kontext gewähren; ein sauberes User-Mode-DML kann einen Legacy-Trigger feuern, der trotzdem eskaliert. Und ein naiver Scanner, der 'without sharing' markiert, ohne diesen Vorrang zu verstehen, produziert False Positives, die seine eigene Glaubwürdigkeit zerstören.
Der Ansatz
Erst die Physik beweisen, dann das Instrument bauen. Sechs von Hand ausgeführte Experimente in einer Live-Org (null Credits, in sich geschlossene Fixtures) etablierten das Vorrang-Gesetz — explizite Klausel schlägt apiVersion-Default schlägt Sharing-Deklaration — und widerlegten dabei drei verbreitete Annahmen: eine fehlende Sharing-Deklaration ist nicht 'without sharing'; der User-Mode-Default von v67 überschreibt für einfache Operationen selbst ein explizites without sharing; und der DML-Modus eines Triggers folgt der API-Version des Triggers, nicht der Access-Level der Action. Erst dann die Pipeline: ein Apex-Introspektor, der den Ausführungsmodus pro Operation auflöst, ein Flow-Introspektor, der runInMode deklarativ liest, ein Permission-Resolver für das effektive CRUD/FLS des laufenden Benutzers (inklusive der View-All-Records-aber-nicht-FLS-Nuance) und ein Authority-Analyzer, der alles zu PS5xx-Findings verbindet — mit den ComplianceGroup-Labels der Org, die markieren, welche entkommenen Felder GDPR/PII sind. Reports sind deterministisch und fingerprint-gebunden; unbestimmte Reichweite wird als ehrliches Unbekannt gemeldet, nie als stilles Bestanden. 47 Unit-Tests decken die Kette ab.
Das Ergebnis
Gegen den Live-Agenten HealthRecord Assistant gelaufen, rechtfertigt der Report das ganze Tool in einer Zeile: Escalation Gap — 1 Feld, 1 GDPR-gelabelt. Eine Pre-v67-Action-Klasse liest ein Private-Objekt im System-Mode (PS501), und das Diagnose-Feld — ComplianceGroup PII;GDPR;HIPAA — erreicht das Modell, obwohl der laufende Benutzer keinen Feldzugriff darauf hat (PS506). Standard-Managed-Actions werden ehrlich als nicht statisch analysierbar ausgewiesen statt als sicher angenommen, und die Legacy-API-Klasse ist zur Migration markiert. Alles statisch, bei jedem Commit, für null Flex Credits. Ehrlich eingeordnet: Das ist Design-Time-Begrenzung des möglichen Blast Radius — sie ergänzt Runtime-Monitoring, statt es zu ersetzen, und DML-Operationen, Selector-Ketten und Trigger-Kaskaden sind als nächste Schritte dokumentiert, nicht behauptet.