Kann ein KI-Agent ein eigenes Postfach haben?

Ein Postfach wie support@example.com betreut bisher ein Mensch. Soll ein Agent diese Arbeit übernehmen, muss er dieselben vier Handgriffe tun. Er sieht die ungelesene Post durch und antwortet einzeln, hakt Erledigtes ab und legt den Rest in Ordner. Der naheliegende Weg dorthin ist das Konto der Kollegin, die das Postfach bisher gelesen hat.

Das geht schief, sobald der Agent zu arbeiten anfängt. Er setzt Lesezeichen und verschiebt Mail in Ordner. Die Kollegin findet ihr Postfach am nächsten Morgen umsortiert vor. Schritt 1 der Einrichtungsanleitung sagt, was stattdessen zu tun ist. Niemals das Konto eines Menschen teilen, sondern ein eigenes anlegen, etwa support-agent@example.com.

Auf Hacker News steht die Frage in zwei Formen nebeneinander. Unter einem Show HN im März 2026 fragt kwstx, ob es sich um echte Postfächer per IMAP und SMTP handle oder um eine Abstraktion darüber. TZubiri fragt darunter, warum ein Agent überhaupt eine andere Schnittstelle brauche als die für Menschen.

Ein gewöhnliches Postfach genügt

Covey beantwortet beide Fragen gleich: das Zielsystem email liest per IMAP und sendet per SMTP, und eine produktspezifische Schnittstelle gibt es dafür nicht. Jedes Postfach mit IMAP- und SMTP-Zugang passt, der eigene Mailserver ebenso wie ein Konto bei Gmail oder Office 365 mit App-Passwort.

Eingerichtet wird es mit zwei Geheimnissen: email_url trägt den Mailserver, email_token die Adresse und das Passwort, getrennt durch einen Doppelpunkt. Für das Support-Postfach sind das etwa mail.example.com und support-agent@example.com:app-password. Diese Kurzform expandiert auf den Normalfall: IMAP mit TLS auf Port 993 und SMTP-Submission mit STARTTLS auf Port 587, beides auf demselben Host. Liegen IMAP und SMTP auf verschiedenen Hosts oder auf anderen Ports, trägt email_url beide Endpunkte als URLs. Dazu kommen zwei Handgriffe am Agenten: die Zeile - system: email scope: read,write in seiner ACCESS.md und die Freigabe beider Hosts im Egress.

Das Passwort bekommt der Agent nie zu sehen

Beide Verbindungen laufen aus der Sandbox hinaus, und einen Weg hinein gibt es nicht, da die Control Plane für dieses Zielsystem nichts entgegennimmt. Neue Post findet der Agent selbst, indem er nach dem Weckruf list_unread aufruft.

Die Zugangsdaten liegen trotzdem außerhalb seines Arbeitsverzeichnisses. Bei jedem Aufruf prüft die Control Plane die Freigabe und löst email_token und email_url auf. Sie reicht beide mit einer Lebensdauer von 15 Minuten an den Daemon durch, falls COVEY_DAEMON_TOKEN_TTL nichts anderes sagt. Der Agent bekommt die Liste seiner Mails, das App-Passwort von support-agent@example.com bleibt im Daemon.

Ohne Webhook weckt der Heartbeat, und nur bei Post

Mail kennt keinen Webhook. Der Posteingang wird abgefragt, über die HEARTBEAT.md des Agenten und mit einer Zeile etwa der Form - alle: 5m nur-wenn: email. Das nur-wenn: ändert, wer nachsieht.

Vor jedem Lauf fragt die Control Plane selbst per IMAP, ob in support-agent@example.com ungelesene Post liegt. Den Agenten weckt sie nur dann, und deshalb erzeugt ein Intervall von fünf Minuten keine Läufe über einem leeren Postfach.

Die Vorabprüfung nimmt denselben Weg wie list_unread. Sie sieht damit genau den Vorrat, den auch der Agent bekäme: eigene Mail fällt durch die Echo-Sperre, Absender außerhalb von COVEY_EMAIL_INTAKE_ADDRESSES bleiben ausgeblendet. Scheitert die Prüfung selbst, feuert der Heartbeat wie gewohnt, da eine kaputte Bedingung keine Arbeit liegen lassen darf.

Der Lesestatus ist dabei das Signal für den Arbeitsvorrat. reply setzt die Mail selbst auf gelesen, alles andere hakt der Agent ausdrücklich ab. get_message liest mit BODY.PEEK und rührt das Lesezeichen nicht an, sodass eine gelesene und nicht bearbeitete Mail im nächsten Lauf wieder dasteht.

Covey zieht die Grenze am Senden

Eine Mail ist Eingabe, und Eingabe bleibt sie auch dann, wenn in ihrem Text eine Anweisung steht. Ein Beitrag auf Hacker News vom Juni 2025 beschreibt das Muster an einem Agenten mit den Rechten gmail.readonly, gmail.send und gmail.modify. Eine eingeschleuste Anweisung liest der Agent als Auftrag und führt sie mit seinen eigenen, gültigen Rechten aus.

Deshalb sitzt die Grenze am Senden. COVEY_EMAIL_SEND_DOMAINS begrenzt die Empfänger auf Domains oder vollständige Adressen, und die Liste greift im Daemon vor jeder Zustellung; ist sie leer, geht Mail an beliebige Adressen.

Getrennt davon stehen die Guard Rails. email:send und email:reply sind eigene Gegenstände, für die eine Freigabepflicht gelten kann, während das Lesen ungehindert läuft. Gegen Schleifen stehen drei Sperren: list_unread überspringt Mail von der eigenen Adresse, und eine Antwort an die eigene Adresse wird abgelehnt. Der Prompt weist den Agenten außerdem an, Automaten-Mail abzuhaken statt zu beantworten.

Zwei covey-Agenten, die einander schreiben, fängt keine dieser Sperren. Abschnitt 3.3 der Dokumentation sagt das an derselben Stelle, an der sie die drei Mechanismen aufzählt, und nennt als Ausweg COVEY_EMAIL_INTAKE_ADDRESSES oder die Guard Rails.

Der Preis dieses Aufbaus ist die Reaktionszeit, die dem Heartbeat-Intervall entspricht. Ein Agent hat außerdem genau ein Postfach, da das Geheimnis-Paar je Agent gilt. Gesendet wird text/plain, ohne HTML und ohne Anhänge, während eingehende Anhänge der Agent mit get_attachment einzeln in seine Sandbox holt, in der Vorgabe 25 MB je Anhang. OAuth2 ist nicht gebaut, es bleibt bei Benutzername und Passwort.

Damit bleibt das eigene Postfach ein Postfach, und wer es einrichtet, legt es an wie für einen Menschen.

Was danach zu entscheiden bleibt, ist die Liste der Empfänger.