agents: Dialog-Blindheit gilt auch für op read mit Item-Referenz

Geprüft: op read "op://Employee/<item>/password" zeigt denselben
generischen full-access-Dialog wie op item get. 1Password autorisiert das
Werkzeug, nie den Zugriff — auch wenn dieser vollständig spezifiziert ist.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012aD7fG6BpN1HchyHeNXZb4
This commit is contained in:
mwiegand 2026-08-04 23:54:59 +02:00
parent 38f07179c4
commit c80b9bbd3d
No known key found for this signature in database

View file

@ -156,7 +156,12 @@ technische Unerreichbarkeit**:
Die verbleibende Schwäche ist die **Blindheit des Dialogs**: er sagt „full Die verbleibende Schwäche ist die **Blindheit des Dialogs**: er sagt „full
access to your account", nennt aber nicht das angefragte Item. Beim access to your account", nennt aber nicht das angefragte Item. Beim
Bestätigen ist nicht unterscheidbar, ob ein Agent ein harmloses Bestätigen ist nicht unterscheidbar, ob ein Agent ein harmloses
API-Passwort oder den kundenfähigen SSH-Key liest — und weil legitime API-Passwort oder den kundenfähigen SSH-Key liest. Das ist systematisch,
nicht nur eine Eigenschaft offener Abfragen: auch `op read` mit einer
punktgenauen `op://Employee/<item>/<feld>`-Referenz zeigt denselben
Dialog (geprüft 2026-08-04) — 1Password autorisiert das Werkzeug, nie den
Zugriff, selbst wenn dieser vollständig spezifiziert ist. Gerade die
Secrets in `.env.agents` sind ausschließlich solche Referenzen — und weil legitime
Agent-Starts denselben Dialog erzeugen, trainiert der Alltag reflexhaftes Agent-Starts denselben Dialog erzeugen, trainiert der Alltag reflexhaftes
Bestätigen. Genau das macht der gescopte Service-Account (Schritt 1) Bestätigen. Genau das macht der gescopte Service-Account (Schritt 1)
überflüssig: was nicht anfragbar ist, muss nicht beurteilt werden. überflüssig: was nicht anfragbar ist, muss nicht beurteilt werden.