Show HN: Continue? Y/N: Ein 60-Sekunden-Spiel über die Erschöpfung durch AI-Agent-Berechtigungen

 (llmgame.scalex.dev)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Continue? Y/N ist ein Experiment, das die Erschöpfung durch LLM-Berechtigungen in ein 60-Sekunden-Spiel verwandelt und testet, wie sorgfältig man AI-Anweisungen liest
  • Bis zum nächsten Meeting bleibt nur noch 1 Minute, und Claude Code bittet um Genehmigung von Befehlen, um das Refactoring abzuschließen
  • Nutzer müssen innerhalb des Zeitlimits so viele Anfragen wie möglich bearbeiten und jeden Befehl lesen, dann mit 1 genehmigen oder mit 2 ablehnen
  • Die Kernaufgabe besteht darin, trotz des ermüdenden Stroms wiederholter Genehmigungsanfragen, bei dem einem fast die Augen zufallen, konzentriert zu bleiben
  • Die Regel lautet, innerhalb von 60 Sekunden so viele wie möglich zu bearbeiten, dabei aber jeden Befehl sorgfältig zu lesen und über Genehmigung oder Ablehnung zu entscheiden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • Wirklich lustig

    Im Moment kann man noch "cheaten", indem man einfach alle Anfragen so schnell wie möglich ablehnt. Dann bekommt man das security-conscious engineer-Abzeichen und erreicht auch bei der Anzahl bearbeiteter Anfragen die volle Punktzahl. Die "overblock"-Warnung erscheint zwar, ist aber unten versteckt, und der Bildschirm sieht trotzdem so aus, als hätte man gewonnen

    Ich habe auch versucht, so viele Anfragen wie möglich schnell zu genehmigen, wie ein Engineer im hustle4lyfe-Stil, der "schnell handelt und Dinge kaputtmacht", aber wegen der malicious command-Popups wurde ich am Ende sogar langsamer. Gemein

    • Gut entdeckt, das wurde inzwischen generft und hat jetzt auch einen eigenen Titel
    • Genau wie in der Realität. Wenn man einfach alles ablehnt, sodass nichts mehr funktioniert, ist es sicher :)

  • Lustiges Spiel, aber es hat auch die mangelnde Security-Hygiene der Ersteller gezeigt. Es sagte, cat ~/.zshrc sei riskant, weil dabei Tokens und Secrets geteilt würden, aber ich würde niemals Secrets in eine Shell-Konfigurationsdatei packen

    • Viele Leute machen das. Diese Werte würden dann allerdings in Umgebungsvariablen liegen, und wahrscheinlich könnte Claude sowieso schon darauf zugreifen
    • Ich selbst mache das nicht, aber ich kann mir schon vorstellen, dass viele Leute das tun
    • Secrets in ein LLM zu geben ist an sich nicht grundsätzlich unsicher, es ist nur einer der drei fatalen Faktoren
    • Schon überhaupt Tokens und Secrets zu haben, ist mangelnde Security-Hygiene
    • Und wo würdest du sie dann aufbewahren?

  • Es ist seltsam, das Lesen von zshrc als riskant einzustufen. Ich würde meine dotfiles-Repository bereitwillig öffentlich machen; wer packt denn bitte API-Keys dort hinein? Umgekehrt scheint es, als würden solche AI-Tools dort ständig PATH ergänzen, also gibt es in der AI-Branche insgesamt wohl ein grundlegendes Missverständnis über gute Shell-Praktiken

    Außerdem ist es nicht sicher, die Ergebnisse von lsof einfach mit kill zu beenden. Wenn zum Beispiel Firefox gerade eine Webseite geöffnet hat oder der Agent selbst eine Client-Subshell enthält, dann schießt man damit Firefox und den Agenten ab

    • Stimmt. Das Spiel scheint anzunehmen, dass kill sicher auszuführen ist, weil Claude gesagt hat, es sei sicher. Aber genau darum geht es ja: Man sollte Claude nicht vertrauen

  • Hat mir gefallen. Ich habe nur eine kleine nitpick

    npm config set registry [https://npm.internal](<https://npm.internal>;)

    Es hieß, das sei ein Befehl, um npm auf den internen Registry-Mirror des Unternehmens umzuleiten, weil die Onboarding-Dokumentation das verlange, und das Spiel stufte das als sicher ein. Ich war auch hin- und hergerissen und habe es am Ende abgelehnt

    Wenn diese README für ein öffentliches Repository oder einen geforkten Klon gedacht ist und dieses https://npm.internal in Wirklichkeit https://npm.internal.somethinganexternaldnscanresolve.tld ist, dann kann das sehr schnell schiefgehen

    In 99 % der Fälle wird per Unternehmensrichtlinie ohnehin bereits ein Mirror wie Artifactory / Nexus eingerichtet sein. Wenn eine README verlangt, eine andere Paketmanager-URL zu verwenden, ist das ein massives Warnsignal, und dann ist es nur noch Sekunden bis zum Incident

    • Guter Punkt. .internal ist eine reservierte Top-Level-Domain und sollte nicht öffentlich auflösbar sein, aber du hast recht, dass man vorsichtig sein sollte, wenn man Claude ein Projekt refaktorieren lässt und dabei Werte geändert werden, die separat konfiguriert sein sollten. Ich werde das eher in Richtung dauerhafte Änderung verschieben

  • Ein nettes kleines Spiel, aber ich finde, die Fragen springen zu stark über den Kontext hinweg und bilden reale Situationen deshalb nicht besonders gut ab. Es wäre besser, sie in "Packs" zu bündeln, damit die Struktur realistischer wirkt

    Zum Beispiel wäre es viel natürlicher und gefährlicher, wenn viele Berechtigungsanfragen zum Bearbeiten einer Datei wie something.js kämen und dann plötzlich npm publish auftaucht. Wenn man gerade ständig Y gedrückt hat, tappt man viel leichter hinein

  • Ungefähr drei Viertel der "schlechten" Optionen wären Dinge, bei deren Leak es mir ziemlich egal wäre, und selbst wenn sie zu einem Produktionsvorfall führen würden, würde mein Arbeitgeber mich dafür vermutlich nicht bestrafen

  • Berechtigungsabfragen zerstören die Produktivität massiv. Wenn man Claude laufen lassen will, ist es meiner Meinung nach effizienter, es in einer wegwerfbaren Sandbox auszuführen oder in einem Docker-Container, der nur die Berechtigungen auf dem persönlichen Rechner hat, mit denen man leben kann

    [1] - https://exe.dev/ ist ein neuer Cloud-Anbieter mit einer ziemlich nützlichen Agent-User-Experience

    [2] - Ich habe https://github.com/stanislavkozlovski/dclaude/ genau für diesen Zweck gebaut. Es ist nicht perfekt, erledigt für mich aber die Arbeit, wenn ich nur gelegentlich lokal einen Coding-Agenten laufen lassen muss

    • Eine wegwerfbare Sandbox verhindert das Leaken von Secrets nicht. Wenn man den Code nicht als geheim betrachtet, kann man natürlich eine Sandbox ganz ohne Secrets bauen, aber dann ist die Art von Arbeit, die der Agent erledigen kann, stark eingeschränkt

  • Ich fände es gut, wenn der Punktebildschirm am Ende auch die Erklärungen des LLM für die Befehle zeigen würde, die man nicht hätte genehmigen dürfen. Ich habe den Befehl rm -rf Projects genehmigt, weil ich dachte, das LLM hätte korrekt erklärt, dass damit alles im Ordner Projects gelöscht wird

    Ich habe beim schnellen Beantworten der Prompts offenbar etwas falsch gelesen, und da ich ja wusste, was der Befehl macht, habe ich vielleicht halluziniert, dass die AI es erklärt hätte. Trotzdem würde ich gern sehen, was ich falsch gelesen habe

    Nachdem ich dieses Spiel gespielt habe, bin ich wirklich froh, dass ich nicht agentmaxxe

  • Ich habe bei ls -la ~/Documents "approve" gewählt und lag damit falsch, aber ich würde das bloße Auflisten des Ordners Documents nicht als Security-Problem ansehen. Das sind nur Dateinamen. Wenn auch noch die Inhalte gelesen würden, dann vielleicht...