In Entwicklungsteams entstehen derzeit Abhängigkeiten, die in klassischen Software-Inventaren nicht auftauchen: KI-Modelle, Werkzeuge auf Basis des Model Context Protocol (MCP, eine Schnittstelle, über die Sprachmodelle externe Tools und Datenquellen ansprechen) sowie autonome Agenten, die Aufgaben eigenständig abarbeiten. Laut einer aktuellen Darstellung gelangen diese Bausteine häufig in den produktiven Betrieb, ohne dass die Security-Teams davon wissen.

Genau an dieser Stelle setzt das AI Bill of Materials an, kurz AI-BOM. Der Begriff lehnt sich an die Software-Stückliste an: Statt nur Bibliotheken und Versionen zu erfassen, dokumentiert ein AI-BOM den Bestand an KI-Komponenten über alle genutzten Clouds hinweg. Jeder Komponente wird eine verantwortliche Person zugeordnet, und der Bestand lässt sich für Audits nachweisen.

Warum ein Inventar der erste Schritt ist

Transparenz ist die Voraussetzung für jede weitere Kontrolle. Wer nicht weiß, welches Modell in welcher Anwendung antwortet, welches MCP-Tool auf welche Datenquelle zugreift und welcher Agent im Hintergrund Aufgaben ausführt, kann weder Risiken bewerten noch im Ernstfall schnell abschalten.

Ein AI-BOM beantwortet in der Praxis vor allem drei Fragen:

  • Was läuft? Welche Modelle, Tools und Agenten sind im Einsatz – inklusive der Instanzen, die in Nebenprojekten oder Testumgebungen entstanden sind.
  • Wer ist zuständig? Eine benannte verantwortliche Person pro Komponente verhindert, dass Zuständigkeiten nach dem Projektende verwaisen.
  • Wie belegen wir das? Der dokumentierte Bestand dient als Nachweis gegenüber internen Revisionen und externen Prüfungen.

Für Unternehmen mit verteilter Cloud-Landschaft ist der Punkt „über alle Clouds hinweg“ der entscheidende. KI-Funktionen entstehen selten an einer Stelle: Ein Modell läuft beim Anbieter A, ein Vektorspeicher bei Anbieter B, der Agent auf einer eigenen Instanz. Ohne übergreifendes Inventar bleibt jedes Teilbild unvollständig.

Zugriffsrechte: Plattformen ziehen nach

Parallel zur Inventarisierung verschiebt sich die zweite Kontrollebene: die Rechtevergabe auf dem Endgerät. Apple verschärft die Kontrollen für den Vollzugriff auf die Festplatte des Mac, um die Sicherheit gegenüber KI-Agenten zu erhöhen. Hintergrund ist die Beobachtung, dass viele Nutzerinnen und Nutzer Zugriffsanfragen zu leichtfertig bestätigen, obwohl die Risiken wachsen.

Das ist mehr als eine Detailänderung in einem Betriebssystem. Ein Agent, der vollen Dateisystemzugriff besitzt, kann Inhalte lesen, kombinieren und weitergeben, die nie für ihn vorgesehen waren. Wenn Plattformbetreiber die Hürden für solche Freigaben anheben, verändert das die Annahmen, auf denen lokal laufende KI-Werkzeuge aufsetzen.

Für Projektverantwortliche heißt das: Berechtigungen sind kein einmaliger Installationsschritt, sondern ein Betriebsthema. Was heute per Klick erteilt wird, kann nach einem Plattform-Update erneut und differenzierter abgefragt werden – mit Auswirkungen auf Rollout-Pläne und Support-Aufwand.

Autonomie ohne klare Grenzen

Wie eigenständig Agenten agieren können, zeigt eine Episode rund um das Werkzeug Openclaw. Ein Nutzer berichtete auf X, dass sich zwei Openclaw-Agenten während seiner längeren Abwesenheit abstimmten, um herauszufinden, ob ihm etwas zugestoßen sein könnte. Sechs Stunden lang beschäftigten sich die Tools mit dieser Frage – der Nutzer schlief lediglich.

Die Geschichte wirkt kurios, illustriert aber einen realen Mechanismus. Agenten verfolgen Ziele, interpretieren Kontext und koordinieren sich untereinander. Fehlt eine klare Abgrenzung, was sie tun dürfen, wie lange sie aktiv bleiben und wann sie Rückfragen stellen müssen, entstehen Aktivitäten ohne Auftrag. In diesem Fall blieb es bei verschwendeter Rechenzeit. In einer Umgebung mit Schreibrechten, API-Zugängen oder Kundendaten wäre dasselbe Verhalten deutlich unangenehmer.

Die gemeinsame Linie der drei Entwicklungen

Inventar, Rechtevergabe und Agentenverhalten sind drei Perspektiven auf dieselbe Lücke: KI-Komponenten verbreiten sich schneller, als Organisationen sie erfassen und begrenzen. Das AI-BOM adressiert die Sichtbarkeit, die verschärften Plattformkontrollen die Zugriffsebene, der Openclaw-Vorfall die Verhaltensebene.

Wichtig ist die Einordnung: Die Quellen beschreiben unterschiedliche Reifegrade. Das AI-BOM ist ein organisatorisches Konzept, das ein Unternehmen selbst einführen muss. Die Apple-Änderung ist eine Plattformmaßnahme, auf die Teams reagieren. Der Openclaw-Fall ist ein Einzelbericht eines Nutzers und kein systematischer Befund – er taugt als Anschauung, nicht als Beleg für eine Häufigkeit.

Was Teams konkret angehen können

  • Bestand aufnehmen: Alle eingesetzten Modelle, MCP-Tools und Agenten erfassen, auch die in Pilotprojekten entstandenen.
  • Verantwortung zuordnen: Pro Komponente eine benannte Person, die über Updates, Abschaltung und Zugriffsrechte entscheidet.
  • Rechte minimieren: Agenten nur die Zugriffe geben, die für die konkrete Aufgabe nötig sind – Vollzugriff auf Dateisysteme als Ausnahme behandeln, nicht als Standard.
  • Laufzeiten begrenzen: Klare Abbruchkriterien und Zeitfenster definieren, damit Agenten nicht unbemerkt über Stunden aktiv bleiben.
  • Nachweisfähigkeit herstellen: Das Inventar so führen, dass es bei einem Audit ohne Zusatzrecherche vorgelegt werden kann.

Einordnung für Web- und Softwareprojekte

Wer KI-Funktionen in Kundenprojekte integriert, sollte das Inventar der KI-Komponenten von Beginn an mitführen und nicht erst beim ersten Audit nachziehen – der Aufwand ist zum Projektstart deutlich geringer. Rechtevergabe und Agentenautonomie gehören in die Architekturentscheidung, nicht in die Betriebsphase: Welche Datenquellen ein Agent sehen darf und wann er stoppt, lässt sich im Entwurf sauber festlegen, im laufenden System nur mühsam korrigieren. Für Angebote und Wartungsverträge heißt das, Governance-Aufwand als eigenen Posten zu führen statt ihn unter „Integration“ zu verbuchen.

Quellen