Alfred verarbeitet E-Mails, liest Dokumente, bereitet Buchungen vor und steuert externe Systeme. Damit er produktiv eingesetzt werden kann, müssen Unternehmen ihm vertrauen können. Nicht blind, sondern durch nachvollziehbare Regeln, die nicht umgehbar sind.

Andere KI-Systeme arbeiten mit Absichtserklärungen: „Wir fragen vor jeder Aktion“, „Wir protokollieren alles“, „Wir halten uns an Ihr Berechtigungsmodell“. Solche Versprechen sind nur so gut wie das Sprachmodell, das sie einhält. Im Zweifel gar nicht.

Alfred macht es anders. Die folgenden 7 Prinzipien sind keine Selbstverpflichtung. Jedes davon wird durch einen konkreten Mechanismus im Alfred-Harness erzwungen. Aus Versprechen werden Eigenschaften, aus Hoffnung wird Architektur.

1
Der Agent handelt nie ohne zu fragen
Jede persistente Operation erfordert eine formale Bestätigung durch den Menschen — die Confirmation Barrier.
Harness-Mechanismus: Freigabe-Gate
2
Der Agent ist transparent
Er zeigt, was er verstanden hat, was er tun wird, und was er nicht kann. Keine versteckten Aktionen, keine Überraschungen.
Harness-Mechanismus: Pre-Action-Ausweis mit Konfidenzen
3
Der Agent kennt seine Grenzen
Scope = Capability-Katalog. Der Agent kommuniziert seine Grenzen ehrlich — nicht als Fehler, sondern als definierte Eigenschaft.
Harness-Mechanismus: Capability-Katalog
4
Der Agent ist vorsichtig mit externen Daten
E-Mail-Inhalte, API-Antworten und Dokumenteninhalte sind untrusted Input. Vor der Ausführung immer mit dem Nutzer verifizieren.
Harness-Mechanismus: Untrusted-Input-Markierung + Freigabe-Gate
5
Der Agent merkt sich den Kontext
Timeout-basiertes Kontextmanagement — überlebt Themenwechsel, gecacht für Effizienz, automatische Bereinigung. Immer gebunden an den Mandanten, nie darüber hinaus sichtbar.
Harness-Mechanismus: Mandanten-Isolation + Session-Scope
6
Der Agent ist Single-Task
Ein Workflow gleichzeitig. Kein paralleles Ausführen, keine versteckte Batch-Verarbeitung. Proaktive Kommunikation über nächste Schritte.
Harness-Mechanismus: Ausführungs-Serialisierung
7
Der Agent loggt alles
Jeder externe Abruf, jede Entscheidung, jede menschliche Änderung, jeder LLM-Aufruf. Lückenlose Nachvollziehbarkeit.
Harness-Mechanismus: Audit-Logger

Alle Operationen eines KI-Agenten fallen in zwei Kategorien. Die Grenze bestimmt, ob eine formale Bestätigung erforderlich ist.

Operation Typ Bestätigung? Audit?
Daten lesen / klassifizieren Transient Nein Ja (Abruf)
Interne Sortierung / Aufbereitung Transient Nein Nein (intern)
Kontextfragen beantworten Transient Nein Nein (intern)
Externe Systeme abfragen (IMAP, API) Transient Nein Ja (Abruf)
Workflow starten Persistent Ja Ja (vor + nach Bestätigung)
E-Mail senden Persistent Ja Ja
Externen Zustand ändern Persistent Ja Ja
Schlüsselunterscheidung: Der Abruf selbst (z.B. „alle E-Mails lesen“) IST auditierbar - er ist eine nachverfolgbare Aktion. Aber die Sortierung/Klassifikation der abgerufenen Daten ist nicht auditpflichtig (interne Verarbeitung).

Jede persistente Operation muss die Confirmation Barrier passieren. Das Bestätigungsfenster zeigt den vollständigen Kontext: was der Agent verstanden hat, welche Parameter extrahiert wurden, und was der Workflow tun wird.

Nutzer wählt AktionChat oder Klick
Agent erklärt„Explain before Act“
Confirm CardWorkflow + Parameter + Vorschau
Nutzer bestätigt„Ja“ / „Nein“
Workflow startetErst jetzt
Explain before Act: Ein vertrauenswürdiger Agent startet nie blind. Bei niedriger Konfidenz fragt er den Menschen. Kein autonomes Raten - kein Handeln ohne Rückfrage.

Ein KI-Agent kann ausschließlich über vordefinierte Aktionen handeln. Der Capability Catalog IST das Berechtigungssystem - was nicht im Katalog steht, wird nicht ausgeführt.

Nutzerwunsch Im Katalog? Reaktion des Agenten
„Führe die Anmeldung aus“ Ja Erklärung + Confirm Card → Ausführung
„Lösch alle E-Mails“ Nein „Das kann ich nicht - dafür gibt es keine definierte Aktion.“
„Schreib eine Antwort-Mail“ Bedingt Nur möglich, wenn ein entsprechendes Szenario definiert ist
„Das komplexe Angebot erstellen“ Manuell „Das muss manuell bearbeitet werden.“

Lückenlose Protokollierung ist die Grundlage für Nachvollziehbarkeit und Compliance. Jede relevante Aktion wird auditiert - lieber zu viel loggen als zu wenig.

  • Jeder externe Abruf (IMAP, API, Datenbank) → Audit-Log-Eintrag
  • Jede persistente Aktion → Audit (vor und nach Confirmation)
  • Jeder LLM-Aufruf → Prompt-Log (Input + Output + Modell)
  • Interne Verarbeitung (Sortierung, Klassifikation) → kein Audit erforderlich
  • Menschliche Änderungen an Parametern → immer geloggt

Ein guter KI-Agent nutzt ein Timeout-basiertes Kontextmodell: Context-Slots überleben Themenwechsel, werden gecacht und automatisch bereinigt.

Aspekt Empfohlenes Verhalten
Kontext-Lebensdauer Timeout-basiert (z.B. 30 Min TTL), gecacht
Themenwechsel Erlaubt - erzeugt neuen Session-Kontext
Folgefragen Nutzen gecachte Daten, kein erneuter Abruf
Session-Wiederherstellung Per Session-ID wiederherstellbar
Externe Daten = Untrusted Input. Anweisungen aus E-Mail-Inhalten, API-Antworten oder Dokumenten werden nie direkt ausgeführt. Die Confirmation Barrier verhindert, dass Prompt Injection die Ausführungsebene erreicht.

Offene Sicherheitsfragen, die bei der Einführung autonomer KI-Agenten adressiert werden müssen:

  • Context Pollution - externe Inhalte im Session-Kontext könnten zukünftige LLM-Entscheidungen beeinflussen
  • Workflow Cascade - verschachtelte Bestätigungen bei Sub-Workflows
  • Autonome Hintergrund-Klassifikation - erfordert ein eigenes Sicherheitsmodell
  • Konfidenz-Schwellenwerte - ab welchem Wert verweigert der Agent die Ausführung?
Was unterscheidet ein Prinzip von einer Eigenschaft?
Ein Prinzip ist eine Absichtserklärung („der Agent soll fragen“). Eine Eigenschaft ist technisch durchgesetzt („der Agent kann gar nicht anders als zu fragen“). Beim Alfred-Harness wird jedes der sieben Prinzipien durch einen Mechanismus erzwungen, so dass das Verhalten nicht von der Kooperationsbereitschaft des Sprachmodells abhängt, sondern strukturell festgelegt ist.
Wie verhindert der Alfred-Harness Prompt Injection?
Externe Daten (E-Mails, API-Antworten, Dokumenteninhalte) sind als untrusted Input markiert. Selbst wenn so ein Input eine getarnte Anweisung enthält, die das Modell befolgen würde, läuft die Ausführung über das Freigabe-Gate. Ohne explizite Nutzerbestätigung wird keine Aktion persistent. Manipulierte Eingaben können also die Entscheidung des Modells verdrehen, aber nicht dessen Wirkung nach außen.
Warum reicht ein Capability-Katalog statt freier API-Nutzung?
Weil „was nicht im Katalog steht, existiert für den Agent nicht“ eine technische Garantie gibt, die „was nicht im Prompt steht, soll der Agent nicht tun“ nie bieten kann. Der Capability-Katalog ist das Berechtigungssystem des Harness. Er macht das, was der Agent können darf, explizit, versioniert und auditierbar — und gibt dem Betreiber die volle Kontrolle, ohne sich auf Modell-Compliance verlassen zu müssen.