Werkzeugzugang ist keine Befugnis.

Die wichtigste Frage zu einem KI-Agenten lautet nicht mehr:

Wie intelligent ist er?

Sie lautet:

Was kann er tun? Und wer hat entschieden, dass er es tun darf?

Ein Agent mit Zugriff auf E-Mail, CRM, Dateien, Code, Zahlungen oder interne APIs ist mehr als ein benutzerfreundlicherer Chatbot. Er ist ein handelndes Softwaresystem mit möglichen Folgen.

Sobald er ein Werkzeug aufrufen kann, müssen Fähigkeit und Befugnis getrennt werden.

Ein Kundenservice-Agent kann technisch möglicherweise:

• eine Bestellung lesen;
• eine Adresse ändern;
• eine Erstattung ausführen;
• eine E-Mail versenden;
• ein Abonnement kündigen.

Das beschreibt seinen technischen Handlungsspielraum.

Sein erlaubter Handlungsspielraum sollte kleiner sein und vom Kontext abhängen.

Vielleicht darf er eine Bestellung für den authentifizierten Kunden lesen. Vielleicht darf er eine Erstattung vorbereiten, aber nicht auszahlen. Vielleicht darf er Erstattungen unterhalb einer Grenze ausführen und höhere Beträge zur Prüfung weitergeben. Interne Betrugsvermerke darf er möglicherweise überhaupt nicht offenlegen.

Setzen wir „kann“ mit „darf“ gleich, ist die Architektur bereits fehlerhaft.

MCP vereinheitlicht, wie KI-Anwendungen auf externe Ressourcen und Werkzeuge zugreifen. Seine Autorisierungsspezifikation nutzt etablierte OAuth-Verfahren für HTTP-Übertragungen. Sie betont ressourcenspezifische Tokens und deren Prüfung.

Quellenkontext: MCP · authorization specification · 2026-07-28 ↗

A2A betrifft eine andere Ebene: Agenten finden andere Agenten, kommunizieren und koordinieren sich mit ihnen. Google entwickelte das Protokoll; heute betreut es die Linux Foundation. Version 1.0 liegt als offener Standard für die Zusammenarbeit zwischen Agenten verschiedener Anbieter, Frameworks und Unternehmensumgebungen vor.

Quellenkontext: Agent2Agent · v1.0 specification ↗

Protokollkompatibilität klärt keine organisatorischen Befugnisse. Eine gültige Agent Card, Werkzeugbeschreibung, ein OAuth-Token, Registry-Eintrag oder signierte Metadaten können Zusammenarbeit, Identitätsmerkmale und Sicherheit unterstützen. Sie beantworten jedoch keine konkrete Erlaubnisfrage. Darf dieser Agent diese Handlung für diese Organisation an diesem Gegenstand mit diesen Folgen ausführen?

Diese Zusammenarbeit ist nützlich. Zugleich werden die Berechtigungsbeziehungen komplexer.

Ein Agent kann verfügen über:

MODELLFÄHIGKEITEN + WERKZEUGFÄHIGKEITEN + DATENZUGRIFF + ZUGRIFF AUF ANDERE AGENTEN + NUTZERKONTEXT + ORGANISATORISCHE ROLLE.

Nichts davon sollte automatisch geschäftliche Befugnisse erteilen.

OWASPs LLM Top 10 beschreibt „Excessive Agency“ als Risiko durch übermäßige Funktionen, Berechtigungen oder Autonomie. Die Agentic Top 10 vertieft weitere Gefahren: manipulierte Ziele, Werkzeugmissbrauch, Identitäts- und Berechtigungsmissbrauch, Lieferkettenlücken und unerwartete Codeausführung.

Quellenkontext: OWASP Top 10 for Agentic Applications 2026 ↗

Daraus folgt nicht: „Agenten sind unsicher.“

Agenten brauchen vielmehr dieselbe Sorgfalt, die wir von verlässlich betriebenen Systemen erwarten. Hinzu kommen Kontrollen für natürlichsprachige Anweisungen, dynamische Werkzeugauswahl und probabilistisches Verhalten.

Ein hilfreicher Befugniseintrag beantwortet:

WER handelt? FÜR WELCHE Organisation oder welchen Mandanten? FÜR WELCHES Vorhaben? AN WELCHEM Gegenstand? MIT WELCHEM Werkzeug oder welcher Fähigkeit? FÜR WELCHE Handlung? MIT WELCHER Grenze? BIS WANN? UNTER WELCHER Freigabebedingung? MIT WELCHER Folgenklasse?

Das ist wesentlich genauer als: „Der Agent hat Zugriff auf Salesforce.“

Zugriff gehört zur Infrastruktur. Befugnisse sind eine geschäftliche und organisatorische Entscheidung.

Ein einfacher Grundsatz:

Größere Folgen dürfen keine geringere Kontrolle erfordern.

Wechselt ein Agent vom Empfehlen zum Vorbereiten und schließlich zum Ausführen, dürfen die erforderlichen Befugnisse nicht geringer werden.

Werden Daten sensibler, dürfen Kontrollen zur Offenlegung nicht schwächer werden.

Wurde eine Berechtigung widerrufen, darf ein zwischengespeicherter Ablauf keine weitergehende Ausführung erlauben. Seine überholte Annahme einer bestehenden Berechtigung zählt nicht.

Enthält eine Eingabe einen unbelegten oder fehlerhaft formatierten Sicherheitszustand, muss das System im Zweifel sperren. Es darf nicht die freizügigste Auslegung wählen.

Das sind keine philosophischen Regeln. Es sind prüfbare Eigenschaften.

Eine weitere wichtige Grenze:

Ein Agent sollte die Nachweise für seine eigenen Befugnisse nicht selbst erzeugen können.

Dasselbe gilt für Verifizierung.

Ein Modell kann melden: „Ich habe die Aufgabe erledigt.“ Das ist eine Behauptung über die Ausführung.

Die Organisation benötigt möglicherweise dennoch eine unabhängige Beobachtung:

Hat sich der CRM-Eintrag tatsächlich geändert? Wurde der richtige Kunde aktualisiert? Lag die Handlung innerhalb des genehmigten Betrags? Wurde die Zahlung abgewickelt? Wurde die erforderliche menschliche Freigabe dokumentiert?

Ausführungsbehauptung ≠ beobachtetes Ergebnis.

Eine menschliche Freigabe für jede Agentenhandlung würde einen großen Teil des wirtschaftlichen Nutzens aufheben.

Gar keine Prüfung zu verlangen, wäre verantwortungslos.

Das Ziel ist eine angemessen abgestufte Prüfung.

Rücknehmbare Handlungen mit geringen Folgen und guter Beleglage können häufig begrenzte Autonomie erhalten. Handlungen mit größeren Folgen oder Unklarheiten sollten weitergehende Befugnisse oder menschliche Prüfung erfordern. Geschützte Grenzen für Menschen, Sicherheit, Datenschutz und Recht können auch eine wirtschaftlich attraktive Handlung untersagen.

„Human in the loop“ ist als Schlagwort noch keine Lösung.

Entscheidend ist: Welcher Mensch prüft an welcher Stelle welche Entscheidung anhand welcher Nachweise?

Agentische Systeme können einen fehlerhaften Ablauf ebenso wirksam verstärken wie einen guten. McKinseys Empfehlungen zur Skalierung vom September 2026 benennen das betriebliche Problem ausdrücklich. Viele Unternehmen erweitern den Agenteneinsatz schneller, als sie die zugrunde liegende Arbeit neu gestalten. Für ein Befugnismodell folgt daraus: Autonomie sollte auf Aufgaben- und Ablaufgestaltung, nutzbaren Daten, Eigenentwicklungs- oder Kaufentscheidungen, Entscheidungsrechten und Eskalation aufbauen. Sie darf diese Grundlagen nicht ersetzen.

Nicht jede Aufgabe braucht einen Agenten. Deterministische Automatisierung, analytische Modelle, generative Assistenz oder agentische Ausführung können jeweils besser passen. Menschliche Entscheidungsbefugnis ist davon unabhängig. Die Organisation bestimmt weiterhin, was unter welchen Bedingungen geschehen darf und wer dafür verantwortlich ist.

Die Berechtigung eines Agenten braucht einen Lebenszyklus. Jemand erteilt sie für einen Zweck, sie gilt für bestimmte Handlungen und sie endet, wenn ihre Voraussetzungen wegfallen. Das klingt selbstverständlich, bis ein Projekt ein gemeinsam genutztes Dienstkonto verbindet und die Verbindung unbegrenzt bestehen bleibt. Das Konto kann weiter funktionieren, obwohl die verantwortliche Person ihre Rolle gewechselt hat, der Pilot beendet wurde oder ein Werkzeug neue Funktionen erhalten hat.

Beginnen Sie mit der kleinsten nützlichen Delegation. Ein Einkaufsassistent darf beispielsweise freigegebene Lieferantendokumente lesen und einen Vergleich vorbereiten. Einen Bestellentwurf anzulegen ist eine zusätzliche Berechtigung; die Bestellung verbindlich auszulösen eine weitere. Bereits die ersten beiden Tätigkeiten können hilfreich sein, während die Verpflichtung von Budget im bestehenden Einkaufsprozess verbleibt. Unternehmen müssen nicht zwischen einem isolierten Chatbot und unbeschränkter Automatisierung wählen.

Der Entzug einer Berechtigung muss beim tatsächlichen Handlungsversuch wirken. Es reicht nicht, den Agenten aus einer Übersicht zu entfernen, wenn eine laufende Sitzung, eine wartende Aufgabe oder ein zwischengespeicherter Zugang weiterhin schreiben kann. Prüfen Sie, ob Befugnisse nach einer Verzögerung, nach dem Widerruf einer Freigabe und nach einer Änderung am betroffenen Datensatz erneut kontrolliert werden. Legen Sie das erwartete Verhalten für jeden Fall vor dem Test fest. Ein Ergebnis lässt sich besser beurteilen, wenn klar ist, was hätte geschehen sollen.

Ein interner Assistent soll Ausstattung für einen neuen Mitarbeiter beschaffen. Er findet den freigegebenen Katalog, prüft das Abteilungsbudget und bereitet einen Bestellentwurf vor. Eine Führungskraft genehmigt einen bestimmten Laptop mit festgelegter Menge und Preis. Vor dem Absenden ändert der Lieferant jedoch den Preis oder ersetzt den Artikel. Die frühere Freigabe darf nicht stillschweigend für ein anderes Geschäft weitergelten.

Eine sinnvolle Umsetzung bindet die Freigabe an die maßgeblichen Einzelheiten: Besteller, Lieferant, Artikel, Menge, Preisgrenzen und Gültigkeitszeitraum. Wesentliche Änderungen führen zurück zur Prüfung. Eine wiederholte Anfrage sollte den vorhandenen Bestellzustand aufnehmen, statt einen zweiten Einkauf anzulegen. Antwortet der Lieferant uneindeutig, muss der Ablauf zuerst den tatsächlichen Vorgang abgleichen. Diese Kontrollen sind ein Gestaltungsvorschlag und keine Behauptung über die Umsetzung eines bestimmten Anbieters.

Dasselbe Beispiel zeigt die Grenzen einer lockeren Aufgabenweitergabe zwischen Agenten. Ein Planungsagent kann einen Einkaufsagenten um Unterstützung bitten. Die Nachricht schafft jedoch weder Budget noch Bestellbefugnis. Jeder Empfänger muss weiterhin prüfen, welche Rechte für seine eigene Handlung gelten. Eine überzeugend formulierte Anweisung eines anderen Agenten darf niemals mehr Berechtigung erzeugen, als das Unternehmen tatsächlich erteilt hat.

Auch die Stellvertretung muss eindeutig bleiben. Handelt das System im Namen eines Mitarbeiters, eines Teams oder eines technischen Dienstes? Wer übernimmt den Vorgang, wenn diese Person abwesend ist? Eine dokumentierte Vertretung mit demselben fachlichen Umfang ist etwas anderes als ein allgemeines Administratorkonto. Die Wahl beeinflusst, welche Informationen sichtbar sein dürfen und wer eine spätere Rückfrage beantworten kann.

Eine Freigabeansicht sollte Handlung, Folgen, verwendete Nachweise und den Grund der Rückfrage knapp zusammenfassen. Ein langer Gesprächsverlauf kann bei einer Untersuchung helfen, ist aber selten die beste Entscheidungsoberfläche. Die prüfende Person muss das konkrete Änderungsobjekt sowie den Unterschied zwischen aktuellem und vorgeschlagenem Zustand erkennen. Wesentliche Unsicherheit gehört neben die Handlung und nicht unter eine beruhigende Erfolgsmeldung.

Die Auswahl muss wirksam sein: den begrenzten Vorgang genehmigen, den Entwurf ändern, weitere Nachweise anfordern oder ablehnen. Zeigen Sie, wann eine Freigabe ungültig wird. Sollen Menschen jeden Fall prüfen, müssen Warteschlange und erforderliche Aufmerksamkeit gemessen werden. Die Bezeichnung „menschlich geprüft“ belegt noch nicht, dass ausreichend Zeit, Information und Befugnis zum Widerspruch vorhanden sind.

Der Europäische Datenschutzbeauftragte unterscheidet bei automatisierten Entscheidungen eine wirksame Beteiligung von einer bloßen Formalität. Diese Ausführungen betreffen Datenschutz und sind kein allgemeiner Agentenstandard. Für die Arbeitsgestaltung ist die Unterscheidung dennoch hilfreich: Eine Person in einem Schaubild ist weniger aussagekräftig als der Nachweis, was diese Person tatsächlich verstehen und verändern kann. Quelle zur menschlichen Aufsicht.

Ordnen Sie Testfälle nach ihren Folgen. Dazu gehören eine erlaubte Standardhandlung, eine verbotene Handlung, eine fehlende Freigabe, eine abgelaufene Freigabe, ein anderer Mandant und ein veränderter Ausgangsdatensatz. Testen Sie außerdem eine versteckte Anweisung in abgerufenen Inhalten sowie den Aufruf eines Werkzeugs, das der Agent finden, aber nicht benutzen darf. Erwartet wird jeweils ein bestimmter erlaubter, verweigerter oder eskalierter Zustand und keine allgemeine Aussage, der Agent habe sich sicher verhalten.

Beobachten Sie das nachgelagerte System unabhängig. Die Erklärung eines Modells, weshalb es eine Grenze eingehalten habe, kann nützlich sein. Sie beweist jedoch nicht, dass ein externer Schreibzugriff tatsächlich verhindert wurde. Prüfen Sie die realen Datensätze und das Protokoll. Halten Sie Modell-, Schnittstellen- und Richtlinienversion fest, damit ein späterer Test Veränderungen erklären kann. Auch Fehler bleiben als Nachweis erhalten, statt ausschließlich erfolgreiche Vorführungen auszuwählen.

Zum Test gehört der Wiederanlauf. Können Beschäftigte den zugrunde liegenden Geschäftsprozess abschließen, wenn das Modell ausfällt? Erklärt der Assistent bei einer abgeschalteten Verbindung, welche Handlungen nicht verfügbar sind? Ein geordneter Ersatzweg schützt den Betrieb, ohne vorbereitete oder wartende Vorgänge als erledigt darzustellen. Das ist eine Voraussetzung unterstützter Arbeit und kein Auftrag, jede Ausnahme zu automatisieren.

Legen Sie vor einer Ausweitung drei Beispiele vor: eine gewöhnliche Handlung, einen Grenzfall und einen unerlaubten Vorgang. Zeigen Sie jeweils Akteur, betroffenes Objekt, Nachweise und erwartete externe Änderung. Die fachlich verantwortliche Person sollte die Entscheidung ohne Erzählung des Modells erklären können. Eine unverständliche Grenze eignet sich nicht als Grundlage einer größeren Delegation.

Ändern Sie anschließend genau eine relevante Einzelheit. Tauschen Sie den Kunden aus, erhöhen Sie den Betrag, lassen Sie die Freigabe ablaufen oder verschieben Sie die Anfrage in ein anderes Unternehmen. Das Ergebnis muss der veränderten Bedingung folgen. Damit wird geprüft, ob die Umsetzung die tatsächliche Berechtigung verwendet oder nur ein vertrautes Beispiel wiederholt. Dokumentieren Sie die externe Beobachtung und nicht ausschließlich die Antwort des Assistenten.

Klären Sie zuletzt, wer die Delegation im gewöhnlichen Betrieb zurücknehmen darf und wie Beschäftigte davon erfahren. Die Antwort benennt eine Rolle und einen praktischen Weg. Ein Notfallmechanismus, den nur der ursprüngliche Entwickler versteht, ist eine schwache Kontrolle. Bewahren Sie die Prüfung mit der Berechtigung auf, damit spätere Verantwortliche Zweck und Grenzen nachvollziehen können. Ergänzen Sie eine Vertretung für Abwesenheit. So bleibt die Kontrolle auch dann wirksam, wenn das Projektteam nicht mehr täglich beteiligt ist.

Vergleichen Sie im Good AI Prisma die zur Bereitstellung und zu Berechtigungen vorliegenden Angaben. Das Wort „Agent“ allein sagt darüber wenig aus. Fragen Sie, welche Kontrollen konfigurierbar sind, welche der Anbieter durchsetzt, welche Ihre Integration übernehmen muss und welche für den vorgesehenen Tarif nicht dokumentiert sind. Diese Unterschiede gehören sowohl in den Vergleich als auch in die Rückfragen an den Lieferanten.

Der AI Trust Pilot ist ein möglicher Gesprächseinstieg für einen einzelnen Anwendungsfall mit vereinbarter Verantwortung und Prüfgrenze. Ein AI Decision Brief beginnt kleiner, wenn zunächst geeignete Optionen eingegrenzt werden sollen. Den Brief fragen Sie an; Sten bestätigt die vollständige Anfrage und damit den Beginn des Lieferfensters. Keine dieser Leistungen erteilt einem Agenten die Befugnis, Ihre Systeme zu bedienen. Darüber entscheidet das Unternehmen ausdrücklich.

Bevor ein Agent ein Werkzeug erhält, fragen Sie:

Welches Vorhaben unterstützt dieses Werkzeug? Welche genaue Handlung ist erforderlich? Welche Mindestberechtigung wird benötigt? Welche Daten kann die Handlung offenlegen? Was lässt sich rückgängig machen? Wie groß ist der mögliche Schadensumfang? Was braucht eine Freigabe? Was geschieht, wenn die Befugnis abläuft? Wie beobachten wir das Ergebnis unabhängig? Wie können wir die Entscheidung später nachvollziehbar erneut durchgehen?

Sind diese Antworten unklar, liegt das Problem nicht beim Modell.

Es liegt in der betrieblichen Gestaltung seines Umfelds.