Die Sicherheit von KI-Agenten wird zur unternehmerischen Entscheidung, sobald ein Assistent Datensätze ändern, Nachrichten versenden oder Arbeit in einer anderen Anwendung auslösen kann. Eine überzeugende Vorführung zeigt, ob der Agent eine Aufgabe erledigen kann. Sie belegt jedoch weder, auf wessen Informationen er zugreifen darf, noch welche Aktionen erlaubt sind oder wie Ihr Team nach einem Fehler weiterarbeitet.
Sichern Sie einen KI-Agenten durch begrenzten Datenzugriff und eingeschränkte Aktionen, durch Autorisierung in den angebundenen Anwendungen und durch informierte Freigaben für folgenreiche Änderungen. Prüfen Sie diese Grenzen mit realistischen Fehlern und bösartigen Eingaben, bevor Sie Zugriffe erweitern. Ein besserer Prompt allein bietet diese Absicherung nicht.
Für britische Teams, die eine Integration beauftragen, lautet die entscheidende Frage: Was darf der Agent tun, wenn seine Einschätzung falsch ist? Dieser Leitfaden schlägt einen praktischen Umfang für einen kontrollierten Pilotbetrieb vor und beschreibt anzufordernde Lieferantennachweise sowie die Kosten der Wirtschaftlichkeitsrechnung. Er verspricht weder ein unangreifbares System noch beschreibt er die Installation eines bestimmten Kunden.
Sicherheit von KI-Agenten an einer Geschäftsaufgabe ausrichten
Beginnen Sie mit einem eng begrenzten Ablauf, beispielsweise dem Entwurf einer Supportantwort oder einem Änderungsvorschlag für das CRM. Halten Sie Quelldatensätze, vorgesehene Nutzer und Zielsystem fest. Trennen Sie Lesen, Entwerfen und Ausführen: Der Zugriff auf einen Kundendatensatz muss keine Exportberechtigung beinhalten, und eine vorbereitete Antwort muss nicht automatisch versendet werden dürfen.
Vereinbaren Sie, was außerhalb des Pilotbetriebs bleibt. Erstattungen, Änderungen von Kontoberechtigungen und Massenexporte verdienen beispielsweise eigene Entscheidungen. Ein Anbieter sollte zeigen können, wo diese Einschränkungen durchgesetzt werden. Ein Satz im Systemprompt ist eine nützliche Vorgabe, aber kein Nachweis dafür, dass eine angebundene API eine unbefugte Anfrage ablehnt.
Benennen Sie eine verantwortliche Person, die über vertretbare Ausnahmen entscheidet. Fehlt sie, übernehmen technische Teams möglicherweise unbemerkt Geschäftsentscheidungen über Kundenkommunikation oder Datensatzänderungen. Ein brauchbares Briefing beschreibt ein autorisiertes Ergebnis mit klaren Grenzen, statt einen Agenten zu verlangen, der jedes verfügbare Werkzeug nutzen kann.
Eingehende Inhalte als Informationen statt als Anweisungen behandeln
Die OWASP-Leitlinie zu Prompt Injection unterscheidet direkte Manipulation durch Prompts von indirekter Manipulation über externe Materialien wie Dateien und Websites. Sie warnt außerdem davor, dass Retrieval und Fine-Tuning diese Schwachstelle nicht vollständig beseitigen. Durch die Anbindung an Unternehmensdokumente wird daher nicht jeder abgerufene Satz vertrauenswürdig.
Stellen Sie sich eine hypothetische Support-E-Mail vor, die den Assistenten auffordert, Daten eines unbeteiligten Kunden in seine Antwort zu kopieren. Die E-Mail ist zu bewertender Inhalt, keine Erlaubnis zur Zugriffserweiterung. Entscheidend ist, ob die umgebende Anwendung die versuchte Offenlegung verhindert, selbst wenn das Modell die Anweisung befolgt. Prüfen Sie Anhänge, Suchergebnisse und Werkzeugantworten nach demselben Prinzip.
Kennzeichnen Sie externe Inhalte und validieren Sie vorgeschlagene Ausgaben, verkaufen Sie diese Maßnahmen aber nicht als vollständige Abwehr. Wir empfehlen eine Integration, bei der eine irreführende Antwort nur begrenzte Handlungsmacht hat. Schlägt das Modell eine ungeeignete Aktion vor, muss vor jeder Änderung im Geschäftssystem eine unabhängige Zugriffsprüfung erfolgen.
Berechtigungen an Nutzer und Datensatz binden
Die angebundene Anwendung sollte prüfen, wer anfragt und welchen Datensatz die Anfrage betrifft. Ein Agent, der für einen Supportmitarbeiter handelt, sollte nicht automatisch Administratorrechte erhalten. Legen Sie fest, ob eine Dienstidentität notwendig ist, was sie lesen oder ändern darf und wie die Integration den Berechtigungsumfang des auslösenden Nutzers erhält.
Die OWASP-Leitlinie zu übermäßiger Handlungsmacht empfiehlt minimale Funktionen und Rechte, Ausführung im Nutzerkontext und nachgelagerte Autorisierung. Sie benennt übermäßige Funktionalität, Berechtigungen und Autonomie als eigenständige Ursachen schädlicher Aktionen. Ein nur lesender Konnektor und ein eng berechtigtes Konto adressieren unterschiedliche Teile dieses Problems.
Testen Sie mit Konten unterschiedlicher Zuständigkeit. Versuchen Sie, Unterlagen eines anderen Teams zu lesen, ein geschütztes Feld zu ändern und einen Export außerhalb des genehmigten Umfangs anzufordern. Dokumentieren Sie die tatsächliche Ablehnung durch die Anwendung. Eine erfolgreiche Standardvorführung mit einem Administratorkonto belegt nicht, dass gewöhnliche Nutzer von unzulässigen Informationen getrennt bleiben.
Ein Aktionsgateway zwischen Vorschlag und Ausführung setzen
Ein Aktionsgateway ist Anwendungscode, der einen vorgeschlagenen Vorgang vor dem Aufruf des Zielsystems prüft. Bei einem CRM-Pilotprojekt könnte er ausschließlich freigegebene Datensatzkennungen und erlaubte Felder akzeptieren. Lehnen Sie unbekannte Vorgänge und nicht unterstützte Werte ab. Bewahren Sie Zugangsdaten in der kontrollierten Umgebung des Konnektors auf, statt Geheimnisse in für das Modell sichtbare Anweisungen einzufügen.
Bevorzugen Sie konkrete Vorgänge, etwa einen Notizvorschlag, gegenüber einem allgemeinen Werkzeug für beliebige Befehle oder Zieladressen. Eine kleinere Schnittstelle lässt sich leichter untersuchen und testen. Sie liefert dem Unternehmen auch eine konkrete Funktionsliste, die bei einer Erweiterung des Pilotbetriebs genehmigt werden kann.
| Fähigkeit | Anfängliche Pilotgrenze | Anzufordernder Nachweis |
|---|---|---|
| Datensatz lesen | Nur für den Nutzer autorisierte Datensätze | Kontenübergreifender Zugriff wird abgelehnt |
| Nachricht entwerfen | Kein automatischer Versand | Entwurf bleibt prüfbar |
| Feld ändern | Freigegebene Felder und Werte | Ungültige Änderungen werden abgelehnt |
| Informationen exportieren | Ohne gesonderten Umfang deaktiviert | Nicht genehmigte Ziele werden blockiert |
Diese Matrix ist ein vorgeschlagener Ausgangspunkt, keine allgemeingültige Richtlinie. Passen Sie Grenzen an Arbeitsablauf und Fehlerfolgen an. Berücksichtigen Sie übliche Anwendungskontrollen: Auch eine Agentenintegration braucht verlässliche Authentifizierung, validierte Eingaben und eine Verbindung zum Zielsystem, die sich nach Störungen wiederherstellen lässt.
Den Vorschlag über die Kontrollgrenze verfolgen
Das Diagramm trennt den Modellvorschlag von der Ausführungsentscheidung der Anwendung. Inhalte können den vorgeschlagenen Vorgang beeinflussen, doch das Gateway prüft Identität, Datensatzumfang und erlaubte Änderungen unabhängig davon. Eine folgenreiche Aktion wartet zusätzlich auf die Freigabe des endgültigen Vorgangs. Anfragen außerhalb der Richtlinie werden abgelehnt, statt unbemerkt zusätzliche Befugnisse zu erhalten.
Freigaben zu echten Entscheidungen machen
Eine Freigabeansicht sollte Aktion, Ziel und wesentliche Änderung zeigen. Bei einer ausgehenden Nachricht müssen Empfänger und endgültiger Text sichtbar sein. Bei einer Datensatzänderung gehören bisheriger Wert und vorgeschlagener Ersatz dazu. Wer eine unerklärte Anweisung freigeben soll, erhält Verantwortung ohne die Informationen, die für ihre Ausübung erforderlich sind.
Binden Sie die Freigabe an den tatsächlich ausgeführten Vorgang. Ändern sich Ziel, Inhalt oder relevanter Datensatzzustand, verlangen Sie nach der vereinbarten Richtlinie eine neue Entscheidung. Andernfalls genehmigt eine Person eine Version, während die Software eine andere ausführt. Nehmen Sie Ablauf und Widerruf einer Freigabe in die Abnahmetests auf, statt sie als reine Oberflächendetails zu behandeln.
Machen Sie nicht jeden belanglosen Vorgang zur Freigabeaufgabe. Dadurch entsteht eine Warteschlange, die Menschen irgendwann nur noch wegklicken. Vereinbaren Sie, welche Aktionen geprüft werden müssen, welche innerhalb einer bestehenden Richtlinie laufen dürfen und welche gesperrt bleiben. Messen Sie, ob Prüfer die Arbeit verstehen und erledigen können, auch bei hoher Auslastung oder Abwesenheit der üblichen freigebenden Person.
Fehlerpfade vor einer Zugriffserweiterung testen
Erstellen Sie eine Evaluationssammlung aus repräsentativen, anonymisierten Aufgaben. Berücksichtigen Sie fehlende Felder, widersprüchliche Datensätze, nicht unterstützte Anhänge und Versuche, die Aufgabe umzulenken. Halten Sie einige Beispiele vom Material zur Systemanpassung getrennt. Ziel ist es, Grenzen und brauchbare Ergebnisse zu testen, statt eine Vorführung zu belohnen, die ihre Beispiele auswendig kennt.
Prüfen Sie den gesamten Ablauf. Unterbrechen Sie die Zielverbindung, wiederholen Sie eine Anfrage nach einer Zeitüberschreitung, entziehen Sie einem Nutzer Rechte und ändern Sie einen Datensatz während einer ausstehenden Freigabe. Kontrollieren Sie, ob der Agent einen wahrheitsgemäßen Status meldet und ob Mitarbeiter ohne doppelte Änderungen weiterarbeiten können. Eine höfliche Ablehnung reicht nicht, wenn ein Werkzeug die verbotene Aktion bereits ausgeführt hat.
Verlangen Sie Nachweise, die jeden Test mit erwartetem Ergebnis, tatsächlichem Anwendungsverhalten und einer für die Behebung verantwortlichen Person verbinden. Benennen Sie offene Einschränkungen klar. Wiederholen Sie relevante Tests nach Änderungen an Prompts, Modellen, Werkzeugen oder Berechtigungen. Ein Pilotbetrieb sollte die zulässigen Betriebsbedingungen bestimmen, einschließlich der Bedingungen, unter denen der Ablauf stoppen muss.
Einen nachvollziehbaren Abnahmenachweis verlangen
Ein brauchbarer Abnahmenachweis verbindet eine versuchte Aktion mit einem sichtbaren Ergebnis im Zielsystem, statt sich auf die Erklärung des Agenten zu verlassen. Beispielsweise kann ein Test absichtlich eine Änderung an einem Datensatz außerhalb des Nutzerumfangs anfordern. Erwartet wird eine Ablehnung ohne Änderung im Zielsystem. Bewahren Sie relevante Kennungen auf, damit jemand anderes als die vorführende Person dieses Ergebnis prüfen kann.
| Testbedingung | Erwarteter Nachweis | Grund, die Erweiterung zu stoppen |
|---|---|---|
| Unbefugter Datensatz | Zugriff abgelehnt, keine Datensatzänderung | Konnektor umgeht den Nutzerumfang |
| Nach Freigabe geänderter Entwurf | Neue Freigabe vor Ausführung erforderlich | Andere Aktion nutzt frühere Freigabe |
| Zeitüberschreitung nach Annahme einer Änderung | Abgeglichenes Ergebnis ohne Doppeländerung | Wiederholung erzeugt zusätzliche Arbeit |
| Stopp bei vorgemerkten Aktionen | Ausstehende Aktionen bleiben unausgeführt | Hintergrundprozess arbeitet nach dem Stopp weiter |
Vereinbaren Sie vor dem Pilotbetrieb, wie das Team diese Ergebnisse nachweist. Nutzen Sie möglichst eine Testumgebung und unkritische Beispiele. Ein fehlgeschlagener Test sollte zu einer dokumentierten Einschränkung oder Korrektur führen, gefolgt von einer erneuten Prüfung des betroffenen Verhaltens. Verstecken Sie eine verletzte Grenze nicht in einer allgemeinen Erfolgsquote.
Nützliche Prüfprotokolle und eine wirksame Stoppfunktion vorsehen
Protokollieren Sie auslösende Identität, angeforderten Vorgang, Autorisierungsergebnis, relevante Freigabe und Bestätigung des Zielsystems. Verwenden Sie stabile Kennungen, damit Betreiber dieselbe Aufgabe über Warteschlangen und Konnektoren verfolgen können. Kopieren Sie nicht wahllos vollständige Dokumente, Zugangsdaten oder private Gespräche in Diagnoseprotokolle. Legen Sie fest, wer Protokolle einsehen darf und wie lange sie benötigt werden.
Ermöglichen Sie das Stoppen neuer Aktionen, ohne ausstehende Arbeit zu verlieren. Entscheiden Sie, ob eine Pause einen Ablauf, einen Konnektor oder sämtliche Agentenvorgänge betrifft. Testen Sie, ob die Stoppfunktion die Ausführung tatsächlich verhindert, einschließlich vorgemerkter Anfragen. Eine beruhigende Anzeige im Dashboard reicht nicht, wenn ein Hintergrundprozess weiterhin Datensätze ändert.
Schreiben Sie ein Wiederherstellungsverfahren, das Zuständigkeit für Untersuchungen, Auffinden betroffener Datensätze und umkehrbare Änderungen benennt. Manche Nachrichten lassen sich nicht zurückrufen; Prävention und Prüfung zählen daher ebenso wie Rückabwicklung. Üben Sie das Verfahren mit den künftigen Betreibern, statt die Übergabedokumentation als letzte technische Lieferung zu behandeln.
Kontrollen, Tests und laufenden Betrieb budgetieren
Verlangen Sie ein Angebot in GBP mit klarem Umfang und getrennten Positionen für Analyse, Konnektoren, Berechtigungsdurchsetzung, Freigabeoberflächen, Evaluation und Übergabe. Dieser Artikel nennt keine allgemeine Preisspanne: Der Aufwand hängt von Anwendungen, Zugriffsmodell und Fehlerfolgen ab. Ein Angebot für eine Chatvorführung ist nicht mit einem Angebot für einen überwachten produktiven Ablauf vergleichbar.
Laufende Kosten umfassen Modellnutzung, Hosting, Überwachung, menschliche Prüfung sowie Pflege der Konnektoren und Evaluationssammlung. Fragen Sie, wer bei geänderten Zugriffsrechten oder verändertem Verhalten der Ziel-API reagiert. Prüfen Sie aktuelle Anbieterpreise anhand der tatsächlichen Abrechnungseinheiten, bevor Sie Nutzungskosten schätzen. Ein Sicherheitskonzept lässt sich nicht allein anhand eines Tokenpreises kalkulieren.
Bewerten Sie Nutzen anhand abgeschlossener Arbeit nach Prüfung und Nachbesserung, nicht anhand generierter Antworten. Frei werdende Mitarbeiterkapazität wird nicht automatisch zur finanziellen Einsparung. Berücksichtigen Sie Ausnahmebearbeitung und die Kosten eines verfügbaren Ersatzverfahrens. Ein kleinerer, nur lesender Pilotbetrieb kann der sinnvollere Kauf sein, wenn Schreibzugriff mehr Aufsicht erfordert, als die Aufgabe rechtfertigt.
Die Wirtschaftlichkeitsrechnung auf beobachtete Arbeit stützen
Verwenden Sie vor und während des Piloten dieselbe Aufgabendefinition. Misst der Ausgangswert eine vollständig bearbeitete Anfrage, der Pilot aber nur eine erzeugte Notiz, wird der Nutzen überzeichnet. Erfassen Sie Zeit für Entwurfsprüfung, Ausnahmebehandlung und Korrekturen im Zielsystem, einschließlich Arbeit von Personen außerhalb des ursprünglichen Teams.
| Bestandteil der Wirtschaftlichkeitsrechnung | Was zu messen oder anzufordern ist |
|---|---|
| Bisheriger Aufwand | Bearbeitungszeit einer abgeschlossenen Aufgabe im aktuellen Verfahren |
| Pilotaufwand | Vorbereitung, Prüfung, Ausnahmen und Nacharbeit für dasselbe Ergebnis |
| Frei werdende Kapazität | Beobachtete Aufwandsdifferenz über die gemessene Arbeitsmenge |
| Wiederkehrende Ausgaben | Nutzung, Hosting, Überwachung, Wartung und beibehaltenes Ersatzverfahren |
| Umsetzungsausgaben | Abgegrenztes Angebot einschließlich Kontrollkonzept und Abnahme |
| Finanzieller Nutzen | Belegbare finanzielle Veränderungen, getrennt von Kapazität |
Ein Pilotbetrieb kann nützliche Kapazität freisetzen, ohne Personalkosten zu reduzieren oder sofort Geld einzusparen. Er kann auch zeigen, dass die Prüfbelastung die eingesparte Vorbereitungszeit übersteigt. Lassen Sie beide Ergebnisse als Entscheidungsgrundlage zu. Das Arbeitsblatt soll eine vertretbare Wahl unterstützen, auch einen engeren Umfang oder den Verzicht auf die Einführung.
Einen begrenzten Ablauf erproben und erst danach erweitern
Stellen Sie sich einen hypothetischen Großhändler vor, dessen Assistent aus eingehenden Anfragen CRM-Notizen vorschlägt. Beginnen Sie mit freigegebenen Beispieldatensätzen und Entwürfen ohne CRM-Änderung. Prüfen Sie, ob die Notizen den Sinn erhalten, fremde Kundendaten vermeiden und Mitarbeitern genügend Entscheidungskontext geben. Dies ist ein Umfangsbeispiel, keine Kundenerfolgsgeschichte.
Aktivieren Sie begrenzte Änderungen erst, wenn Zugriffs-, Freigabe- und Fehlertests die vereinbarten Bedingungen erfüllen. Halten Sie das bisherige Verfahren verfügbar und weisen Sie die Verantwortung für Ausnahmen zu. Bewerten Sie korrekte abgeschlossene Änderungen, Prüfaufwand und Wiederherstellungsverhalten. Bewältigen einfache Regeln die Aufgabe ausreichend, kann deren Beibehaltung ein erfolgreiches Ergebnis der Untersuchung sein.
Eine Erweiterung braucht eine eigene Entscheidung. Neue Datenquellen, Nutzergruppen oder Werkzeuge verändern die geprüfte Grenze. Leiten Sie aus einem Notizpiloten keine Berechtigung zu autonomen Erstattungen oder Kundenexporten ab. Bewahren Sie Nachweise des bisherigen Umfangs auf und bestimmen Sie zusätzliche Kontrollen und Tests für die neue Fähigkeit.
Eine Integration mit prüfbaren Nachweisen beauftragen
Bringen Sie zum Erstgespräch eine Ablaufbeschreibung, anonymisierte Beispiele, eine Zugriffsübersicht und eine Liste folgenreicher Aktionen mit. Lassen Sie Anbieter erklären, welche Kontrollen außerhalb des Modells durchgesetzt werden, und neben Erfolgen auch Ablehnungen demonstrieren. Verlangen Sie eine Lieferung, die verbleibende Einschränkungen, Zuständigkeiten und Einsatzbedingungen benennt.
Unsere KI-Integrationsleistungen helfen bei der Abgrenzung eines Agentenablaufs und dessen Anbindung an vorhandene Anwendungen. Nennen Sie für ein brauchbares Briefing die beteiligten Systeme, gewünschte Lese- oder Schreibaktionen und Vorgänge mit menschlichem Entscheidungsbedarf. Fragen Sie nach einem abgegrenzten GBP-Angebot für Pilotbetrieb, Abnahmenachweise und betriebliche Verantwortlichkeiten.
Die Kaufentscheidung sollte davon abhängen, ob der vorgeschlagene Ablauf seine Zugriffsrechte verdient. Kann die Integration nicht erklären, wer eine Änderung autorisiert hat, oder ihre Stoppfunktion vorführen, verschieben Sie weitergehende Rechte. Nützliche Automatisierung gibt Ihrem Unternehmen nachvollziehbare Abläufe und eine schnellere Vorbereitung von Arbeit.
Häufig gestellte Fragen
Kann ein besserer Prompt einen KI-Agenten sicher machen? Ein besserer Prompt kann das Verhalten steuern, schafft aber keine Zugriffskontrolle. Setzen Sie Berechtigungen in der angebundenen Anwendung durch, validieren Sie vorgeschlagene Vorgänge und testen Sie Grenzen mit bösartigen Eingaben. Promptverbesserungen sind eine Schutzschicht, keine Garantie.
Braucht jede Agentenaktion eine menschliche Freigabe? Nein. Entscheiden Sie nach Vorgang und Folgen. Unkritische Aktionen dürfen innerhalb einer genehmigten Richtlinie laufen; folgenreiche Änderungen brauchen informierte Prüfung oder bleiben gesperrt. Testen Sie, ob die Freigabe exakt für den ausgeführten Vorgang gilt.
Was gehört in eine Prüfung der Sicherheit von KI-Agenten? Dazu gehören Ablauf- und Zugriffsübersicht, Werkzeugrechte, nachgelagerte Autorisierung, Freigabeverhalten, Angriffstests, Fehlerbehebung und betriebliche Zuständigkeit. Verlangen Sie tatsächliche Anwendungsnachweise für abgelehnte Anfragen und erfolgreiche Aufgaben sowie dokumentierte offene Einschränkungen.
Was kostet die Absicherung eines KI-Agenten? Verlangen Sie ein abgegrenztes GBP-Angebot für Konnektoren, Zugriffsdurchsetzung, Prüfoberflächen, Tests und Übergabe. Laufende Nutzung, Überwachung, Prüfzeit und Wartung zählen ebenfalls. Keine allgemeine Preisspanne berücksichtigt die Unterschiede zwischen Anwendungen und Fehlerfolgen ausreichend.
Wann sollte ein Unternehmen den Agentenpiloten erweitern? Erweitern Sie erst, wenn der aktuelle Ablauf seine vereinbarten Abnahmebedingungen erfüllt und eine betriebliche Zuständigkeit besteht. Neue Quellen, Werkzeuge oder Nutzergruppen benötigen eine neue Umfangsentscheidung und relevante Tests. Ein erfolgreicher Schreibentwurfspilot rechtfertigt keine fremden privilegierten Aktionen.