Versatile AI Risk Assessment

KI-Bedrohungskatalog Anwendungs- und Integrationssicherheit Produktion

Unsicheres Tool-Design

Viele KI-Anwendungen handeln selbst, indem sie über angebundene Werkzeuge (Tools) E-Mails versenden oder Datenbanken abfragen. Sind diese Werkzeuge zu mächtig oder schlecht abgesichert, lösen Angreifer über das Modell nie vorgesehene Aktionen aus.

Stand: Oktober 2026 · Katalogversion 2026.10.24.2 · 5 Gegenmaßnahmen · 9 belegte Quellen

Beschreibung

Werkzeuge sind Funktionen oder Plugins, die ein KI-Modell aufrufen darf, um Aufgaben zu erledigen. Die Schwachstelle entsteht beim Entwurf: Ein Werkzeug erhält mehr Rechte als nötig (Überprivilegierung), prüft übergebene Eingaben nicht streng genug oder bietet unsichere Schnittstellen wie direkten Zugriff auf die Kommandozeile. Angreifer nutzen das aus, indem sie das Modell mit manipulierten Eingaben, etwa einer Prompt Injection (in verarbeitete Texte eingeschleuste Anweisungen), zu Werkzeugaufrufen bewegen. Das Werkzeug führt die Aktion aus, weil es dem Modell vertraut. Da Werkzeuge oft Zugriffe besitzen, die Nutzern direkt verwehrt sind, verschaffen sie Angreifern zusätzliche Rechte.

Mögliche Auswirkung

Angreifer lösen unautorisierte Aktionen mit unmittelbarer Wirkung aus: Sie lesen, verändern oder löschen Daten, versenden E-Mails, stoßen Buchungen an oder führen Code aus. Eine einzige manipulierte Eingabe wirkt so bis in angebundene Geschäftssysteme hinein. Betroffen sind Betrieb, Datenschutz und Haftung des Unternehmens, bei personenbezogenen Daten auch Pflichten nach der DSGVO.

Beispiel

Ein E-Mail-Assistent soll Posteingänge nur zusammenfassen, darf über sein Werkzeug aber auch Nachrichten versenden. Eine präparierte eingehende E-Mail weist das Modell an, vertrauliche Korrespondenz weiterzuleiten; das Werkzeug führt den Versand an die fremde Adresse aus.

Empfohlene Gegenmaßnahmen (5)

Vergleichen Sie Wirkung und Umsetzungsebene. Die ergänzende Einordnung und Begründung können Sie bei Bedarf aufklappen.

  • Prinzip der geringsten Rechte für Tools

    Technisch
    Wirkung
    Präventiv, Schadensbegrenzend
    Umsetzungsebene
    Anwendung, API & Agenten
    Einordnung und Begründung

    Ergänzende MaßnahmenartGovernance & Compliance

    Primär technisch: Maschinell erzwungene Identitäts-, Berechtigungs- oder Bereichsregeln begrenzen unzulässige Zugriffe und Aktionen; ergänzt durch Regeln und Aufsicht.

  • Strenge Eingabevalidierung in Tool-Implementierungen

    Technisch
    Wirkung
    Präventiv
    Umsetzungsebene
    Anwendung, API & Agenten
    Einordnung und Begründung

    Primär technisch: Systemseitige Prüf-, Transformations- oder Blockierregeln stoppen oder neutralisieren unzulässige Inhalte vor der Weiterverarbeitung.

  • Sandboxing und Isolation

    Technisch
    Wirkung
    Präventiv, Schadensbegrenzend
    Umsetzungsebene
    Anwendung, API & Agenten, Infrastruktur
    Einordnung und Begründung

    Primär technisch: Architektur- und Laufzeitgrenzen trennen Daten, Ausführung oder Mandanten und begrenzen die Fehlerausbreitung.

  • Human-in-the-loop bei sensiblen Operationen

    Organisatorisch & prozessual
    Wirkung
    Präventiv
    Umsetzungsebene
    Anwendung, API & Agenten, Nutzung & Betrieb
    Einordnung und Begründung

    Ergänzende MaßnahmenartMensch & Kompetenz

    Primär organisatorisch & prozessual: Ein verbindlicher Arbeitsablauf verlangt vor Nutzung oder Ausführung eine verantwortliche menschliche Entscheidung; ergänzt durch Fachwissen und Urteil.

  • Umfassendes Security-Review für Tools

    Organisatorisch & prozessual
    Wirkung
    Aufdeckend
    Umsetzungsebene
    Anwendung, API & Agenten, Organisation, Nutzung & Betrieb
    Einordnung und Begründung

    Ergänzende MaßnahmenartGovernance & Compliance

    Primär organisatorisch & prozessual: Ein geplanter, wiederholbarer Prüfablauf mit Zuständigkeit und Nachverfolgung erzeugt die Schutzwirkung; ergänzt durch Regeln und Aufsicht.

Standard-Zuordnungen

Verifizierte Fundstellen in OWASP, NIST AI RMF, MITRE ATLAS, EU AI Act und weiteren Rahmenwerken. Die Zuordnungen zeigen fachliche Bezüge. Sie belegen nicht, dass ein System die jeweiligen Anforderungen erfüllt.

Belegte Referenzen (9)

Jede Referenz nennt Rahmenwerk, Fundstelle und die herausgebende Organisation.

Pflichten der KI-Verordnung zu dieser Bedrohung

Die Pflichten aus dem Pflichtenkompass, deren Artikel der Katalog dieser Bedrohung zuordnet. Jede führt auf ihren Eintrag mit Kern, Handlungsschritt und Nachweis; ob sie Sie trifft, hängt von Rolle und Risikoklasse ab.

  • Risikomanagementsystem einrichten und betreiben Art. 9 · gilt ab Anhang III: 2. Dezember 2027 · Anhang I: 2. August 2028

    Gesetzliche Rollen: Anbieter, Produkthersteller. Klassen: Hochrisiko nach Anhang III, Hochrisiko als Produkt oder Sicherheitsbauteil.

    Der Verweis ist ein Prüfanlass. Ein Bedrohungstreffer allein begründet keine Anwendbarkeit.

  • Menschliche Aufsicht bei der Systemgestaltung berücksichtigen Art. 14 · gilt ab Anhang III: 2. Dezember 2027 · Anhang I: 2. August 2028

    Gesetzliche Rollen: Anbieter, Produkthersteller. Klassen: Hochrisiko nach Anhang III, Hochrisiko als Produkt oder Sicherheitsbauteil.

    Der Verweis ist ein Prüfanlass. Ein Bedrohungstreffer allein begründet keine Anwendbarkeit.

Alle 62 Pflichten nach Rolle, Risikoklasse und Frist im Pflichtenkompass

Begriffe auf dieser Seite

Fachbegriffe aus dem Glossar, die in diesem Eintrag vorkommen. Jeder Verweis führt zur vollständigen Erklärung.

Weitere Einträge aus der Themengruppe Anwendungs- und Integrationssicherheit.

Passende Anwendungsfälle

Die Liste zeigt, wo Sie diese Bedrohung prüfen, nicht wie hoch das Risiko ist.

Besonders wichtig bei:

  • KI-AgentEin Werkzeug des Agenten nimmt beliebige Eingaben an und prüft nicht, wer den Aufruf auslöst. So erreicht der Agent Daten und Funktionen, die mit seiner Aufgabe nichts zu tun haben.
  • Coding-AgentEin uneingeschränkter Terminalzugang erlaubt dem Agenten jeden Befehl, den auch die angemeldete Person ausführen darf. Fehlen eine abgeschottete Umgebung und eine Liste erlaubter Befehle, lässt sich ein Fehlgriff kaum begrenzen.

Bei 7 weiteren Anwendungsfällen hängt es vom Aufbau des Systems ab, etwa davon, ob es andere Programme oder Schnittstellen aufruft oder über das Model Context Protocol (MCP) angebunden ist. Diese Anwendungsfälle zeigen

Häufige Fragen

Worum geht es bei dieser Bedrohung?
Viele KI-Anwendungen handeln selbst, indem sie über angebundene Werkzeuge (Tools) E-Mails versenden oder Datenbanken abfragen. Sind diese Werkzeuge zu mächtig oder schlecht abgesichert, lösen Angreifer über das Modell nie vorgesehene Aktionen aus.
Welche Gegenmaßnahmen nennt der Katalog?
Der Katalog nennt 5 Gegenmaßnahmen, jede mit Maßnahmenart, Wirkung und Umsetzungsebene. Beispiele sind: Prinzip der geringsten Rechte für Tools, Strenge Eingabevalidierung in Tool-Implementierungen und Sandboxing und Isolation. Die Reihenfolge ist keine Priorisierung.
Welche Pflichten der KI-Verordnung können relevant sein?
Der Katalog ordnet diese Bedrohung Art. 9 und Art. 14 der EU-KI-Verordnung zu. Daraus folgen im Pflichtenkompass: Risikomanagementsystem einrichten und betreiben und Menschliche Aufsicht bei der Systemgestaltung berücksichtigen. Ob eine Pflicht gilt, entscheiden Rolle, Risikoklasse und Frist.

Diese Bedrohung im eigenen System bewerten

Die Live-Demo enthält alle 52 Bedrohungen dieses Katalogs sowie die Einordnung nach der EU-KI-Verordnung und die Datenschutzprüfung. Die kostenlosen Einzelmodule decken KI-Risiko, EU-KI-VO und DSGVO ab. Ohne Registrierung; die Bewertung läuft lokal in Ihrem Browser.

Diesen Eintrag zitieren

Für Berichte, Richtlinien oder interne Unterlagen; der Link führt direkt auf diesen Eintrag.

„Unsicheres Tool-Design“. Versatile AI Risk Assessment, KI-Bedrohungskatalog, Stand Oktober 2026.
https://www.versatile-ai-risk-assessment.com/wissensbasis/bedrohungen/unsicheres-tool-design/

← Zurück zum vollständigen Katalog