Da sich die Erkennung von einzelnen Merkmalen auf die gesamte Sitzung verlagert, steigen die Anforderungen an Clients: Umgebungen müssen intern stimmig, voneinander getrennt, zustandskontinuierlich und mit dem Netzwerk-Ausgang abgestimmt sein.
Im vergangenen Jahr sind AI Agents immer tiefer in Geschäftsabläufe vorgedrungen: vom Aufruf von Browser-Tools über die Anmeldung in Backoffice-Systemen bis zur Auftragsbearbeitung und dem Beantworten von E-Mails. Gleichzeitig ändern Risikokontrollsysteme ihre Bewertungsmethode. Statt nur ein einzelnes Browsermerkmal zu beobachten, betrachten sie zunehmend die gesamte Sitzung.
Die Erkennung verlagert sich von Einzelmerkmalen auf die gesamte Sitzung
Wenn Plattformen ihre Fähigkeiten zur AI-Erkennung beschreiben, nennen sie Verhaltenssignale über die gesamte Sitzung hinweg: ob Zeigerbewegungen zu regelmäßig sind, ob Tippgeschwindigkeit und Rhythmus auffällig wirken, ob Eingaben fortgesetzt werden, obwohl die Seite keinen Fokus hat, ob bei unsichtbarer Seite noch Zeigeraktivität stattfindet und ob der Ablauf von Anfang bis Ende konsistent bleibt.
Diese Signale haben eines gemeinsam: Sie hängen nicht davon ab, ob ein einzelner Parameter echt oder falsch ist. Entscheidend ist die Kontinuität über einen Zeitraum. Manipulationen an nur einem Merkmal bringen gegen diese Art der Bewertung daher wenig.
Außerhalb der Sitzung gibt es eine weitere Korrelationsschicht
Neben Verhaltenssignalen können umfassendere Risikokontrollen Browserumgebung, Cookies, Anmeldestatus, Netzwerkumgebung und Kontohistorie gemeinsam betrachten: Bleibt die Umgebung konsistent? Sind Cookies, lokaler Speicher und Anmeldestatus kontinuierlich? Ändert sich die Umgebung zu häufig? Gibt es ungewöhnliche Sprünge im Netzwerk? Nutzen mehrere Konten dieselbe Browserumgebung? Entspricht das Verhalten einem normalen Geschäftsablauf?
Diese Prüfungen lassen sich in zwei Ebenen einteilen. Die erste ist die Browser-Laufzeitumgebung; sie bestimmt, ob Umgebung und Anmeldestatus kontinuierlich bleiben können. Die zweite ist die Ausführungsstrategie des Agents; sie beeinflusst, ob der gesamte Ablauf automatisiert wirkt. Wenn eine der beiden Ebenen Probleme hat, wird ein stabiler Betrieb schwierig.
Warum inkonsistente Umgebungen als Automatisierung gewertet werden können
Der umgekehrte Blick macht es klarer. Ein echter Nutzer, der mit einem Gerät eine Website besucht, hinterlässt viele zueinander passende Hinweise: Liegt die Ausgangs-IP in einer bestimmten Region, sollte die Systemzeitzone normalerweise dazu passen; die übliche Sprache sollte sinnvoll zur IP-Region passen; Bildschirmauflösung, Schriftartenliste und GPU-Informationen sollten miteinander vereinbar sein; Cookies und Anmeldestatus sollten sich über die Zeit allmählich verändern, statt bei jedem Besuch bei null zu beginnen.
Inkonsistenz ist selbst eine Auffälligkeit. Ein Ausgang in Frankfurt, während die Browser-Zeitzone auf Los Angeles steht; in dieser Stunde eine Schrift- und Auflösungskombination, in der nächsten eine andere; fünf Konten, die innerhalb von zehn Minuten in derselben Umgebung angemeldet werden. Schon einzeln sind solche Fälle verdächtig, zusammen lassen sie sich nur schwer als normales menschliches Verhalten erklären.
Die Logik der Plattform ist nicht kompliziert: Normale Nutzer verhalten sich in der Regel nicht so. Die Kosten für die Aufrechterhaltung der Konsistenz liegen daher beim Client.
Vier Bereiche, auf die Clients sich vorbereiten können
Erstens: interne Stimmigkeit der Umgebung. Zeitzone, Sprache, Auflösung, Schriftarten, GPU und ähnliche Parameter dürfen sich nicht widersprechen.
Zweitens: Unabhängigkeit zwischen Umgebungen. Jede Aufgabe sollte ein eigenes Datenverzeichnis, eigene Parameter und einen eigenen Netzwerk-Ausgang besitzen, damit mehrere Identitäten nicht derselben Geräteumgebung zugeordnet werden.
Drittens: Kontinuität des Zustands. Cookies, lokaler Speicher und Anmeldestatus sollten pro Umgebung getrennt gespeichert und nach einem Neustart wiederhergestellt werden, statt jedes Mal neu anzumelden.
Viertens: Abstimmung von Ausgang und Geoparametern. Wechselt der Ausgang in ein anderes Land, sollten Zeitzone und Sprache der Umgebung entsprechend mitwechseln, damit kein langfristiger Widerspruch entsteht.
Die ersten beiden Punkte gehören hauptsächlich zur Umgebungsebene. Die letzten beiden liegen teils in der Umgebungsebene, teils in der Scheduling-Logik. Wenn ein Team gleichzeitig Dutzende Agents ausführt, landen solche Anforderungen meist im Umgebungsmanagement, wo isolierte Umgebungen, getrennte Ausgänge und Massenkonfiguration gemeinsam verwaltet werden. PurpleMark ist eines der Werkzeuge, die diese Ebene bereitstellen.
Mehrere ältere Ansätze funktionieren zunehmend schlechter
Nur den User-Agent zu ändern ist weit verbreitet. Bleiben die zugrunde liegenden Merkmale jedoch unverändert, fällt der Widerspruch zwischen UA und tatsächlicher Umgebung erst recht auf. Nur die IP zu wechseln hat dasselbe Problem: Gerätemerkmale und Verhaltensrhythmus bleiben gleich, daher löst ein anderer Ausgang das Problem nicht. Der Inkognito-Modus betrifft den lokalen Speicher, nicht die Gerätemerkmale.
Mehrere Aufgaben in dieselbe Umgebung zu packen ist ebenfalls ungünstig. Bei paralleler Ausführung können sie Cookies und Anmeldestatus gegenseitig überschreiben, und mehrere Identitäten aus derselben Umgebung sind bereits ein Korrelationshinweis. Auch ein einheitlich auf einen festen Wert verlängerter Wartezeitraum erzeugt ein regelmäßiges Muster, das selbst erkannt werden kann.
Bewertungskriterien
Statt sich daran festzubeißen, ob einzelne Merkmale tief genug verborgen sind, ist eine andere Frage sinnvoller: Ist die Umgebung intern plausibel, sind die Umgebungen voneinander unabhängig und entspricht der Verhaltensrhythmus einem normalen menschlichen Ablauf? Erst wenn alle drei Punkte stimmen, ist ein stabiler Betrieb realistisch.
Grenzen
Eine Erkennung zu passieren bedeutet nicht, dass eine Nutzung erlaubt ist. Halten Sie die Nutzungsbedingungen und robots-Regeln der Zielplattform ein, verwenden Sie keine falschen Identitätsangaben, umgehen Sie keine technischen Schutzmaßnahmen, begrenzen Sie die Anfragefrequenz und beeinträchtigen Sie den normalen Betrieb des fremden Dienstes nicht.
