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

agents/README.md

@@ -156,7 +156,12 @@ technische Unerreichbarkeit**:
   Die verbleibende Schwäche ist die **Blindheit des Dialogs**: er sagt „full
   access to your account", nennt aber nicht das angefragte Item. Beim
   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
   Bestätigen. Genau das macht der gescopte Service-Account (Schritt 1)
   überflüssig: was nicht anfragbar ist, muss nicht beurteilt werden.