Einer der folgenschwersten Veränderungen in der Sicherheits- und Datenschutzlandschaft findet derzeit nicht in traditioneller Infrastruktur statt. Sie ereignet sich an der Schnittstelle zwischen großen Sprachmodellen und der physischen Welt. LLMs sind nicht länger auf die Textverarbeitung in isolierten Umgebungen beschränkt. Ihnen werden Werkzeuge an die Hand gegeben. Ihnen wird Zugriff auf externe Systeme gewährt. Sie werden aufgefordert, von realen Geräten zu lesen, in reale Datenbanken zu schreiben und reale Aktionen auf realen Maschinen auszulösen.
Dies ist wirklich aufregend. Aus Sicherheitssicht ist es auch eine Risikokategorie, die sorgfältiges architektonisches Denken erfordert. Das Model Context Protocol (MCP) – Anthropic's offener Standard für die Verbindung von LLMs mit externen Werkzeugen und Datenquellen – ist eine der wichtigsten Entwicklungen in diesem Bereich. Und der awaBerry Agentic MCP Server ist unser Weg, Zero-Trust-Gerätezugriff in dieses Ökosystem zu integrieren.
Was das Model Context Protocol leistet
MCP definiert eine standardisierte Methode, mit der Sprachmodelle externe Werkzeuge aufrufen können: eine Datei lesen, eine Abfrage ausführen, einen Dienst aufrufen, Daten von einem Gerät abrufen. Anwendungen wie Claude Desktop implementieren die MCP-Clientseite. Externe Systeme – Datenbanken, APIs, Gerätemanager – implementieren die MCP-Serverseite. Wenn ein LLM Daten benötigt oder eine Aktion ausführen muss, ruft es den entsprechenden MCP-Server auf, erhält ein strukturiertes Ergebnis und integriert es in seine Entscheidungsfindung.
Die Stärke dieser Architektur liegt in Modularität und Komponierbarkeit. Das LLM muss nicht wissen, wie es mit Ihrem spezifischen Gerät kommuniziert. Es muss nur wissen, dass ein MCP-Werkzeug existiert, das Daten davon abrufen kann. Die Sicherheit des Systems hängt vollständig davon ab, wie dieser MCP-Server implementiert ist – insbesondere davon, ob er angemessene Zugriffskontrollen zwischen den Anfragen des LLM und den Zielgeräten durchsetzt.
Der awaBerry Agentic MCP Server
Der awaBerry Agentic MCP Server stellt Ihre registrierten awaBerry-Geräte als MCP-Werkzeuge bereit. Wenn er in Claude Desktop (oder einem anderen MCP-kompatiblen Client) konfiguriert ist, ermöglicht er dem LLM:
- Daten aus bestimmten Verzeichnissen auf bestimmten Geräten zu lesen
- Erlaubte Befehle auszuführen und deren Ausgabe abzurufen
- Strukturierte Datendateien zur Analyse zu laden
- Ergebnisse an definierte Ausgabepunkte zurückzuschreiben (sofern Schreibberechtigungen erteilt wurden)
All dies geschieht über die awaBerry Agentic API – was bedeutet, dass jede Interaktion durch einen Project Key mit präzise definierten Berechtigungen gesteuert wird, über eine reine HTTPS-Ausgangsverbindung getunnelt und mit einer vollständigen Audit-Spur protokolliert wird.
Ein konkretes Szenario
Lassen Sie mich dies konkretisieren. Stellen Sie sich ein Forschungsteam vor, das Umweltdaten von einer Flotte von Fernüberwachungsgeräten sammelt – Temperatur-, Feuchtigkeits- und Luftqualitätsmessungen, die auf jedem Gerät in strukturierten CSV-Dateien protokolliert werden. Sie möchten Claude nutzen, um Muster in diesen Daten zu analysieren und eine schriftliche Zusammenfassung von Anomalien für den wöchentlichen Forschungsbericht zu erstellen.
Mit dem awaBerry Agentic MCP Server, der in Claude Desktop konfiguriert ist:
- Der Forscher gibt eine Aufforderung ein: „Analysieren Sie die Sensordaten dieser Woche von den Feldstationen und fassen Sie alle Anomalien oder Trends zusammen, auf die ich aufmerksam gemacht werden sollte.“
- Claude identifiziert das relevante MCP-Werkzeug – den awaBerry-Gerätedatenleser – und ruft es mit den entsprechenden Parametern auf.
- Der MCP-Server authentifiziert sich anhand der awaBerry Agentic API mit dem konfigurierten Project Key, öffnet einen gesicherten Tunnel zu jedem registrierten Feldstationsgerät und liest die relevanten Datendateien.
- Die Rohsensordaten werden als strukturierter Kontext an Claude zurückgegeben.
- Claude analysiert die Daten, identifiziert Anomalien und schreibt eine klare, strukturierte Zusammenfassung – direkt in der Konversation.
Der Forscher erhält eine Analyse von Daten in KI-Qualität, die sich auf physischen Fernüberwachungsgeräten befinden, ohne eine einzige Zeile Integrationscode schreiben zu müssen und ohne diese Geräte in irgendeiner Weise dem Internet auszusetzen.
Warum die Sicherheitsarchitektur hier wichtig ist
Ich möchte offen über die Sicherheitseigenschaften sprechen, die diesen Ansatz zu einer verantwortungsvollen Bereitstellung machen – denn „einem LLM Zugriff auf Ihre Geräte gewähren“ ist ohne die richtigen Kontrollen eine Aussage, die jeden Sicherheitsexperten beunruhigen sollte.
Das Berechtigungsmodell der awaBerry Agentic API gilt für MCP-Server-Interaktionen genauso wie für jeden anderen programmatischen Zugriff:
- Bereich der Berechtigungen: Das LLM kann nur mit der in der Projektkonfiguration definierten Berechtigungsstufe arbeiten – standardmäßig Benutzer, nur Root, wenn explizit aktiviert.
- Dateisystembereich: Lesezugriff kann auf benannte Verzeichnisse beschränkt werden. Das LLM kann nicht das gesamte Dateisystem durchsuchen, es sei denn, das Projekt erlaubt dies ausdrücklich.
- Schreibberechtigungen: Schreibzugriff ist standardmäßig deaktiviert. Er muss pro Projekt explizit aktiviert werden und kann auf bestimmte Pfade beschränkt werden.
- Befehlsumfang: Eine explizite Whitelist zulässiger Befehle kann definiert werden. Der MCP-Server führt nichts außerhalb dieser Liste aus, unabhängig davon, was das LLM anfordert.
Jede MCP-Interaktion generiert einen vollständigen Audit-Protokolleintrag. Wenn etwas Unerwartetes passiert – wenn das LLM etwas anfordert, das es nicht tun sollte, oder wenn ein ungewöhnliches Muster in den Zugriffsprotokollen auftritt – verfügt das Sicherheitsteam über eine vollständige, strukturierte Aufzeichnung zur Untersuchung.
Und die sofortige Widerrufbarkeit bedeutet, dass das Risiko zeitlich streng begrenzt ist: Wenn das Projekt gelöscht wird, endet der Zugriff vollständig, ohne Rückstände.
Device as a Service, sicher umgesetzt
Der Begriff „Device as a Service“ wird im Bereich der KI-Infrastruktur immer häufiger verwendet. Was er in der Praxis bedeutet, variiert enorm. Am einen Ende des Spektrums bedeutet er, Gerätedaten breit für jedes LLM zugänglich zu machen, das danach fragt. Am anderen Ende – dem awaBerry-Ende – bedeutet er, Gerätedaten für LLMs innerhalb einer Zero-Trust-Grenze verfügbar zu machen, die präzise definiert, vollständig auditiert und sofort widerrufbar ist.
Die LLMs werden mit Ihren Geräten interagieren. Die Frage ist, ob Sie mit der Architektur, die diese Interaktion vermittelt, zufrieden sind. Erkunden Sie die Agentic API →
