Abbildung: KI-generierte Visualisierung der beschriebenen Systemarchitektur.
Vom Chatbot zum persönlichen KI-Assistenten – Hermes verbindet GMX, Google Calendar und Blinko
Künstliche Intelligenz wird häufig noch immer als eine Art intelligente Suchmaschine oder Textgenerator betrachtet. Man stellt eine Frage, erhält eine Antwort und beginnt bei der nächsten Anfrage wieder von vorn. Interessant wird es jedoch, wenn ein KI-System nicht nur auf sein allgemeines Trainingswissen zurückgreifen kann, sondern auch auf Informationen aus dem eigenen digitalen Alltag.
E-Mails enthalten wichtige Nachrichten, Kalender verwalten Termine und persönliche Wissenssysteme speichern Informationen, die man später wieder benötigt. Diese Daten liegen normalerweise in voneinander getrennten Anwendungen. Ein direkter Zusammenhang besteht häufig nicht.
In meinem CloudLab habe ich deshalb den Hermes Agent mit drei unterschiedlichen Informationsquellen verbunden: einem GMX-Postfach, Google Calendar und der selbst gehosteten Notizverwaltung Blinko.
Das Ziel war nicht, möglichst viele Schnittstellen an einen KI-Agenten anzuschließen. Vielmehr wollte ich untersuchen, wie sich ein persönlicher Assistent aufbauen lässt, der verschiedene Informationsquellen nutzen kann, ohne dabei grundlegende Sicherheitsanforderungen außer Acht zu lassen.
Die eigentliche Herausforderung lag weniger in der Verbindung der einzelnen Systeme als in der Frage, welche Berechtigungen ein KI-Agent erhalten sollte und wie sich diese kontrollieren lassen.
Was ist Hermes Agent?
Hermes Agent ist ein quelloffenes KI-Agentensystem, das von Nous Research entwickelt wird.
Im Gegensatz zu einer klassischen Chatoberfläche beschränkt sich Hermes nicht darauf, Eingaben an ein Sprachmodell weiterzureichen und dessen Antwort auszugeben.
Der Agent kann zusätzliche Werkzeuge verwenden, auf externe Dienste zugreifen und mehrstufige Aufgaben bearbeiten. Dazu gehören beispielsweise Webrecherchen, das Abrufen von Informationen oder die Kommunikation mit anderen Anwendungen.
Die zugrunde liegenden Sprachmodelle lassen sich grundsätzlich von der eigentlichen Agentenplattform trennen. Dadurch kann Hermes sowohl mit lokalen Modellen als auch mit extern bereitgestellten KI-Modellen betrieben werden. Besonders interessant ist die Möglichkeit, zusätzliche Werkzeuge und Datenquellen einzubinden.
Neben eigenen Skills unterstützt Hermes auch das Model Context Protocol (MCP). Über MCP können externe Anwendungen standardisierte Funktionen zur Verfügung stellen, die anschließend vom Agenten verwendet werden.
In meinem CloudLab läuft Hermes als Docker-Anwendung auf einem Linux-Server. Als Benutzeroberfläche verwende ich Mattermost, das bereits in meiner Infrastruktur vorhanden ist.
Damit muss ich nicht für jede Informationsquelle eine separate KI-Oberfläche öffnen. Stattdessen kann ich Hermes direkt über den Teamchat ansprechen.
Ziel des Projekts
Für das Projekt habe ich drei unterschiedliche Anwendungsfälle ausgewählt.
E-Mail: Hermes soll Nachrichten aus meinem GMX-Postfach suchen, lesen und zusammenfassen können. Änderungen am Postfach oder der Versand von E-Mails sind aktuell noch nicht vorgesehen.
Kalender: Hermes soll Termine aus Google Calendar abrufen und perspektivisch auch verwalten können. Dabei sollen ausschließlich die notwendigen Google-Berechtigungen genehmigt werden.
Wissensverwaltung: Hermes soll auf vorhandene Notizen in Blinko zugreifen und Informationen daraus verwenden können. Die Anbindung erfolgt über MCP.
Diese drei Integrationen unterscheiden sich technisch erheblich. GMX verwendet IMAP, Google Calendar eine REST-API mit OAuth 2.0 und Blinko stellt einen MCP-Server bereit.
Gerade diese Unterschiede machen das Projekt interessant. Sie zeigen, dass ein KI-Agent nicht auf eine einzige Art der Integration beschränkt ist.
Die Architektur
Die zentrale Komponente ist der Hermes Agent. Der Agent verarbeitet die Benutzeranfrage und entscheidet anhand der verfügbaren Werkzeuge, welche Informationsquelle benötigt wird. Hermes übernimmt dabei die Steuerung der Werkzeuge. Die eigentlichen Daten verbleiben zunächst in den jeweiligen Anwendungen.
Eine E-Mail wird beispielsweise weiterhin von GMX bereitgestellt. Hermes nutzt Himalaya als IMAP-Client, um die benötigten Informationen abzurufen. Bei Google Calendar erfolgt der Zugriff über die Google Calendar API. Blinko wird über einen MCP-Server eingebunden. Anschließend verarbeitet Hermes die zurückgegebenen Informationen mithilfe des konfigurierten Sprachmodells. Wichtig ist dabei die Trennung zwischen Datenquelle, Agent und Sprachmodell.
Diese Architektur ermöglicht es grundsätzlich, einzelne Komponenten auszutauschen oder zu aktualisieren, ohne das gesamte System neu aufzubauen.
GMX – E-Mails lesen, ohne das Postfach zu verändern
Himalaya als IMAP-Schnittstelle
Für den Zugriff auf mein GMX-Postfach verwende ich Himalaya, einen quelloffenen E-Mail-Client für die Kommandozeile. Himalaya unterstützt unterschiedliche E-Mail-Protokolle und kann Nachrichten über eine CLI verarbeiten. Im CloudLab kommt Himalaya ausschließlich für den IMAP-Zugriff zum Einsatz. Die Verbindung wird verschlüsselt über TLS hergestellt.
Hermes kann damit beispielsweise folgende Aufgaben übernehmen:
„Welche neuen E-Mails habe ich heute erhalten?“
Oder:
„Fasse mir die wichtigsten Nachrichten der letzten beiden Tage zusammen.“
Das Prinzip des stillen Mitlesers
Der GMX-Zugriff wurde bewusst als rein lesende Integration eingerichtet. Hermes soll keine Nachrichten versenden, löschen, verschieben oder als gelesen markieren. Auch das Herunterladen von Anhängen ist nicht vorgesehen. Dafür wurde ein eigener restriktiver Hermes-Skill eingerichtet, der die zulässigen Himalaya-Operationen beschreibt. Auf eine SMTP-Konfiguration habe ich derzeit vollständig verzichtet. Dadurch steht der reguläre Versandweg über den Mailclient nicht zur Verfügung.
Beim Lesen von Nachrichten ist außerdem darauf zu achten, dass keine unerwünschten Änderungen am IMAP-Status erfolgen. Bestimmte IMAP-Befehle können beispielsweise das \Seen-Flag setzen und eine Nachricht damit als gelesen markieren. Die Integration soll deshalb nur geeignete Leseoperationen verwenden.
Keine vollständige technische Lesesperre
Ein wichtiger Unterschied besteht zwischen einer Beschränkung innerhalb des KI-Agenten und einer Berechtigung, die bereits der Mailserver erzwingt. Das GMX-Konto besitzt keine eigens eingerichtete serverseitige IMAP-Rolle, die ausschließlich lesende Befehle erlaubt. Die Einschränkung erfolgt daher auf Ebene der Himalaya-Integration und des Hermes-Skills.
Ein kompromittierter Agent mit Zugriff auf die Zugangsdaten und entsprechenden Ausführungsmöglichkeiten könnte diese Beschränkung möglicherweise umgehen. Das ist eine grundsätzliche Sicherheitsgrenze, die man bei solchen Konstruktionen berücksichtigen muss.
Eine Read-only-Anweisung an einen KI-Agenten ist nicht dasselbe wie ein technisch erzwungener Read-only-Zugang.
Authentifizierung mit anwendungsspezifischen Passwörtern
Eine weitere Möglichkeit zur Absicherung des IMAP-Zugriffs bietet GMX durch die Verwendung anwendungsspezifischer Passwörter.
Im Gegensatz zu Google Calendar steht für externe IMAP-Clients bei GMX derzeit keine allgemein dokumentierte OAuth-2.0-Authentifizierung zur Verfügung. Stattdessen können separate Anwendungspasswörter verwendet werden, die unabhängig vom regulären Kontopasswort verwaltet werden.
Der wesentliche Sicherheitsvorteil liegt in der Trennung zwischen dem persönlichen Kontopasswort und den Zugangsdaten einer externen Anwendung. Sollte ein Anwendungspasswort kompromittiert werden, lässt es sich gezielt widerrufen, ohne das reguläre GMX-Kontopasswort ändern zu müssen.
Zugangsdaten verschlüsselt speichern
Die für den IMAP-Zugriff verwendeten Zugangsdaten werden dauerhaft ausschließlich in verschlüsselter Form gespeichert. Dabei kommt ein hybrides Verschlüsselungsverfahren zum Einsatz, das symmetrische Datenverschlüsselung mit asymmetrischer Schlüsselverwaltung kombiniert.
Die verschlüsselt gespeicherten Informationen können ohne das entsprechende private Schlüsselmaterial nicht ohne Weiteres entschlüsselt werden.
Ein wesentlicher Bestandteil des Konzepts ist die Trennung von Schlüsselverwaltung und Anwendungsbetrieb. Der private Entschlüsselungsschlüssel wird außerhalb der eigentlichen KI-Agentenplattform verwaltet. Damit erhält Hermes keinen direkten Zugriff auf das Schlüsselmaterial, das für die Entschlüsselung der dauerhaft gespeicherten Zugangsdaten erforderlich ist.
Für den laufenden Betrieb werden die benötigten Authentifizierungsinformationen über einen gesonderten, zugriffsbeschränkten Mechanismus bereitgestellt. Dabei wird auf eine dauerhafte unverschlüsselte Speicherung verzichtet. Die Bereitstellung erfolgt ausschließlich für die vorgesehenen Anwendungsprozesse, wobei die Wirksamkeit der Zugriffsbeschränkungen von der Sicherheit der zugrunde liegenden Systemumgebung abhängt.
Wo liegen die Grenzen?
Auch eine mehrstufige Sicherheitsarchitektur kann nicht sämtliche Risiken ausschließen. Für die Authentifizierung gegenüber einem externen Dienst müssen die erforderlichen Zugangsdaten während des laufenden Betriebs in verwendbarer Form verfügbar sein.
Die verschlüsselte Speicherung schützt deshalb insbesondere die dauerhaft abgelegten Zugangsdaten. Sie verhindert jedoch nicht grundsätzlich, dass ein kompromittierter Prozess auf zur Laufzeit bereitgestellte Authentifizierungsinformationen zugreifen kann.
Wird beispielsweise der KI-Agent oder eine seiner ausführenden Komponenten vollständig kompromittiert, besteht grundsätzlich die Möglichkeit, dass ein Angreifer auf die zur Laufzeit bereitgestellten Authentifizierungsinformationen zugreift.
Auch die Trennung zwischen Schlüsselverwaltung und Anwendung kann dieses Restrisiko nicht vollständig beseitigen. Sie verhindert jedoch, dass der private Entschlüsselungsschlüssel regulär Bestandteil der Agentenumgebung ist, und erschwert damit bestimmte Angriffsszenarien.
Entscheidend ist daher die Unterscheidung zwischen dem Schutz gespeicherter Zugangsdaten und dem Schutz ihrer Verwendung zur Laufzeit.
Zugriff über die Google Calendar API
Die zweite Integration verbindet Hermes mit einem Google-Kalender. Hier kommt die offizielle Google-Workspace-Integration von Hermes zum Einsatz. Die Kommunikation erfolgt über die Google Calendar API. Anders als bei GMX verwendet man dabei kein klassisches Passwort, sondern OAuth 2.0.
Für Hermes wurde ein eigenes Google-Cloud-Projekt mit einem eigenen OAuth-Client eingerichtet. OAuth erlaubt es, einer Anwendung Zugriff auf bestimmte Funktionen eines Google-Kontos zu geben, ohne ihr das eigentliche Kontopasswort zu überlassen. Der Zugriff erfolgt über zeitlich begrenzte Access Tokens.
Ein Refresh Token ermöglicht die Erneuerung des Zugangs, ohne dass bei jedem Ablauf eine erneute Anmeldung notwendig wird.
Acht angeforderte Berechtigungen für einen Kalender?
In der zum Zeitpunkt meiner Einrichtung verwendeten Hermes-Version wurden zunächst acht OAuth-Berechtigungen angefordert. Eine direkte Auswahl der benötigten Dienste innerhalb des damaligen Einrichtungsablaufs stand mir nicht zur Verfügung.
Dazu gehören unter anderem Zugriffe auf:
- Google Calendar
- Gmail
- Google Drive
- Google Docs
- Google Sheets
- Google Contacts
Für meinen Anwendungsfall waren diese Berechtigungen deutlich zu umfangreich. Da ausschließlich der Kalenderzugriff benötigt wurde, sollte die Autorisierung konsequent auf diesen Dienst beschränkt werden.
Die Lösung fand sich schließlich im Google-Zustimmungsdialog. Dort konnte ich die tatsächlich benötigten Berechtigungen gezielt auswählen. Sämtliche nicht erforderlichen Zugriffe wurden abgewählt, sodass ausschließlich die Kalenderberechtigung genehmigt wurde.
Der tatsächlich erteilte Scope lautet:
https://www.googleapis.com/auth/calendarWarum der Kalender-Scope trotzdem nicht minimal ist
Auch hier lohnt sich eine genauere Betrachtung. Der verwendete Kalender-Scope erlaubt nicht nur das Lesen von Terminen. Er umfasst grundsätzlich auch Änderungen und weitergehende Kalenderverwaltungsfunktionen. Er ist deshalb umfangreicher als eine reine Leseberechtigung. Die Auswahl im Google-Zustimmungsdialog reduziert zwar die Anzahl der genehmigten Dienste, aber nicht automatisch die Berechtigungen innerhalb des Kalenderdienstes. Aus Sicht einer konsequenten Berechtigungsminimierung bleibt daher Verbesserungspotenzial.
Automatischer OAuth-Refresh
Token-Gültigkeit
Ein weiterer wichtiger Aspekt war die langfristige Nutzbarkeit der OAuth-Autorisierung. Google unterscheidet hierbei zwischen Anwendungen im Testmodus und solchen, die für den produktiven Einsatz veröffentlicht wurden.
Für meine CloudLab-Integration wurde die OAuth-Anwendung entsprechend konfiguriert und die Autorisierung anschließend erneuert.
Besonders wichtig war die Überprüfung des automatischen Token-Refreshs. Dieser konnte erfolgreich getestet werden: Hermes erneuerte die erforderlichen Zugriffstokens ohne erneute Benutzeranmeldung. Gleichzeitig wurde kontrolliert, dass die zuvor genehmigten OAuth-Berechtigungen unverändert blieben.
Damit ist die automatisierte Kalenderanbindung grundsätzlich auch über die begrenzte Gültigkeitsdauer einzelner Access Tokens hinaus möglich.
Token-Sicherheit
Während der Einrichtung fiel außerdem auf, dass Hermes die OAuth-Token-Datei zunächst nicht mit ausdrücklich restriktiven Dateirechten anlegte. Die Berechtigungen wurden deshalb manuell korrigiert. Anschließend wurde geprüft, dass diese Rechte auch nach einem Token-Refresh erhalten bleiben.
Im Gegensatz zur GMX-Integration erfolgt die Speicherung der Google-OAuth-Tokens über den Standardmechanismus der verwendeten Hermes-Google-Workspace-Integration. Dabei werden die Authentifizierungsinformationen in einer lokalen Token-Datei gespeichert, deren Zugriff durch restriktive Dateiberechtigungen geschützt wird.
Eine zusätzliche Verschlüsselung der gespeicherten Tokens ist in dieser Standardimplementierung nicht vorgesehen.
Die Sicherheitsgrenze: Ein Prozess mit ausreichenden Dateizugriffsrechten könnte die gespeicherten Tokens auslesen und möglicherweise für einen unberechtigten Zugriff auf die freigegebenen Google-Dienste verwenden. Die Wirksamkeit dieses Zugriffs hängt unter anderem von der Gültigkeit der Tokens und den erteilten OAuth-Berechtigungen ab.
Auch hier zeigt sich, dass eine funktionierende OAuth-Anmeldung noch kein vollständiges Sicherheitskonzept darstellt.
Blinko – Persönliches Wissen über MCP einbinden
Was ist Blinko?
Blinko ist eine quelloffene Anwendung zur Verwaltung persönlicher Notizen und Informationen. Sie eignet sich insbesondere dazu, Gedanken, kurze Aufzeichnungen und andere Wissensinhalte zentral abzulegen. In meinem CloudLab wird Blinko selbst gehostet. Die eigentliche Herausforderung bestand darin, diese Notizen auch für Hermes zugänglich zu machen. Dafür verwendet Blinko einen MCP-Server.
Das Model Context Protocol
Das Model Context Protocol ist ein standardisiertes Verfahren, über das KI-Anwendungen auf externe Datenquellen und Werkzeuge zugreifen können. Ein MCP-Server stellt dazu definierte Funktionen bereit. Der KI-Agent muss dadurch nicht die vollständige interne API einer Anwendung kennen. Stattdessen kann er die angebotenen Werkzeuge ermitteln und verwenden. Im Fall von Blinko stehen beispielsweise Funktionen zum Suchen, Erstellen, Aktualisieren und Löschen von Notizen zur Verfügung.
Die Herausforderung mit den MCP-Berechtigungen
Eine besondere Herausforderung bei der Integration von MCP-Diensten liegt in der differenzierten Steuerung der verfügbaren Werkzeugberechtigungen. Ein MCP-Server kann neben lesenden Funktionen auch Operationen zum Erstellen, Bearbeiten oder Löschen von Informationen bereitstellen.
Aus sicherheitstechnischer Sicht ist deshalb entscheidend, welche dieser Funktionen einem KI-Agenten tatsächlich zur Verfügung stehen. Insbesondere verändernde und löschende Operationen sollten durch geeignete Berechtigungs- und Kontrollmechanismen abgesichert werden.
Ein KI-Agent kann Benutzeranfragen unter Umständen falsch interpretieren oder durch manipulierte Inhalte beeinflusst werden. Dadurch besteht grundsätzlich das Risiko, dass unbeabsichtigte Änderungen oder Löschoperationen ausgelöst werden.
Eine sichere MCP-Integration sollte deshalb nicht ausschließlich auf Anweisungen an das Sprachmodell vertrauen. Ergänzende technische Zugriffsbeschränkungen und geeignete Freigabeverfahren sind insbesondere bei kritischen Aktionen erforderlich.
Besonders schreibende und löschende Funktionen sollten nur dann verfügbar sein, wenn sie tatsächlich benötigt werden.
Die eigentliche Sicherheitsfrage lautet deshalb nicht nur, ob ein KI-Agent auf einen Dienst zugreifen kann, sondern was er mit diesem Zugriff tatsächlich tun darf.
Docker – Modularer Betrieb
Hermes wird im CloudLab als Docker-Anwendung betrieben. Das erleichtert die Bereitstellung und Aktualisierung des Agenten erheblich.
Sicherheit – Die eigentliche Herausforderung eines KI-Agenten
Die technische Anbindung externer Systeme ist heute vergleichsweise einfach geworden. APIs, OAuth und MCP stellen standardisierte Verfahren bereit, mit denen Anwendungen Informationen austauschen können.
Schwieriger wird es bei der Kontrolle eines KI-Agenten.
Ein klassisches Programm führt normalerweise klar definierte Abläufe aus. Ein KI-Agent entscheidet dagegen abhängig von der Benutzeranfrage und dem verfügbaren Kontext, welche Werkzeuge benötigt werden.
Das eröffnet interessante Möglichkeiten, schafft aber auch neue Risiken.
Prompt Injection
Dabei werden Anweisungen in Daten eingebettet, die ein KI-Agent verarbeitet. Eine E-Mail oder Blinko-Notiz könnte beispielsweise versuchen, Hermes zur Ausführung unerwünschter Aktionen zu bewegen.
- Ein Text innerhalb einer E-Mail darf nicht die Berechtigung erhalten, andere E-Mails zu löschen.
- Ebenso darf eine Blinko-Notiz nicht allein deshalb eine Löschoperation auslösen, weil ihr Inhalt eine entsprechende Aufforderung enthält.
- Die bloße Formulierung entsprechender Regeln innerhalb eines Skills reicht jedoch nicht aus, um solche Risiken vollständig auszuschließen.
- Bei kritischen Aktionen sind zusätzlich technisch durchgesetzte Berechtigungen erforderlich.
Die entscheidende Sicherheitsregel lautet deshalb:
Inhalte aus externen Datenquellen sind Informationen – keine autorisierten Steueranweisungen.
Lokale Infrastruktur bedeutet nicht automatisch lokale Datenverarbeitung
Ein weiterer Punkt betrifft den Einsatz von Cloud-Modellen. Hermes, Mattermost, Himalaya und Blinko laufen innerhalb meiner eigenen Infrastruktur.
Das bedeutet jedoch nicht automatisch, dass sämtliche Informationen dort verbleiben. Wenn Hermes ein extern betriebenes Sprachmodell verwendet, können Teile der abgerufenen Informationen an diesen Dienst übermittelt werden. Bei E-Mails, Kalenderterminen und persönlichen Notizen ist das besonders relevant. Deshalb muss klar zwischen der selbst betriebenen Agentenplattform und dem tatsächlich verwendeten Sprachmodell unterschieden werden.
Für besonders schützenswerte Informationen kann ein vollständig lokales Modell die konsequentere Lösung sein.
Auch dann müssen allerdings die Zugriffsrechte des Agenten und die Sicherheit der angebundenen Anwendungen berücksichtigt werden.
Erfahrungen aus dem Projekt
Die Verbindung der drei Informationsquellen hat gezeigt, wie leistungsfähig ein selbst betriebener KI-Agent inzwischen sein kann. Besonders positiv fällt auf, dass sich sehr unterschiedliche Systeme über eine gemeinsame Agentenoberfläche nutzen lassen.
Statt zwischen mehreren Anwendungen zu wechseln, können Informationen direkt über Mattermost abgefragt werden. Dabei übernimmt Hermes die Auswahl und Ausführung der passenden Werkzeuge.
Die Integration von Blinko über MCP ist vergleichsweise elegant. Der Agent erhält eine standardisierte Schnittstelle und muss die internen Details der Anwendung nicht kennen.
Der GMX-Zugriff war dagegen deutlich aufwendiger. Nicht die IMAP-Verbindung selbst verursachte die größte Arbeit, sondern die sichere Verwaltung des Passworts und die Begrenzung der zulässigen Operationen. Hier wurde bewusst auf ein mehrstufiges Sicherheitskonzept mit hybrider Verschlüsselung, getrennter Schlüsselverwaltung und kontrollierter Bereitstellung der Zugangsdaten gesetzt.
Bei Google Calendar lag die eigentliche Herausforderung zunächst im OAuth-Berechtigungsmodell. Die offizielle Hermes-Integration forderte wesentlich mehr Rechte an, als für meinen Anwendungsfall erforderlich waren. Erst die gezielte Auswahl im Google-Zustimmungsdialog ermöglichte die gewünschte Beschränkung auf den Kalenderzugriff.
Eine weitere sicherheitsrelevante Erkenntnis betrifft die Speicherung der OAuth-Tokens. Während OAuth die Weitergabe des eigentlichen Google-Passworts vermeidet und Zugriffsberechtigungen gezielt einschränken kann, müssen die ausgestellten Tokens für den laufenden Betrieb gespeichert beziehungsweise verfügbar gehalten werden.
In der verwendeten Standardimplementierung erfolgt dies über eine lokale Token-Datei, deren Zugriff durch restriktive Dateiberechtigungen geschützt wird. Eine zusätzliche Verschlüsselung der gespeicherten Tokens ist derzeit nicht vorgesehen.
Damit entsteht ein potenzieller zentraler Kompromittierungspunkt: Gelingt es einem Angreifer, gültige OAuth-Tokens auszulesen, kann er diese unter Umständen für unberechtigte API-Zugriffe verwenden. Besonders kritisch sind dabei Refresh Tokens, da sie abhängig von ihrer Gültigkeit und den Sicherheitsmechanismen des Anbieters die wiederholte Ausstellung neuer Access Tokens ermöglichen können.
Diese Problematik beschränkt sich keineswegs auf Hermes oder Google Calendar. Sie betrifft grundsätzlich zahlreiche Anwendungen, die Zugangsdaten, API-Schlüssel oder Authentifizierungstokens dateibasiert verwalten.
Auch eine zusätzliche Verschlüsselung beseitigt das Problem nicht vollständig. Sobald eine Anwendung auf geschützte Informationen zugreifen muss, benötigt sie entweder die entschlüsselten Zugangsdaten oder einen entsprechenden Zugriff auf den Entschlüsselungsmechanismus.
Die eigentliche Herausforderung liegt deshalb nicht allein in der Verschlüsselung gespeicherter Informationen, sondern in der konsequenten Begrenzung des Zugriffs auf sicherheitskritisches Schlüsselmaterial und Authentifizierungsinformationen.
Die Erfahrungen aus dem Projekt zeigen, dass die Integration externer Dienste technisch häufig unkompliziert ist. Der größere Aufwand entsteht bei der Entwicklung eines nachvollziehbaren Sicherheitskonzepts, das Authentifizierung, Berechtigungen, Speicherung und Laufzeitschutz gleichermaßen berücksichtigt.
Was funktioniert bereits
Die wichtigsten lesenden Anwendungsfälle sind inzwischen erfolgreich umgesetzt.
Hermes kann über Mattermost:
- Informationen aus GMX-E-Mails abrufen und zusammenfassen.
- Google-Kalendertermine abfragen und Informationen daraus bereitstellen. Die verwendete Integration unterstützt darüber hinaus grundsätzlich das Erstellen und Löschen von Terminen.
- Blinko-Notizen suchen, lesen und Informationen daraus verwenden. Über die MCP-Schnittstelle stehen grundsätzlich auch Funktionen zur Erstellung, Bearbeitung und Löschung von Einträgen zur Verfügung.
Besonders interessant ist, dass die drei Systeme dabei ihre jeweils eigenen Schnittstellen behalten.
Hermes bildet lediglich die gemeinsame Zugangsschicht.
Fazit
Die Kombination aus Hermes Agent, Mattermost, Himalaya, Google Calendar und Blinko zeigt, wie sich unterschiedliche Informationsquellen zu einer gemeinsamen KI-gestützten Arbeitsumgebung verbinden lassen.
Hermes übernimmt die Rolle der zentralen Vermittlungs- und Steuerungsschicht. Die eigentlichen Daten verbleiben zunächst in ihren jeweiligen Anwendungen. GMX stellt E-Mails bereit, Google Calendar verwaltet Termine und Blinko dient als persönliche Wissensbasis. Der entscheidende Mehrwert entsteht durch den Zugriff auf diese Informationen über natürliche Sprache.
Statt jede Anwendung einzeln bedienen zu müssen, kann der Benutzer seine Frage direkt an Hermes richten. Besonders überzeugend finde ich dabei die modulare Architektur. Neue Informationsquellen können ergänzt werden, ohne den Agenten vollständig neu entwickeln zu müssen.
Gleichzeitig hat das Projekt gezeigt, dass Sicherheit nicht allein durch den Einsatz moderner Standards wie OAuth oder MCP entsteht.
Ein funktionierender API-Zugriff sagt noch nichts darüber aus, ob die vergebenen Berechtigungen angemessen sind. Eine verschlüsselte Verbindung schützt nicht automatisch vor unzulässigen Werkzeugaufrufen. Und ein selbst gehosteter KI-Agent garantiert nicht, dass sämtliche Daten ausschließlich lokal verarbeitet werden.
Die eigentliche Herausforderung besteht darin, die Leistungsfähigkeit eines KI-Agenten mit kontrollierbaren Zugriffsrechten, geschützten Zugangsdaten und nachvollziehbaren Abläufen zu verbinden.
Genau darin sehe ich die zukünftige Entwicklung solcher Systeme.
Weg vom isolierten Chatbot, der ausschließlich Fragen beantwortet. Hin zu einem persönlichen Assistenzsystem, das unterschiedliche Informationsquellen nutzen, Zusammenhänge herstellen und definierte Aufgaben unterstützen kann.
Ausblick – Von der Informationsabfrage zur kontrollierten Automatisierung
Der nächste Entwicklungsschritt liegt für mich nicht allein in der Anbindung weiterer Datenquellen. Interessanter wird die Frage, wie sich aus den vorhandenen Integrationen kontrollierte Arbeitsabläufe entwickeln lassen.
Denkbar wären beispielsweise die Zusammenfassung relevanter E-Mails, der Abgleich mit bevorstehenden Terminen oder die strukturierte Ablage ausgewählter Informationen in Blinko.
Dabei soll Hermes jedoch nicht eigenständig beliebige Entscheidungen über persönliche Daten treffen. Vielmehr müssen schreibende und verändernde Aktionen klar autorisiert, begrenzt und nachvollziehbar sein.
Langfristig könnte so aus mehreren unabhängigen Anwendungen (Mail, Kalender und Notizen) eine zusammenhängende persönliche Informationsplattform entstehen. Hermes bildet dabei die Verbindung zwischen Benutzer, Datenquellen und Sprachmodell.
Der eigentliche Fortschritt liegt weniger darin, dass die KI immer mehr Funktionen erhält, sondern darin, dass sie vorhandene Informationen im richtigen Kontext und innerhalb klar definierter Sicherheitsgrenzen verwenden kann.
Mein persönliches Schlusswort – Die Zukunft gehört persönlichen KI-Assistenten
Ich bin davon überzeugt, dass wir in absehbarer Zeit einen grundlegenden Wandel im Umgang mit digitalen Anwendungen erleben werden. Klassische Einzelprogramme wie E-Mail-Clients, Kalender oder Notizverwaltungen werden meiner Einschätzung nach zunehmend in den Hintergrund treten. Ihre Funktionen und die dahinterliegenden Dienste werden weiterhin benötigt, doch die Art und Weise, wie wir mit ihnen interagieren, dürfte sich grundlegend verändern.
Die Zukunft sehe ich in persönlichen, KI-gestützten Agentensystemen, die unterschiedliche Dienste miteinander verbinden und dem Menschen als zentrale Schnittstelle dienen.
Statt zwischen zahlreichen Anwendungen zu wechseln, Menüs zu durchsuchen und immer wieder Formulare auszufüllen, werden wir unsere Anliegen zunehmend in natürlicher Sprache formulieren. Der persönliche KI-Assistent übernimmt die Kommunikation mit den entsprechenden Diensten, stellt Zusammenhänge her und unterstützt uns bei der Erledigung alltäglicher Aufgaben.
Für mich ist das ein entscheidender Fortschritt in der Mensch-Maschine-Interaktion. Nicht mehr der Mensch muss sich an die Bedienkonzepte der Software anpassen, sondern die Software orientiert sich stärker an den Bedürfnissen und der natürlichen Kommunikation des Menschen. Damit rückt die Ergonomie digitaler Anwendungen wieder stärker in den Mittelpunkt.
Mein CloudLab-Projekt zeigt mir bereits heute, welches Potenzial in diesem Ansatz steckt. Auch wenn die technischen Möglichkeiten noch nicht vollständig ausgereift sind, zeichnet sich für mich eine Entwicklung ab, die unseren Umgang mit IT nachhaltig verändern könnte.
Umso gespannter bin ich, welche Lösungen die großen Software- und Technologiehersteller in den kommenden Jahren vorstellen werden. Dabei hoffe ich allerdings, dass neben Benutzerfreundlichkeit und Funktionalität auch Datenschutz, Datensouveränität und die Kontrolle über persönliche Informationen einen angemessenen Stellenwert behalten.
Denn gerade persönliche KI-Assistenten werden künftig möglicherweise auf einen erheblichen Teil unseres digitalen Lebens zugreifen können. E-Mails, Termine, Kontakte, Dokumente und persönliche Aufzeichnungen ergeben zusammengenommen ein äußerst detailliertes Bild unserer Lebensgewohnheiten und Interessen.
Diese Informationen dürfen nicht zum bloßen Wirtschaftsgut werden, bei dem kommerzielle Interessen und der zunehmende Hunger nach persönlichen Daten Vorrang vor dem Schutz der Privatsphäre erhalten.
Für mich wird sich die Qualität zukünftiger KI-Assistenten deshalb nicht allein daran messen lassen, wie intelligent oder komfortabel sie sind. Entscheidend wird auch sein, wie transparent sie arbeiten, wie zuverlässig sie unsere Daten schützen und wie viel Kontrolle sie uns über unsere eigenen Informationen ermöglichen.
Mein Wunsch für die Zukunft ist daher ein persönlicher KI-Assistent, der für den Menschen arbeitet – und nicht ein Mensch, dessen Daten für die Geschäftsmodelle seines KI-Assistenten arbeiten.
Technischer Hinweis: Die beschriebenen Erfahrungen beziehen sich auf den Stand meiner CloudLab-Installation im Oktober 2026. Da sich die eingesetzten Anwendungen kontinuierlich weiterentwickeln, können sich Funktionsumfang, Konfigurationsmöglichkeiten und Sicherheitsmechanismen in späteren Versionen unterscheiden.
Transparenzhinweis: Bei der Erstellung dieses Artikels wurde künstliche Intelligenz zur sprachlichen und redaktionellen Unterstützung eingesetzt. Die beschriebenen technischen Konzepte und praktischen Erfahrungen basieren auf meinem eigenen CloudLab-Projekt. Die inhaltliche Prüfung und redaktionelle Verantwortung liegen beim Autor.
