Autor: Rijesh Haridas

20. Juli 2026

Souveräne KI-Agenten für die Cloud: Read-only-Standard und Inferenz aus Deutschland

Wir kombinieren den IONOS CLOUD MCP Server und den AI Model Hub zu einem Read-only-KI-Agenten für höchste Compliance-Ansprüche: 118 Möglichkeiten zur Cloud-Analyse, keine einzige zur Veränderung – mit Modell-Inferenz aus souveränen, deutschen Rechenzentren.

Im Produktmanagement vertreten wir eine klare These: Nicht der Zugriff der KI ist das Problem, sondern ihre fehlende Beschränkung auf reine Leseoperationen.

Im Juni haben wir den IONOS CLOUD MCP Server veröffentlicht, einen quelloffenen Server, der KI-Assistenten wie Claude Desktop, Cursor, VS Code oder Windsurf über das Model Context Protocol an ein IONOS CLOUD-Konto anbindet. Stand Juli 2026 enthält er 118 Tools für sieben Produkte: Compute Engine, Object Storage, Cloud DNS, Certificate Manager, Billing, Activity Log und Managed Kubernetes.

Dabei liegt unser Fokus auf einem Read-only-MCP-Server: Alle 118 Tools lesen, keines schreibt. Wir verzichten bewusst auf Befehle wie create_server oder delete_anything. Unser Agent sieht alles, fasst aber nichts an.

Durch die Kopplung mit dem IONOS CLOUD AI Model Hub, der offene Modelle wie Mistral und Llama in deutschen Rechenzentren bereitstellt, verlässt auch die Verarbeitung der Anfragen die EU nicht.

Souveräne KI-Workflows: Warum wir beim MCP Server bewusst auf Schreibrechte verzichten

Wir definieren einen KI-Agenten als souverän, wenn die gesamte Kette aus Modell, Infrastruktur und Datenfluss unter einem gewählten Rechtsraum liegt. Wir setzen auf prüfbare Infrastruktur ohne Abhängigkeiten von Anbietern außerhalb dieses Hoheitsgebiets. Souveränität betrifft bei uns das Gesamtsystem: Modell-Inferenz, API-Zugriff und Tool-Ausgaben.

Mit diesem strengen Verständnis grenzen wir uns vom Markt ab, der oft nur Teilaspekte als souverän bewirbt.

Wie Daten im MCP-Modell geschützt bleiben

Bei einer Anfrage an den MCP-Server stellen wir die Sicherheit durch vier Säulen sicher:

1. Lokale Zugangsdaten: Unser Server läuft als lokales Binary. Das IONOS CLOUD-API-Token bleibt in der lokalen Konfiguration und kommuniziert direkt mit der IONOS CLOUD API – ohne Umwege.

2. Der Prompt: Die Eingaben werden an das Modell des gewählten KI-Clients übermittelt. Bei Claude Desktop bedeutet das, dass Anthropic den Prompt erhält. Welche Daten die Client-Anwendung selbst protokolliert oder übermittelt, bleibt eine Vertrauensfrage. Da der Server keine Kontrolle über die Host-App hat, sollte die Wahl des Clients mit derselben Sorgfalt erfolgen wie bei jeder Software mit Zugriff auf sensible Produktivdaten

3. Die Tool-Ausgaben: Die meisten Hersteller-Beiträge lassen diesen Teil aus. Wir sagen es ganz direkt: Ruft der Agent list_servers auf und es enthält Servernamen, IP-Adressen und Konfigurationen, geht diese Antwort zur Verarbeitung an das Backend des Modell-Anbieters, also überquert die Anfrage meistens den Atlantik.

4. Absolut zustandslos: Unser Server ist zustandslos (stateless) und sendet keine Daten an externe Gegenstellen. Der Quellcode auf GitHub ist offen zur Verifikation.

Den Datenschutz gewährleisten wir durch den AI Model Hub. Bei Nutzung von Mistral- oder Llama-Modellen im Model Hub verbleibt die gesamte Schleife (Prompt, Verarbeitung, Tool Ausgabe und Infrastruktur-API) in deutschen Rechenzentren. Unser „Fully Sovereign AI Workflow“-Guide visualisiert diesen vollständig europäischen Stack.

Ein Hinweis für die Systemarchitektur: Clients wie Claude Desktop und Cursor senden die Inferenz immer an ihr eigenes Backend. Ein souveräner Weg erfordert daher einen Client, der eigene, OpenAI-kompatible Inferenz-Endpunkte akzeptiert. Wir listen passende Clients und den Nachweis der Perimeter-Sicherheit im selben Guide auf.

Wir ermöglichen die aktive Gestaltung von Datenflüssen. Ob die Verarbeitung durch Modelle wie Claude ausreicht oder volle Souveränität nötig ist, bleibt eine bewusste Architektur-Entscheidung.

Montagmorgen, 07:52 Uhr: Incident-Triage mit einem read-only KI-Agenten

Die folgende Konversation ist leicht redigiert aus einer echten Session mit Claude Desktop, also, wie oben beschrieben, nicht in der souveränen Konfiguration.

Die Lage: Seit dem Wochenende bekommen Kunden eines Shop-Backends Zertifikatsfehler, und die mobile App verbindet sich gar nicht mehr. Der Kollege, der die Hälfte davon aufgesetzt hat, ist im Urlaub. Klassischer Montag.

Ich: Kunden bekommen seit dem Wochenende Zertifikatsfehler von unserem Shop-Backend. Die mobile App verbindet sich nicht. Kannst du prüfen, was sich seit Freitag 18 Uhr in unserem IONOS-Konto geändert hat?

Der Agent analysierte per list_activitylog_events das Wochenende. Ergebnis: erfolgreicher Server-Resize am Samstag, nächtliche Volume-Snapshots, sonst keine Änderungen. Der Agent schlug eine Prüfung des resizten Servers vor.

Ich: Sieh nach.

Durch get_server, get_lan und list_nics bestätigten wir: Der Server läuft, das LAN ist gesund. Eine Sackgasse. Wir lernten: Das Activity Log zeigt Änderungen, aber keine schleichenden Abläufe. Zwanzig Minuten Klickerei im DCD gespart mit einer Abfrage.

Ich: Trotz unveränderter Konfiguration blieb das System unerreichbar. Wir weiten die Analyse auf weitere Ressourcen wie Zertifikate oder DNS-Einträge aus.

Der Aufruf von list_cert_certificates brachte den Erfolg. Wir identifizierten ein am Sonntag abgelaufenes TLS-Zertifikat am Load Balancer. Ein DNS-Check per list_dns_records bestätigte die korrekte IP-Zuordnung. Diagnose: System überfällig, nicht defekt.

Root-Cause gefunden in zehn Minuten. Ein abschließender Test zeigte die Sicherheitsbarriere.

Ich: Super. Lösch bei der Gelegenheit gleich den alten Staging-Server.

Agent: Diese Aktion ist nicht möglich. Der IONOS-MCP-Server stellt ausschließlich lesende Tools bereit. Ich kann Details anzeigen, aber keine Ressourcen löschen oder ändern.

Diese systemseitige Absage bestätigt unsere Produktphilosophie. Die Zertifikatserneuerung übernahm schließlich ein Administrator mit entsprechendem Change-Ticket.

Warum Read-only kein Kompromiss ist, sondern eine Entscheidung

Wir haben „Read-only by default“ als zentrale Sicherheitsentscheidung für den MCP-Server etabliert und konsequent verteidigt.

Wir begrenzen dadurch das Schadenspotenzial massiv. Prompt-Injections oder fehlerhafte Agent-Schleifen führen bei Lesezugriffen maximal zu ungenauen Berichten statt zu Systemausfällen. Wir verwandeln potenzielle Incidents in harmlose Anekdoten.

Das weniger naheliegende Argument: Read-only heißt auch, dass es keinen Weg gibt, Zugangsdaten abzugreifen. Das strengste Beispiel ist Managed Kubernetes. Die Kubernetes-API kennt eine gewöhnliche Leseoperation, um die Kubeconfig eines Clusters herunterzuladen — und dafür gibt es bewusst kein Tool. Denn eine Kubeconfig ist keine Information über die Infrastruktur, sie ist der Zugang zur Infrastruktur. Der MCP-Server listet also Cluster, Node Pools und Versionen und rührt die eine Leseoperation nicht an, die faktisch ein Schlüssel ist. Aus demselben Grund sollte das API-Token zu einem Benutzer mit möglichst eng gefassten Gruppenrechten gehören. Least Privilege gilt für das Token eines Agenten wie für jedes andere.

Wir setzen auf technische Barrieren statt auf Verhaltensanweisungen für KI-Modelle. Sollten wir künftig Schreibrechte einführen, erfolgt dies ausschließlich als explizites Opt-in.

Unsere Anwendungsfälle zeigen die Stärke dieses Ansatzes: Sicherheits-Audits für Object-Storage, FinOps-Kostenberichte und automatisierte Compliance-Audits. Wir stellen fertige Prompts im Use-Case-Bereich unserer Dokumentation bereit.

In zehn Minuten zum eigenen Read-only-Agenten

Unsere MCP-Server-Dokumentation bietet Anleitungen für Cursor, VS Code und weitere Clients. Hier die Kurzübersicht:

Das Binary für die passende Plattform von der Releases-Seite laden (oder per go install).
Ein IONOS API-Token anlegen — im DCD unter Management > Token Manager oder mit ionosctl token generate.
Den Server im Client eintragen. Für Claude Desktop (der schnelle Weg; für das souveräne Setup dient ein Client mit konfigurierbarem Endpunkt, siehe Guide oben) genügt ein Block in claude_desktop_config.json:

{
  "mcpServers": {
    "ionoscloud": {
      "command": "/path/to/ionoscloud-mcp",
      "env": {
        "IONOS_TOKEN": "your-api-token",
        "IONOS_S3_ACCESS_KEY": "your-s3-access-key",
        "IONOS_S3_SECRET_KEY": "your-s3-secret-key"
      }
    }
  }
}

4. Client neu starten und etwas fragen, wofür sonst der Weg durchs DCD nötig wäre. „Welche Zertifikate laufen in den nächsten 60 Tagen ab?“ ist eine gute erste Frage – genau die, die vor jenem Wochenende den Fehler hätte vermeiden können.

Noch ein praktischer Hinweis: Standardmäßig meldet der Server beim Start alle 118 Tools an (eager-Modus), richtig für Claude Desktop und die meisten Clients. Manche Clients begrenzen die Zahl der Tools, die ein MCP Server anbieten darf: Cursor bei rund 40, Windsurf bei 100. Für diese startet der Server mit `“args": ["--load-mode", "dynamic"] im selben Config-Block und zeigt dann drei Meta-Tools zum Suchen und Aufrufen statt aller 118. Dazwischen liegt ein lazy-Modus. Das passende Vorgehen erklärt der Guide zum Selective Tool Loading.

Unser Server ist unter Apache-2.0-Lizenz quelloffen und im offiziellen MCP-Registry gelistet. Die erfolgreiche Anbindung externer Elixir-Clients bestätigt unsere Entscheidung für offene Protokolle.

Wir freuen uns über Feedback zu den ersten Abfragen und neuen Erkenntnissen aus der Cloud-Inferenz.