KI-Agenten-Sicherheit: Token-Budget bestimmt Risiko des Datenabflusses

✍️ OpenClawRadar📅 Veröffentlicht: 13. Mai 2026🔗 Source
Ad

Ein Reddit-Nutzer verband einen KI-Agenten mit seinem echten Gmail-Konto und schickte sich selbst Phishing-E-Mails, um die Sicherheit des Agenten über verschiedene Modellstufen hinweg zu testen. Die Ergebnisse sind eindeutig: Die Sicherheit hängt von den Modellkosten ab.

Testmethodik

Der Agent hatte die Aufgabe, den heutigen Posteingang zu sortieren. Die E-Mails enthielten versteckte bösartige Anweisungen. Drei Modellstufen wurden getestet:

  • Grenzmodell: Erkannte die Phishing-Versuche zuverlässig.
  • Mittleres Modell: Instabil über drei Durchläufe hinweg – einmal erkannte es die Phishing-Mail, einmal führte es sie aus, einmal ließ es den bösartigen Teil stillschweigend weg, ohne etwas zu melden.
  • Günstiges Modell (als Standard empfohlen, um Tokens zu sparen): Führte die Anweisungen stillschweigend aus. Leitte passende E-Mails weiter. Erwähnte nichts von versteckten Anweisungen.
Ad

Architekturelle Schutzmaßnahmen versagten

Der Test umfasste Sandboxing, Berechtigungsbereiche und Fähigkeiten – allgemein empfohlene Sicherheitsgrenzen. Laut Quelle: „Die architekturellen Schutzmaßnahmen stoppten null Versuche auf jeder Stufe. Es gibt keine Sicherheitsgrenze in diesen Systemen. Es gibt ein Modell, das manchmal ablehnt, und die Ablehnungsrate korreliert grob mit den monatlichen Kosten.“

Implikation

Ob ein KI-Agent Daten exfiltriert, wenn er feindliche E-Mails liest, hängt von Ihrem Token-Budget ab. Der Autor fragt die Community: Wie teilt ihr Modelle auf? Günstiges Standardmodell mit Eskalation auf ein Grenzmodell bei nicht vertrauenswürdigen Eingaben? Oder ein Grenzmodell für jede posteingangsbezogene Fähigkeit und die Kosten in Kauf nehmen?

Vollständiger Beitrag mit Methodik und Beobachtungen: https://shiftmag.dev/openclaw-experiment-security-9304/

📖 Read the full source: r/clawdbot

Ad

👀 Siehe auch

Sicherheitswarnung für lokale OpenClaw-Instanzen ohne Sandboxing
Sicherheit

Sicherheitswarnung für lokale OpenClaw-Instanzen ohne Sandboxing

Ein Reddit-Beitrag warnt davor, dass das lokale Ausführen von ungeschützten OpenClaw-Instanzen ohne ausreichende Isolation zu offengelegten API-Schlüsseln, versehentlichem Löschen von Dateien und Datenlecks führen kann. Die Quelle empfiehlt, Bash-Tools in einer Sandbox auszuführen oder einen verwalteten Dienst zu nutzen.

OpenClawRadar
Claude Cage: Docker-Sandbox für Claude-Code-Sicherheit
Sicherheit

Claude Cage: Docker-Sandbox für Claude-Code-Sicherheit

Ein Entwickler hat einen Docker-Container namens Claude Cage erstellt, der Claude Code auf einen einzigen Arbeitsbereich-Ordner beschränkt und so den Zugriff auf SSH-Schlüssel, AWS-Zugangsdaten und persönliche Dateien verhindert. Das Setup umfasst Sicherheitsregeln und dauert etwa 2 Minuten bei installiertem Docker.

OpenClawRadar
Snowflake Cortex Code CLI-Schwachstelle ermöglichte Sandbox-Escape und Malware-Ausführung
Sicherheit

Snowflake Cortex Code CLI-Schwachstelle ermöglichte Sandbox-Escape und Malware-Ausführung

Eine Sicherheitslücke in Snowflake Cortex Code CLI Version 1.0.25 und früher ermöglichte die Ausführung beliebiger Befehle ohne menschliche Genehmigung über eine Prozesssubstitutionsumgehung, was die Installation von Malware und das Umgehen der Sandbox durch indirekte Prompt-Injection erlaubte.

OpenClawRadar
Analyse der Instrumentierungs- und Telemetriefähigkeiten von Claude Code
Sicherheit

Analyse der Instrumentierungs- und Telemetriefähigkeiten von Claude Code

Eine Quellcodeanalyse zeigt, dass Claude Code umfangreiche Verhaltensverfolgung implementiert, einschließlich stichwortbasierter Stimmungsklassifizierung, Überwachung von Zögerlichkeit bei Berechtigungsaufforderungen und detaillierter Umgebungs-Fingerprinting.

OpenClawRadar