Kategorie: Erklärer

  • Open-Weight-Modelle dominieren 29 % des AI-Gateway-Traffics – Preise stabilisieren sich

    Open-Weight-Modelle dominieren 29 % des AI-Gateway-Traffics – Preise stabilisieren sich

    Laut Vercels AI-Gateway-Index vom Juli 2026 machten Open-Weight-Modelle 29 % des Gateway-Traffics aus – fast ein Drittel aller Produktions-KI-Anfragen läuft inzwischen über frei verfügbare Modelle wie Llama und Mistral. Gleichzeitig stiegen die Preise für Closed-Weight-Frontier-Modelle im Juni um 12 %, während günstigere Modelle den Rückgang ausglichen. Das Ergebnis: Der durchschnittliche Preis pro Token blieb stabil. Investitionen in KI wachsen weiter, doch Unternehmen werden strategischer im Modell-Mix.

    Quelle: Vercel AI Gateway

  • Algolia und MCP: Wie Sie in wenigen Minuten einen KI-fähigen MCP-Server für Ihre Suchindizes erstellen

    Algolia und MCP: Wie Sie in wenigen Minuten einen KI-fähigen MCP-Server für Ihre Suchindizes erstellen

    Sie betreiben eine technische Dokumentation, einen Blog oder einen E‑Commerce-Katalog mit Algolia als Such‑Backend. Ihre Daten sind sauber indexiert, die Suche funktioniert zuverlässig – aber immer dann, wenn ein KI‑Agent oder ein Sprachmodell auf diese Informationen zugreifen soll, müssen Sie eine separate Schnittstelle bauen, API‑Keys verwalten und Abfragen anpassen. Bislang war das so. Algolia hat vor Kurzem eine Funktion veröffentlicht, die diesen Aufwand reduziert: Sie verwandeln Ihren bestehenden Suchindex in einen vollwertigen MCP‑Server.

    Der Autor dieses Erfahrungsberichts, langjähriger Algolia‑Nutzer und Betreiber eines Blogs, stieß zufällig auf diese Möglichkeit. Er sprach mit Chuck Meyer, Developer Relations bei Algolia, über genau diesen Wunsch – und erfuhr, dass die Funktion bereits existiert. Folgt eine nüchterne Betrachtung, wie einfach die Einrichtung ist und welche konkreten Anwendungsfälle sich daraus ergeben.

    Was ist Algolia?

    Algolia ist eine Such‑as‑a‑Service‑Plattform. Sie erstellen einen oder mehrere Indizes, die die durchsuchbaren Inhalte repräsentieren: Text (Blogartikel, Dokumentation) oder Produktdaten (E‑Commerce). Über APIs, SDKs oder Plugins befüllen und aktualisieren Sie diesen Index, sobald sich Ihre lokalen Daten ändern. Das System ist schnell und lässt sich durch Einstellungen (Relevance‑Tuning, Facetten, Synonyme) an Ihre Anforderungen anpassen. Für einen einfachen Blog reichen oft wenige Zeilen JavaScript, um eine vollwertige Suche zu integrieren. Algolia ist der Motor, der Ihre Inhalte millisekundenschnell findbar macht.

    Was ist MCP und warum ist es nützlich?

    MCP steht für Model Context Protocol – ein Protokoll, das es KI‑Agenten (wie Claude, Cursor oder Google Gemini) ermöglicht, auf externe Werkzeuge und Datenquellen zuzugreifen. Wenn Sie einen MCP‑Server bereitstellen, kann ein Sprachmodell diesen Server ansprechen, um bestimmte Aktionen auszuführen: Suchen, APIs aufrufen, Daten zurückgeben. Der Server kümmert sich um Authentifizierung, Logik und die Formatierung der Antworten. Für eine Dokumentationsseite bedeutet das: Ein Nutzer kann in seinem AI‑Chat frei formulierte Fragen zu den Inhalten stellen, und der Agent ruft über den MCP‑Server die relevanten Suchergebnisse ab. Sie müssen keine komplexe Middleware schreiben.

    Der Autor nennt das Beispiel des Webflow‑MCP‑Servers, den er vor seiner Zeit bei Webflow kannte: Ein Agent konnte damit Webflow‑API‑Aufrufe tätigen, etwa „Welche Sites habe ich?“ und die Antworten in natürlicher Sprache zurückgeben. Dieses Prinzip lässt sich auf Algolia‑Indizes übertragen.

    Die Einrichtung: Fünf Minuten oder weniger

    Der Weg zum eigenen MCP‑Server ist kurz. Sie loggen sich in Ihr Algolia‑Dashboard ein und wählen die Anwendung aus, die einen oder mehrere Indizes enthält. Im Navigationsmenü klicken Sie auf „Generate AI“. Im Untermenü erscheint „MCP Servers / Public“. Dort finden Sie einen Button „Create Public MCP Server“.

    Nun wählen Sie die Indizes aus, die der Server verwenden soll, und vergeben einen Namen – der Autor vergab einen nichtssagenden Namen, aber das ist nebensächlich. Im nächsten Schritt legen Sie fest, welche Tools aktiviert werden sollen: Suche, Empfehlungen (sofern genutzt) und weitere. Der Autor aktivierte alle, weist aber darauf hin, nicht benötigte Tools zu deaktivieren, um Klarheit zu bewahren. Nach der Bestätigung erhalten Sie eine vollständige URL – die Adresse Ihres neuen MCP‑Servers. Fertig.

    Von dort folgen Sie dem gewohnten Prozess, um den MCP‑Server in Ihren AI‑Agenten zu integrieren. Der Autor testete es unter anderem in Cursor, indem er die URL in den Einstellungen für externe Tools hinzufügte. Keine zusätzliche Konfiguration, kein manuelles Mapping von API‑Endpunkten – der Server spricht sofort auf die vom Protokoll definierten Anfragen an.

    Externe Anwendung: Dokumentation für Ihre Nutzer

    Der erste große Anwendungsfall: Ihre öffentliche Dokumentation wird über den MCP‑Server für jeden KI‑Agenten nutzbar, der MCP unterstützt. Viele technische Produkte bieten das bereits an – auch Algolia selbst. Aber jetzt können Sie das Gleiche für Ihre eigenen Inhalte tun. Ein Entwickler, der in seinem Chat nach einer bestimmten Funktion sucht, bekommt präzise Antworten aus Ihrer Dokumentation, ohne die Website manuell durchsuchen zu müssen. Der Autor berichtet von einem Test mit dem Kommandozeilen‑Tool agy (basierend auf Googles Gemini): Die Frage „Suche in Rays MCP‑Server nach seiner Meinung zu React“ lieferte fast perfekt passende Ergebnisse – inklusive des erwarteten Kontexts.

    Interne Anwendung: Content‑Erstellung und Wissensmanagement

    Der zweite Use‑Case richtet sich an Content‑Creator, Redakteure und alle, die regelmäßig auf einen großen Bestand an bereits veröffentlichten Inhalten zurückgreifen müssen. Der Autor, selbst Betreiber eines Blogs, nutzt die Algolia‑Suche bereits, um schnell zu prüfen, ob er über ein Thema schon geschrieben hat. Mit dem MCP‑Server kann er darüber hinausgehende Fragen stellen: „Was empfehlen Sie für einen neuen Blogbeitrag basierend auf meinen bisherigen Artikeln?“ In einem Test mit Cursor schlug die Kombination aus Server und AI‑Agent tatsächlich den Beitrag vor, den er gerade schrieb – ein Zeichen dafür, dass die gelieferten Inhalte kontextuell relevant sind. Das eröffnet die Möglichkeit, bestehendes Wissen automatisiert in neue Inhalte einfließen zu lassen, Lücken zu identifizieren oder thematische Verknüpfungen herzustellen.

    Technische Details und Kosten

    Bemerkenswert ist, dass diese Funktion im Build‑Tier enthalten ist – dem kostenlosen Tarif von Algolia, der für viele kleinere und mittlere Projekte ausreicht. Der Autor betont, dass er die Grenzen des Free‑Tiers nie erreicht habe, obwohl er Algolia seit Jahren intensiv nutzt. Das spricht für ein großzügiges Kontingent. Die Einrichtung erfordert keinerlei zusätzliche Server‑Infrastruktur; der MCP‑Server wird vollständig von Algolia gehostet und über die generierte URL bereitgestellt. Alles, was Sie brauchen, ist ein Algolia‑Konto und ein Index mit Daten.

    Was das konkret bedeutet

    Die Integration von MCP‑Servern in Algolia zeigt, wie Plattformen ihre Leistungsfähigkeit öffnen, ohne den Nutzer mit Komplexität zu belasten. Statt einen eigenen Server aufzusetzen, Authentifizierungs‑Mechanismen zu implementieren und die MCP‑Spezifikation von Grund auf zu lernen, können Sie sich auf Ihre Inhalte konzentrieren. Die MCP‑Schnittstelle ist ein weiterer Kanal, über den Ihre Daten lebendig bleiben – nicht nur über die eigene Suchleiste, sondern auch über die Sprachmodelle, die Ihre Nutzer ohnehin verwenden.

    Der Autor resümiert, dass er die Funktion unterschätzt hatte – eine Fehleinschätzung, wie er zugibt. Für alle, die Algolia einsetzen und einen Schritt in Richtung KI‑gestützter Anwendungen gehen möchten, ist dieser MCP‑Server ein niedrigschwelliger Einstieg. Sie müssen kein Experte für maschinelles Lernen oder Server‑Architektur sein. Ein Klick, eine URL, und Ihr Index spricht mit der KI.

    Loggen Sie sich in Ihr Algolia‑Dashboard ein, suchen Sie den Menüpunkt „Generate AI“ und erstellen Sie Ihren ersten öffentlichen MCP‑Server. Dann integrieren Sie ihn in Cursor, Claude oder ein anderes Tool Ihrer Wahl. Die Anwendung, die sich daraus ergibt, mag je nach Kontext unterschiedlich sein – ob Sie Ihre Dokumentation für Endnutzer öffnen oder Ihr eigenes Redaktionssystem mit einer KI‑Unterstützung ausstatten. Die Grundlage ist in fünf Minuten gelegt.

    Quelle: raymondcamden.com

  • Die vier Reiter hinter tausenden Postgres-Ausfällen

    Die vier Reiter hinter tausenden Postgres-Ausfällen

    Du betreibst eine Webanwendung, alles läuft – bis die Datenbank nicht mehr reagiert. Kein SELECT, kein INSERT. Server hängt, Fehlerlogs laufen über. Wer eine PostgreSQL-Instanz betreut, kennt diese Momente. Sie haben oft vier Ursachen. Der Entwickler von pgrust, einer Neuimplementierung von Postgres in Rust, hat diese Problembereiche analysiert. Er beschreibt, warum sie zu Ausfällen führen – und wie sein Ansatz helfen könnte. Schauen wir uns die vier Punkte an.

    1. VACUUM und Transaction ID Wraparound – die stille Gefahr

    Wenn du in Postgres eine Zeile löschst, wird sie nicht sofort physisch entfernt. Postgres markiert sie als gelöscht – das ermöglicht Rollbacks. Die Bereinigung übernimmt ein Hintergrundprozess namens VACUUM. Er liest alle Daten und entfernt die markierten Zeilen. Das klingt harmlos, birgt aber zwei Risiken. Erstens: VACUUM frisst I/O. Es konkurriert mit deinen Abfragen um die Festplattenbandbreite. Stell dir vor, du liest ein Buch, während jemand neben dir Seiten herausreißt – so ähnlich fühlt es sich für die Datenbank an. Du musst VACUUM richtig einstellen: aggressiv genug, um mit gelöschten Zeilen Schritt zu halten, aber nicht so aggressiv, dass es Queries ausbremst. Eine knifflige Balance, besonders ohne dedizierten Datenbank-Admin.

    Das zweite Problem ist tückischer: Transaction ID Wraparound. Postgres vergibt pro Transaktion eine 32-Bit-ID – maximal vier Milliarden IDs. Sind alle verbraucht, müssen sie wiederverwendet werden. VACUUM markiert alte IDs, damit sie sicher recycelt werden. Hinkt VACUUM hinterher, schaltet Postgres die Datenbank komplett ab – sonst könnten Daten korrupt werden. Der Autor schätzt, dass dieser Mechanismus weltweit für tausende, wenn nicht zehntausende Ausfälle verantwortlich ist. pgrust plant zwei Lösungen: 64-Bit-Transaktions-IDs, die zwar Overhead pro Zeile bedeuten, aber den Wraparound praktisch auf unbestimmte Zeit verschieben. Außerdem wird eine Architektur ohne VACUUM diskutiert – ähnlich dem Undo-Log von Oracle. Der Ansatz ist vielversprechend, erfordert aber grundlegende Änderungen.

    2. Connection Limits und Query Parallelism – wenn die Türen zu bleiben

    Jede Postgres-Instanz hat eine Konfigurationsvariable für die maximale Anzahl gleichzeitiger Verbindungen. Wenn mehr Clients versuchen, sich zu verbinden, werden sie abgewiesen – die Datenbank ist nicht erreichbar. Simpel, aber die Falle lauert im Detail: Änderungen an diesem Grenzwert erfordern einen Neustart. Wer den Wert zu niedrig ansetzt, steht im Regen. Viele nutzen PgBouncer, einen Verbindungspooler, der das Problem mildert, aber nicht beseitigt. Warum ein Grenzwert? Der Grund liegt in der Prozess-Architektur von Postgres. Für jede neue Verbindung erzeugt Postgres einen Betriebssystem-Prozess. Prozesse sind teuer – sie brauchen CPU, Speicher und Zeit zum Starten. Das schränkt nicht nur die Parallelisierung zwischen Abfragen ein, sondern auch innerhalb einer einzelnen Abfrage. Denn wenn Postgres eine aufwendige Query parallel ausführen will, startet es ebenfalls mehrere Prozesse. Wegen der hohen Kosten tut es das nur bei wirklich langlaufenden Abfragen.

    Seit Jahren wird über eine Umstellung auf ein Thread-Modell diskutiert, aber die Änderung ist so tiefgreifend, dass kaum jemand sie wagt. pgrust wurde von Anfang an mit Threads konzipiert. Der Autor betont, dass die Prozess-Architektur der Sicherheit dient: Prozesse sind stärker isoliert als Threads. Ein Fehler in einem Prozess reißt die anderen nicht mit. pgrust setzt auf die Speichersicherheitsgarantien von Rust zur Compile-Zeit, sodass diese Isolation nicht nötig ist. Das verspricht schnellere Verbindungsaufnahmen und effizientere Parallelisierung – ohne lästige Grenzwerte und Umwege über PgBouncer.

    3. Bad Query Plans – wenn der Optimierer daneben liegt

    Postgres besitzt einen Planer für Abfragen. Er analysiert die SQL-Query, zieht Statistiken über die Tabellen heran und wählt aus Dutzenden Algorithmen den vermeintlich schnellsten aus. Meist funktioniert das gut. Wenn der Planer daneben liegt, dann richtig. Der Unterschied zwischen einem guten und einem schlechten Ausführungsplan kann den Faktor 60.000 ausmachen: eine Query, die normalerweise 10 Millisekunden braucht, läuft plötzlich 10 Minuten. Das ist bekannt. Noch ärgerlicher: Postgres bietet kaum Möglichkeiten, den Planer direkt zu lenken. Während andere Datenbanken wie MySQL Planner Hints unterstützen, mit denen du für einzelne Queries den Algorithmus vorgeben kannst, fehlt diese Funktion in Postgres komplett. Die einzige Stellschraube ist das globale Abschalten bestimmter Algorithmen – ein grobes Werkzeug.

    Der Autor von pgrust berichtet von einem früheren Arbeitgeber, bei dem sie in der gesamten Datenbank Nested-Loop-Joins deaktivieren mussten, weil Postgres sie ständig nutzte und alle Queries ausbremste. Grund war oft der Umgang mit JSON-Daten. Für pgrust schwebt dem Entwickler ein adaptiver Query Planer vor, der ständig die Ausführungszeiten überwacht. Wenn eine Query, die normalerweise 10ms braucht, plötzlich 10 Sekunden benötigt, soll pgrust automatisch erkennen, ob der Plan gewechselt hat oder die Statistiken veraltet sind, und ohne menschliches Eingreifen korrigieren. Klingt futuristisch, aber der Autor ist optimistisch, dass dies realisierbar ist – es fehlt nur die konkrete Umsetzung.

    4. JSON – scheinbarer Segen mit versteckten Fallstricken

    Postgres liebt und hasst JSON. Es ist nützlich, um unstrukturierte Daten zu speichern und flexibel abzufragen. Aber die Schattenseiten sind massiv. Das größte Problem: Postgres sammelt für JSON-Spalten keine vernünftigen Statistiken. Für normale Datentypen wie Integer oder Text erhebt es Histogramme, häufigste Werte und mehr. Bei JSON schätzt der Planer pauschal, dass ein Filter auf eine JSON-Eigenschaft nur 0,1 % der Zeilen trifft – ein fixer Wert, völlig unabhängig von den tatsächlichen Daten. Der tatsächliche Anteil kann bei 80 % oder bei 0,0001 % liegen. Diese Fehleinschätzung führt zu schlechten Abfrageplänen. Wer mit großen JSON-Spalten gearbeitet hat, kennt das Gefühl, wenn Abfragen plötzlich explodieren.

    Hinzu kommt, dass Postgres JSON nicht komprimiert. Werden in vielen Zeilen die gleichen Schlüssel und Werte verwendet, werden sie jedes Mal neu gespeichert. Das bläht die Datenbank auf. Der Autor von pgrust sieht zwei Ansatzpunkte: echte Statistiken für JSON-Spalten – das würde nach seiner Einschätzung 80 % der JSON-bedingten Probleme lindern. Es existieren bereits Patches, die in diese Richtung gehen; er möchte einen zur Serienreife bringen. Zweitens eine Wörterbuchkomprimierung (Dictionary Compression), um sich wiederholende JSON-Inhalte platzsparender abzulegen. Das könnte den Speicherverbrauch drastisch reduzieren und die I/O-Last verringern.

    Was bleibt – und was pgrust konkret bedeutet

    Die vier Punkte – VACUUM/Wraparound, Connection Limits, schlechte Query-Pläne und JSON – sind keine akademischen Probleme. Sie verursachen täglich Ausfälle in tausenden Unternehmen. Der Entwickler von pgrust hat sich vorgenommen, diese Schwachstellen mit einem technisch durchdachten Neuanfang zu adressieren. Der Fokus des Projekts liegt auf zwei Dingen: erstens Kompatibilität mit PostgreSQL – pgrust besteht bereits 96 % der offiziellen Regressionstests. Zweitens Stabilität und Fehlerbereinigung, damit die Datenbank ernsthaft eingesetzt werden kann. Erst danach sollen die architektonischen Verbesserungen kommen, beginnend mit den 64-Bit-Transaktions-IDs.

    Für dich als Betreiber einer Postgres-Installation bedeutet das: Solange pgrust nicht produktionsreif ist, solltest du die genannten Fallstricke aktiv managen. Überwache deine VACUUM-Aktivitäten, setze PgBouncer ein, um Connection Limits zu puffern, analysiere regelmäßig deine Abfragepläne und meide JSON, wo möglich, oder schaffe dir Monitoring für plötzliche Performance-Einbrüche. Die Arbeit an pgrust zeigt, dass die Probleme erkannt sind und Lösungen existieren.

    Quelle: malisper.me

  • Wie die Apple-Car-Forschung die M7- und M8-Chips antreibt

    Wie die Apple-Car-Forschung die M7- und M8-Chips antreibt

    Jahrelang an einem Projekt gearbeitet, das eingestellt wird. Zehn Milliarden Dollar, zehn Jahre Entwicklungszeit – dann der Stopp. So erging es dem Apple Car, 2024 offiziell begraben. Viele sahen einen Fehlschlag. Doch die Forschung war nicht umsonst. Die Erkenntnisse aus dem selbstfahrenden Auto fließen nun in die kommenden Prozessoren M7 und M8 ein – für KI-Leistung.

    Der Bericht stammt von AppleInsider, gestützt auf Bloomberg. Demnach konzentriert sich Apple bei den nächsten Chips vor allem auf KI-Unterstützung. Hier kommt das Apple Car ins Spiel. Tim Cook nannte autonome Systeme 2017 „die Mutter aller KI-Projekte“ – eines der schwierigsten Vorhaben. Apple hat nie einfach nur ein Auto gebaut, sondern die Grundlagen für maschinelles Lernen im großen Maßstab entwickelt.

    Ein Vergleich: Du kochst in einer Profiküche für ein ganzes Restaurant. Du eröffnest das Restaurant nicht, aber die Küche bleibt – Hochleistungsöfen, Kühltechnik, Organisation. Diese Infrastruktur nutzt du jetzt für deine Bäckerei. So ähnlich beim Apple Car. Die zehn Jahre Forschung an Sensoren, Entscheidungsalgorithmen und Echtzeit-Verarbeitung wandern direkt in die Chip-Designs für Mac und Apple Intelligence Server.

    Nach Einstellung des Car-Projekts gingen viele Mitarbeiter zu John Giannandrea, Leiter der KI-Abteilung. Kein Zufall. Apple sprach meist von „Machine Learning“ statt von AI, galt daher in der Branche oft als Nachzügler. Während Firmen wie OpenAI Milliarden in Rechenzentren pumpten und Geld verloren, verfolgte Apple eine andere Strategie.

    Diese Strategie heißt On-Device AI. Statt Rechenarbeit in die Cloud zu verlagern, läuft KI direkt auf dem Gerät. Dafür braucht es speziell optimierte Chips. M7 und M8 sollen das bieten – nicht nur schneller oder sparsamer, sondern speziell für neuronale Netze. Die Autoforschung brachte genau dieses Wissen: Wie verarbeitet man riesige Datenmengen in Echtzeit? Wie trifft man Entscheidungen unter Zeitdruck? Wie schützt man die Privatsphäre bei permanent scannenden Sensoren?

    Das klingt abstrakt, hat konkrete Auswirkungen. Mit einem M7-MacBook Pro wirst du vielleicht keine schnelleren Bootzeiten merken. Aber Siri versteht dich besser, Fotos werden automatisch bearbeitet, Spiele reagieren realistischer. Alles lokal, ohne Cloud-Umweg. Genau das war das Ziel des Apple Car: ein autonomes System, das in Sekundenbruchteilen Entscheidungen trifft, ohne auf eine Cloud-Verbindung angewiesen zu sein.

    Der erste Mac mit M7 soll das 16-Zoll MacBook Pro sein. Die Entwicklung zeigt einen grundlegenden Wandel. Die M6-Ära dauert laut Berichten nur sechs Monate – Apple treibt die KI-Optimierung voran. Ungewöhnlich für ein Unternehmen mit sonst gemächlichen Upgrade-Zyklen. Offenbar hat Apple aus dem Car-Projekt nicht nur Technologie, sondern auch Tempo mitgenommen.

    Intel, AMD und Qualcomm arbeiten ebenfalls an KI-Chips. Apples Vorteil liegt in der vertikalen Integration: Sie kontrollieren Hardware, Software und Dienste. Zehn Jahre Arbeit an einem der komplexesten KI-Probleme – dem autonomen Fahren – sind handfeste Ingenieursarbeit. Ein Kommentator bei AppleInsider: „Lesezeichen setzen und in fünf Jahren wiederkommen. Apple wird der König der On-Device-KI sein.“

    Für Nutzer bedeutet das: Die nächste Generation von Macs, iPads und iPhones wird nicht nur schneller sein, sondern Aufgaben vorausahnen, ohne dass du deine Privatsphäre opfern musst. Die Milliarden ins gescheiterte Apple Car waren kein Fehler, sondern eine Investition, die jetzt beginnt. Apple hat nicht das Auto gebaut, aber dafür das Gehirn des Autos in unsere Taschen gesteckt.

    Schlagzeilen über einen KI-Rückstand täuschen. Apple setzt nicht auf reine Cloud-Power, sondern auf Effizienz und Integration. Ob sich dieser Ansatz mit M7 und M8 auszahlt, wird sich zeigen. Die bisherigen Erkenntnisse aus dem Car-Projekt lassen erwarten, dass Apple seine Position im Bereich On-Device-KI stärken kann. Zehn Jahre Forschung an einem der schwierigsten KI-Vorhaben machen sich bemerkbar.

    Quelle: appleinsider.com

  • Sicherheitsrisiko bei KI-Agenten: 69% der Unternehmen teilen Zugangsdaten

    Sicherheitsrisiko bei KI-Agenten: 69% der Unternehmen teilen Zugangsdaten

    Stell dir vor, in einem großen Bürogebäude bekommen alle Mitarbeiter denselben Haustürschlüssel. Egal ob Praktikant, Abteilungsleiter oder externer Reinigungsdienst – jeder hat Zugang zu allen Räumen. Verliert eine Person den Schlüssel, ist das gesamte Gebäude gefährdet. Genau dieses Szenario spielt sich derzeit in der Welt der KI-Agenten ab. Die Zahlen sind deutlich.

    Eine aktuelle Studie von VentureBeat, basierend auf einer Umfrage unter 107 Unternehmen mit mehr als 100 Mitarbeitern, zeigt: 69% der Unternehmen betreiben ihre KI-Agenten mit gemeinsamen Zugangsdaten. Konkret bedeutet das: Ein einziger API-Key wird für mehrere Agenten verwendet. Wird einer dieser Agenten kompromittiert, profitiert der Angreifer sofort von den kumulierten Berechtigungen aller Workflows, die dieser Key berührt. Die forensische Spur endet auf der Ebene der Zugangsdaten, weil fünf Agenten auf einem Konto keine Aufzeichnung darüber hinterlassen, welcher Agent welche Aktion ausgeführt hat.

    Ein Problem, das Milliarden kostet

    Diese eine Zahl – 69% – erklärt, warum die größten Sicherheitsfirmen derzeit viel Geld investieren. Palo Alto Networks, CrowdStrike und Cisco haben im vergangenen Jahr zusammen mehr als 22 Milliarden Dollar investiert, um genau diese Sicherheitslücke zu schließen. Palo Alto Networks schloss am 11. Februar die Übernahme von CyberArk ab – für 21,1 Milliarden Dollar, der größte Deal in der Firmengeschichte. CrowdStrike kaufte die Runtime-Autorisierungsplattform SGNL für 740 Millionen Dollar und brachte bereits im Juni das erste Produkt daraus auf den Markt: Continuous Identity for AI Agents. Cisco gab Anfang Mai die Übernahme von Astrix Security bekannt, einem Spezialisten für nicht-menschliche Identitäten, für rund 400 Millionen Dollar.

    Für Sicherheitsverantwortliche ist diese Studie keine Trendlinie, sondern eine Frage, die im Vorstand diskutiert werden muss. Denn sie deckt ein Problem auf, das in den Marketing-Broschüren der großen Cloud-Anbieter nicht vorkommt. 54% der befragten Unternehmen hatten bereits einen Sicherheitsvorfall oder einen Beinahe-Vorfall mit KI-Agenten. 18% bestätigten einen tatsächlichen Vorfall, 36% entdeckten eine knappe Verfehlung, bevor es zum Bruch kam. Die Sicherheitsteams stoppen die meisten dieser Ereignisse am letzten Kontrollpunkt – aber die restlichen Daten zeigen, wie dünn diese Grenze ist.

    Wie Agenten heute ihre Identität verwalten

    Nur 32% der Unternehmen geben jedem KI-Agenten eine eigene, abgegrenzte und verwaltete Identität. 48% berichten, dass einige Agenten abgegrenzte Identitäten haben, viele aber immer noch gemeinsame Zugangsdaten verwenden. Weitere 32% geben an, dass Agenten größtenteils mit gemeinsamen API-Keys oder mit entliehenen menschlichen bzw. Servicekonto-Zugangsdaten laufen. Die Umfrage erlaubte Mehrfachnennungen, und 24 der 107 Befragten wählten mehrere Optionen – daher summieren sich die Kategorien auf 112%. Bereinigt nach Befragten zeigen 74 Organisationen, also 69%, Credential Sharing in mindestens einer Antwort.

    Diese eine Zahl erklärt, warum die Übernahmen genau auf diese Ebene zielen. Ein gemeinsamer Zugangsschlüssel verwandelt einen einzelnen kompromittierten Agenten in viele. CyberArks Forschung setzt die Anzahl der Maschinenidentitäten auf 82 pro menschlicher Identität in Unternehmen weltweit, wobei KI-Agenten die am schnellsten wachsende Kategorie sind. Cisco hat die gleiche Diagnose gestellt, als es Astrix kaufte, deren Gründer das Unternehmen um API-Keys, Servicekonten und OAuth-Tokens herum aufbauten. Ciscos Ankündigung nennt diese Zugangsdaten diejenigen, die KI-Agenten heute „nutzen (und missbrauchen)“, um Arbeiten in großem Maßstab auszuführen.

    Adam Meyers, Senior Vice President für Counter Adversary Operations bei CrowdStrike, beschrieb den Mechanismus in einem Interview mit VentureBeat direkt: Einige KI-Systeme hätten ihre eigenen Identitäten, in anderen Fällen würden Menschen ihre Identität an die KI verleihen, damit sie in ihrem Namen handeln könne – das mache das Wasser noch trüber und die Lage sehr komplex. Das Trübe sei der Punkt: Wenn die Identität geteilt wird, stirbt mit ihr die Zuordnung.

    Exposition wächst mit der Größe – Eindämmung nicht

    49% der Unternehmen setzen zur Laufzeit abgegrenzte Berechtigungen durch, und 47% überwachen und protokollieren Agentenaktivitäten – beides Maßnahmen, die Sicherheitsvorfälle reduzieren können. Nur 30% isolieren jedoch ihre risikoreichsten Agenten in einer Sandbox. Das ist die eine Kontrolle, die den Schaden begrenzt, wenn die ersten beiden versagen. Isolation ist das, was einen einzelnen kompromittierten Agenten davon abhält, ein unternehmensweites Ereignis zu werden. Unternehmen haben in Erkennung und Abwehr investiert, aber die Eindämmungsebene existiert kaum.

    Der schärfste Befund der Umfrage – und den kein Anbieterbericht zeigt – tritt zutage, wenn man die Ergebnisse nach Unternehmensgröße aufschlüsselt. Die Vorfallrate beträgt 49% für Unternehmen mit 101 bis 1.000 Mitarbeitern, steigt aber auf 63% für Unternehmen mit mehr als 1.000 Mitarbeitern. Die Sandbox-Isolation bewegt sich in die entgegengesetzte Richtung: von 35% auf 20% bei den größeren Unternehmen. Die Lücke zwischen Exposition und Eindämmung wächst von 7 Prozentpunkten bei kleinen Unternehmen auf 60 Prozentpunkte bei den größten. Größere Unternehmen betreiben mehr Agenten über mehr Systeme, was die Vorfälle nach oben treibt, während die Sandbox – das Engineering-Projekt, das sie eindämmen würde – nicht finanziert wird. Die Unternehmen mit den meisten Agenten haben die wenigste Isolation um sie herum.

    In der Obhut dessen, der das Modell ausgeliefert hat

    Die Modellanbieter selbst sind die Sicherheitsschicht: OpenAIs eingebaute Schutzmaßnahmen führen mit 51%, Google Cloud erreicht 36%, Microsoft Azures Purview und Copilot Studio DLP 35%, und Anthropics verwaltete Agentenkontrollen 29%. 82% der Befragten nennen eine anbietereigene oder Hyperscaler-Kontrolle als ihre einzige primäre Agentensicherheitsschicht. Die zweckgebauten Spezialisten liegen im niedrigen einstelligen Bereich: Palo Alto Networks‘ Prisma AIRS bei 7%, CrowdStrike bei 6%, Okta für KI-Agenten bei 4%. Microsoft Entra Agent ID ist die am weitesten verbreitete identitätsspezifische Kontrolle im Datensatz mit 13%, die einzige von einem Hyperscaler, und liegt dennoch außerhalb der Top-Vier. Nur 5% der Unternehmen betreiben überhaupt keine dedizierte Agenten-Toolbox.

    Die gebündelten Kontrollen führen, weil sie kostenlos mitgeliefert und standardmäßig aktiviert sind. Die meisten filtern Prompts und Outputs, aber sie geben einem Agenten keine eigene Identität und isolieren ihn nicht. Hyperscaler verkaufen zwar Produkte auf der Identitätsebene – Entra Agent ID ist mit 13% im Datensatz –, aber die Adoption bleibt niedrig. Die beiden Kontrollen, die die Vorfallszahlen am meisten beeinflussen – abgegrenzte Identität und Isolation – sind die beiden, die der Standard-Stack nicht enthält. Prompt- und Output-Filter bewerten, ob ein Aufruf bösartig aussieht. Das ist ein Absichtsproblem, und Absicht kann nicht auf der Sprachebene gelöst werden.

    Crowdstrikes CTO Elia Zaitsev zog die Grenze in einem Interview auf der RSAC 2026: „Das Beobachten tatsächlicher kinetischer Aktionen ist ein strukturiertes, lösbares Problem. Absicht ist es nicht.“ Der Falcon-Sensor von CrowdStrike durchläuft den Prozessbaum auf einem Endpunkt und verfolgt, was Agenten getan haben, nicht, was Agenten zu tun beabsichtigten. Eine abgegrenzte Identität und eine Isolationsgrenze geben diesem Sensor etwas, das er verfolgen kann, während ein gemeinsamer Zugangsschlüssel auf einer gebündelten Schutzmaßnahme dies nicht tut.

    Die Cloud-Sicherheit durchlief vor zehn Jahren denselben Zyklus, und Palo Alto Networks, CrowdStrike und Wiz bauen milliardenschwere Geschäfte auf den Lücken auf, die native Cloud-Kontrollen offen ließen. Die Agentensicherheit folgt demselben Pfad schneller. Ein falsch konfigurierter Speicher-Bucket lag offen, bis ein Mensch ihn bemerkte. Ein falsch konfigurierter Agent nutzt seine eigene Überberechtigung bei jedem Durchlauf aus, und kein Mensch sieht zu, wenn er das tut. Merritt Baer, Chief Security Officer bei Enkrypt AI und ehemaliger stellvertretender CISO bei AWS, sagte VentureBeat, dass die Standardebene dünner sei, als Unternehmen annähmen: „Unternehmen glauben, sie hätten KI-Anbieter ‚genehmigt‘, aber in Wirklichkeit haben sie eine Schnittstelle genehmigt, nicht das zugrundeliegende System. Die wahren Abhängigkeiten liegen ein oder zwei Ebenen tiefer, und genau diese versagen unter Belastung.“

    Zufrieden, aber nicht überzeugt – und schon auf dem Weg zum Einkauf

    Hier ist der Widerspruch, der eine Keynote-Folie wert ist: Unternehmen bewerten ihre Agentensicherheits-Toolbox mit 4,2 von 5 Punkten, das Preis-Leistungs-Verhältnis mit 4,1, die Implementierungsfreundlichkeit mit 3,9. Diese Werte würden die meisten SaaS-Anbieter neidisch machen. Nur 35% glauben, dass ihre KI-gestützten Abwehrmaßnahmen den KI-gestützten Angreifern voraus sind. 32% sehen es als ungefähr ausgeglichen. 21% sagen, die Angreifer seien voraus, und weitere 21% halten es für zu früh, um das zu sagen. Das zeigt: Unternehmen vertrauen ihrer Toolbox mehr als den Ergebnissen, die sie liefert.

    Die Budgets bestätigen das: 46% der Unternehmen weisen 6 bis 10% ihres Sicherheitsbudgets für Agentensicherheit aus, ein volles Drittel gibt 5% oder weniger aus. Die Hälfte der Stichprobe hatte bereits einen Vorfall oder Beinahe-Vorfall, aber die Finanzierung entspricht nicht der Exposition. 59% planen, innerhalb von 12 Monaten Agentensicherheits-Toolbox zu übernehmen, zu ergänzen oder auszutauschen – und 29% wollen noch in diesem Quartal handeln. OpenAI führt bei der zukünftigen Nachfrage mit 34%, gefolgt von Google (30%), Anthropic (29%) und Azure (25%). Die spezialisierten Anbieter ziehen mehr Interesse auf sich, als ihr aktueller einstelliger Fußabdruck vermuten lässt. Zufriedene Kunden stellen nicht so schnell um, es sei denn, sie wissen, dass der Stapel, den sie gerade verwenden, nur provisorisch ist.

    Drei Schritte für Sicherheitsverantwortliche

    Erstens: Noch in diesem Quartal eine Bestandsaufnahme aller Zugangsdaten jedes Agenten durchführen. Kartieren, welche Agenten Zugangsdaten mit anderen Agenten teilen und welche auf entliehenen menschlichen oder Servicekonto-Identitäten laufen. Das Ziel ist nicht ein Zugangsschlüssel pro Agent – Agenten, die mehrere Systeme berühren, brauchen mehrere abgegrenzte Identitäten. Das Ziel ist null gemeinsame Zugangsdaten zwischen Agenten und null entliehene menschliche Identitäten. 13% der befragten Unternehmen nutzen bereits Microsoft Entra Agent ID. Okta für KI-Agenten und die Spezialisten für nicht-menschliche Identitäten bieten Äquivalente. Geteilte und entliehene Zugangsdaten sind das Erste, was eliminiert werden muss.

    Zweitens: Die risikoreichsten Agenten zuerst isolieren. Isolation ist die am wenigsten angewandte Kontrolle (30%) und die einzige, die den Schaden begrenzt, wenn die Prävention versagt. Die Agenten nach der Sensibilität dessen, was sie berühren, einordnen und die Spitze der Liste isolieren. Bei Unternehmen mit mehr als 1.000 Mitarbeitern, wo die Isolation auf 20% fällt, ist dies die einzelne Maßnahme mit der höchsten Rendite im Datensatz. Sandboxing erfordert nicht den Austausch des Agenten oder der Plattform. Es erfordert eine politische Entscheidung und eine Isolationsschicht.

    Drittens: Das Budget an die Vorfallrate anpassen. Ein Drittel der Unternehmen finanziert die Agentensicherheit mit 5% oder weniger des Sicherheitsbudgets, obwohl mehr als die Hälfte bereits Vorfälle hatte. Die Daten zeigen: Je mehr Agenten ein Unternehmen einsetzt, desto höher die Vorfallrate und desto geringer die Isolation. Die Lösung ist nicht nur Technik, sondern auch Priorisierung im Budget. Die drei Milliardenübernahmen der letzten zwölf Monate zeigen die Richtung an: Wer jetzt investiert, kann die Lücke schließen, bevor sie zum geschäftskritischen Problem wird.

    Die Parallele zur Cloud-Sicherheit vor zehn Jahren ist deutlich. Damals wie heute begannen Unternehmen mit den mitgelieferten Standardkontrollen, stellten aber schnell fest, dass diese nicht ausreichen, sobald die Nutzung skaliert. Die Firmen, die früh in dedizierte Identitäts- und Isolationslösungen investierten, hatten am Ende weniger Vorfälle und geringere Schäden. Für KI-Agenten gilt das Gleiche – nur dass die Geschwindigkeit, mit der sich die Bedrohung entwickelt, deutlich höher ist. Jetzt zu handeln vermeidet Altlasten. Wer wartet, riskiert die Zugangsdaten seiner gesamten Agentenflotte.

    Quelle: venturebeat.com