Was ist ein evidence-carrying multimodal agent?

Ein Agent, der vor riskanten Aktionen nicht nur behauptet, etwas auf dem Bildschirm gesehen zu haben, sondern für jede handlungskritische Bedingung einen typisierten Beleg speichert.

Wann reicht ein Screenshot als Beleg nicht?

Immer dann, wenn daraus eine privilegierte Aktion folgt: senden, kaufen, löschen, umbuchen, Daten extrahieren oder Zugriff gewähren. Dann braucht es DOM-, Accessibility-, OCR-, Dokument- oder API-Belege.

Ist das für jeden Browser-Agenten nötig?

Nein. Für read-only Recherche ist es oft zu schwer. Es lohnt sich bei irreversiblen, externen, privaten oder finanziellen Aktionen.

KI-Agenten brauchen Belege, bevor sie klicken

Multimodale Agenten sollten Screenshots nicht als Erlaubnis behandeln. Die bessere Regel: Jede riskante Aktion braucht einen typisierten Beleg aus DOM, Accessibility Tree, OCR oder API.

Kurz erklärt

Ein Browser-Agent sieht einen Button. Er beschreibt ihn richtig. Dann klickt er.

Das klingt harmlos, bis der Button Geld sendet, eine E-Mail abschickt, ein Konto löscht oder private Daten aus einem Dokument zieht.

Der interessante Shift in “Hallucination as Exploit: Evidence-Carrying Multimodal Agents” ist deshalb nicht: Multimodale Modelle sollen weniger halluzinieren.

Der Shift ist schärfer:

Eine falsche visuelle Behauptung kann zur Autorisierungs-Lücke werden.

Wenn ein Agent sagt “das ist die richtige Rechnung” oder “der Empfänger ist ausgewählt”, ist das noch kein Beleg. Das ist Modelltext. Für riskante Aktionen sollte Modelltext nicht als Erlaubnis zählen.

riskante Klicks nur auf Modell-Prosa

Evidenz-Tabelle vor dem Tool Call

gute Quellen: DOM, AX, OCR, API

Der Fehler: Screenshot-Gefühl als Permission Slip

Viele Computer-Use-Demos laufen ungefähr so:

Screenshot → Modellbeschreibung → Tool Call

Das ist okay, solange der Agent nur liest oder navigiert. Es wird dünn, sobald die Beschreibung eine Vorbedingung für Handlung ist.

Beispiele:

“Der Empfänger ist Max” → E-Mail senden.
“Der Betrag ist 49 €” → Zahlung bestätigen.
“Das ist der richtige Kundenaccount” → Daten exportieren.
“Die Checkbox ist aktiv” → Zustimmung speichern.
“Das Dokument enthält keine sensiblen Daten” → Datei hochladen.

Wenn diese Aussagen nur aus freier Vision-Prosa kommen, hat der Agent keine harte Bremse. Er hat eine plausible Geschichte.

Behauptung vs. Beleg

Schwach

"Ich sehe den richtigen Button."
"Der Betrag wirkt korrekt."
"Die Rechnung gehört zu Kunde X."
"Die Seite ist die Login-Seite."

Besser

Selector + accessible name + sichtbarer Text stimmen.
Parsed field amount === erwarteter Betrag.
Dokumentfeld / API-ID / OCR-Box belegt Kunde X.
Origin, title, form action und bekannte Marker passen.

Der sichere Mini-Harness

Du brauchst dafür nicht sofort ein Forschungsprojekt. Für viele interne Agenten reicht ein kleines Gate vor riskanten Aktionen.

Evidence gate vor Aktionen

erst belegen, dann handeln

01

Aktion
02

Predicates
03

Belegtypen
04

Quellen prüfen
05

Block oder Tool Call
06

Audit-Log

Die Regel:

Keine riskante Aktion, solange eine handlungskritische Bedingung nur durch Modelltext belegt ist.

Handlungskritisch ist alles, was die Aktion erlaubt, begrenzt oder gefährlich macht:

Wer ist Empfänger, Account, Kunde oder Patient?
Welcher Betrag, Vertrag, Tarif oder Zeitraum?
Welche Datei, Tabelle, Nachricht oder Datenquelle?
Ist die Aktion reversibel?
Wurde Zustimmung wirklich gesetzt?

Was als Beleg zählen kann

DOM: Selector, Value, Attribute, Form State, URL, Origin.
Accessibility Tree: Rolle, Name, checked/disabled/expanded State.
OCR: Text plus Bounding Box, wenn kein DOM existiert.
Parsed Document/API: Feldwert, ID, Signatur, Serverantwort.

Steal this: der Predicate-Prompt

Kopier das vor jeden riskanten Tool Call deines Agents:

Bevor du diese Aktion ausführst, erstelle eine Evidence-Tabelle.

Aktion: [Tool Call]
Risiko: read-only | extern | destruktiv | privat | finanziell

Für jede handlungskritische Bedingung:
- Predicate: Was muss wahr sein?
- Required evidence type: DOM | AX | OCR | parsed document | API | user approval
- Observed evidence: konkreter Wert
- Source pointer: selector, bounding box, field path, URL, response id oder approval text
- Status: proven | missing | conflicting

Regel:
Wenn eine Bedingung missing oder nur durch freie Modell-Prosa belegt ist, führe die Aktion nicht aus. Frage nach Bestätigung oder nutze ein sichereres Tool.

Das ist nicht langsam. Es ist ein Sicherheitsgurt.

Für Browser-Agenten

Tun

✓ riskante Actions vorher in Predicates zerlegen
✓ typed evidence neben dem Tool Call loggen
✓ DOM/AX/API gegenüber Screenshot-Prosa bevorzugen
✓ bei fehlendem Beleg blockieren statt raten

Vermeiden

× Screenshot-Beschreibung als Erlaubnis behandeln
× Buttons nur nach visueller Position klicken
× OCR ohne Bounding Box oder Feldkontext vertrauen
× Audit-Logs nur aus Modellzusammenfassungen bauen

Wo es sich lohnt

Für einen Agenten, der Kochrezepte sucht, ist das zu viel.

Für einen Agenten, der Formulare ausfüllt, Rechnungen prüft, Kundendaten bewegt, Buchungen ändert oder Nachrichten sendet, ist es genau die richtige Art langweilige Infrastruktur.

Der Punkt ist nicht, dem Modell zu misstrauen. Der Punkt ist, seine Rolle sauber zu schneiden:

Das Modell darf interpretieren.
Der Harness muss belegen.
Die Aktion darf erst danach passieren.

Das ist huecki-kompatible Agent-Sicherheit: wenig Drama, klare Bremse, besserer Alltag.