Dev.to Security 🔐 Cybersecurity 👁 0 📖 1 min read

Ein Agent, der eine E-Mail ohne Rückfrage verschickt, ist kein Feature – er ist

Ein Agent, der eine E-Mail ohne Rückfrage verschickt, ist kein Feature – er ist ein Bug mit Absender. Der Unterschied zwischen sympathisch und gruselig liegt selten im Modell, sondern im Datenmodell. Wer E-Mail, Kalende

Ein Agent, der eine E-Mail ohne Rückfrage verschickt, ist kein Feature – er ist ein Bug mit Absender.

Der Unterschied zwischen sympathisch und gruselig liegt selten im Modell, sondern im Datenmodell. Wer E-Mail, Kalender und Aufgaben verbindet, sollte zwei getrennte Zustände bauen: Vorschlag und Ausführung.

Was dabei konkret zählt:

  • Jeder Vorschlag ist ein eigenes Objekt: Typ (Antwort, Termin, Aufgabe), betroffene Ressource, Diff zum Original, auslösende Nachricht. Ohne Diff kann niemand prüfen, was er freigibt.
  • Lese- und Schreibrechte strikt trennen. Erst read-only (IMAP lesen, CalDAV lesen), Schreib-Scopes wie senden oder Termin anlegen erst beim Commit.
  • Freigabe ist ein Commit mit Idempotency-Key, damit ein Doppelklick nicht zwei Antworten rausschickt.
  • Vorschläge verfallen. Ein Entwurf auf eine drei Wochen alte Mail ist peinlicher als kein Entwurf – also Tabelle mit TTL statt unendlicher Queue.
  • Jede Freigabe landet im Log: wer, wann, was, auf Basis welcher Daten. Nicht fürs Dashboard, sondern für den ersten Bugreport.

Das ist unspektakulär, und genau deshalb trägt es. Der Nutzer behält die Kontrolle, das System bleibt debugbar, und niemand muss erklären, warum der Bot gestern Kollegin Müller geschrieben hat.

Welche Aktion in deinem Setup darf niemals ohne Rückfrage rausgehen – und woran erkennst du sie im Code?

architecture #humanintheloop #productivity

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.