From c80b9bbd3d37202e3b4788475230a63852520841 Mon Sep 17 00:00:00 2001 From: mwiegand Date: Tue, 4 Aug 2026 23:54:59 +0200 Subject: [PATCH] =?UTF-8?q?agents:=20Dialog-Blindheit=20gilt=20auch=20f?= =?UTF-8?q?=C3=BCr=20op=20read=20mit=20Item-Referenz?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Geprüft: op read "op://Employee//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) Claude-Session: https://claude.ai/code/session_012aD7fG6BpN1HchyHeNXZb4 --- agents/README.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/agents/README.md b/agents/README.md index e41c603..a0b8b47 100644 --- a/agents/README.md +++ b/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//`-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.