KI-Agenten brauchen mehr als Login-Daten

KI-Agenten verändern gerade eine scheinbar kleine, aber sehr wichtige Frage.

Früher ging es oft darum: Darf ein KI-System Informationen sehen?

Heute geht es zunehmend darum: Darf ein KI-System handeln?

Das ist ein anderer Risikotyp. Ein Chatbot, der eine falsche Antwort gibt, ist ärgerlich. Ein Agent, der ein falsches Tool ausführt, eine Datenbank verändert, einen API-Call auslöst oder einen Deployment-Prozess startet, kann echten Schaden verursachen.

Auf X wird genau diese Lücke gerade intensiv diskutiert: Viele Teams verbinden Agenten mit Tools, MCP-Servern, Repositories, Cloud-Diensten, internen APIs und Automatisierungen. Sie lösen das Login-Problem — aber nicht automatisch das Ausführungsproblem.

Anders gesagt: Ein Agent kann authentifiziert sein und trotzdem Dinge tun dürfen, die er in diesem Moment niemals tun sollte.

Für Gründer, CTOs, Produktverantwortliche und Mittelstandsteams ist das kein theoretisches Security-Thema. Es ist eine Architekturfrage. Wer KI-Agenten produktiv einsetzen will, braucht eine klare Antwort darauf, welche Aktionen erlaubt sind, welche nur mit Freigabe passieren dürfen und welche grundsätzlich außerhalb der Reichweite des Agenten bleiben.

Authentifizierung ist nicht Autorisierung

In vielen Softwareprojekten werden diese Begriffe im Alltag vermischt.

Authentifizierung beantwortet: Wer oder was bist du?

Autorisierung beantwortet: Was darfst du tun?

Bei Menschen ist der Unterschied bekannt. Ein Mitarbeitender kann sich korrekt einloggen und trotzdem keine Gehaltsdaten lesen, keine Produktionsdatenbank löschen und keine Zahlungsfreigaben erteilen. Identität allein ist keine Erlaubnis für jede Aktion.

Bei KI-Agenten wird diese Trennung schnell unscharf.

Ein Agent bekommt einen API-Key, ein GitHub-Token, Zugriff auf einen MCP-Server, einen Browser, ein Terminal oder ein internes Tool. Technisch funktioniert die Verbindung. Der Agent kann arbeiten. Genau das macht ihn nützlich.

Aber wenn dieses Token zu breit ist, wird aus Produktivität ein Betriebsrisiko.

Der Agent hat dann nicht nur Kontext. Er hat Wirkung.

Er kann Daten lesen, verändern, verschieben, löschen oder veröffentlichen. Er kann teure Prozesse starten. Er kann sensible Informationen in falsche Systeme schreiben. Er kann aus einer plausibel klingenden, aber falschen Interpretation heraus eine Aktion ausführen, die für das Unternehmen real ist.

Das Problem ist nicht, dass KI-Agenten „böse“ sind. Das Problem ist, dass probabilistische Systeme keine stabilen Sicherheitsgrenzen ersetzen.

Ein Sprachmodell kann Absichten interpretieren. Es sollte aber nicht allein entscheiden, ob eine riskante Aktion ausgeführt werden darf.

MCP und Tool-Zugriff machen die Frage dringender

Das Model Context Protocol und ähnliche Tool-Integrationen sind ein wichtiger Schritt. Sie machen es einfacher, KI-Systeme mit Datenquellen, Entwicklungswerkzeugen und Geschäftssystemen zu verbinden.

Das ist gut. Ohne solche Schnittstellen bleiben viele KI-Anwendungen oberflächlich.

Ein Agent, der nur schreibt, ist begrenzt. Ein Agent, der Tickets lesen, Code ändern, Tests starten, Daten analysieren, Supportfälle vorbereiten oder interne Workflows ausführen kann, wird für Unternehmen deutlich interessanter.

Aber Tool-Zugriff verschiebt KI vom Wissenssystem zum Handlungssystem.

Sobald ein Agent Werkzeuge bedienen kann, entstehen neue Fragen:

• Darf der Agent nur lesen oder auch schreiben?
• Darf er Änderungen direkt ausführen oder nur vorschlagen?
• Welche Systeme sind produktionskritisch?
• Welche Aktionen brauchen menschliche Freigabe?
• Welche Credentials sind kurzlebig und aufgabenbezogen?
• Welche Aktion wird wie protokolliert?
• Gibt es Rollback- oder Wiederherstellungswege?
• Wer bekommt einen Alarm, wenn ein Agent etwas Ungewöhnliches versucht?

Diese Fragen klingen langweilig. Genau deshalb sind sie wichtig.

Seriöse Software entsteht selten durch spektakuläre Einzelentscheidungen. Sie entsteht durch klare Grenzen, gute Defaults und Systeme, die auch dann vernünftig reagieren, wenn jemand — oder etwas — einen Fehler macht.

Der gefährliche Standard: „Der Agent darf, was der Nutzer darf“

Ein häufiger Fehler ist, Agenten einfach mit den Rechten des Menschen auszustatten, der sie benutzt.

Das wirkt praktisch. Ein Entwickler darf auf Repository, Ticket-System und Staging-Umgebung zugreifen. Also bekommt der Agent diese Rechte auch. Ein Operations-Mitarbeiter darf Deployments auslösen. Also kann der Agent das ebenfalls. Ein Produktverantwortlicher darf Kundendaten exportieren. Also bekommt der Agent Zugriff auf das entsprechende Tool.

Für einfache Aufgaben spart das Reibung.

Für produktive Systeme ist es gefährlich.

Ein Mensch bringt Kontext mit, den das Berechtigungssystem nicht sieht: Erfahrung, Verantwortungsgefühl, Bauchgefühl, Erinnerung an vergangene Incidents, Verständnis für Kundenversprechen, Wissen über interne Absprachen. Ein Agent simuliert Teile davon, aber er besitzt diese Verantwortung nicht.

Deshalb sollten Agenten nicht automatisch die Rechte ihrer Nutzer erben.

Sie brauchen eigene Rollen.

Eine gute Agentenrolle ist enger als eine menschliche Rolle. Sie ist auf konkrete Aufgaben zugeschnitten. Sie trennt Lesen, Vorschlagen und Ausführen. Sie erlaubt ungefährliche Aktionen schnell und macht riskante Aktionen bewusst langsam.

Das Ziel ist nicht, KI-Agenten unbrauchbar zu machen. Das Ziel ist, den sicheren Pfad zum einfachsten Pfad zu machen.

Eine bessere Architektur: Ausführung als eigene Schicht

Der wichtigste Gedanke ist einfach: Die KI entscheidet nicht allein, ob etwas ausgeführt wird.

Sie kann eine Aktion vorschlagen. Sie kann erklären, warum diese Aktion sinnvoll ist. Sie kann Parameter vorbereiten, Auswirkungen beschreiben und Alternativen nennen.

Aber zwischen Vorschlag und Ausführung sollte eine deterministische Schicht stehen.

Diese Schicht kann sehr einfach beginnen:

• erlaubte Tools pro Agent und Aufgabe;
• getrennte Lese- und Schreibrechte;
• keine produktiven Schreibrechte ohne Freigabe;
• blockierte Aktionen für irreversible Vorgänge;
• kurzlebige Tokens statt dauerhafter Secrets;
• verpflichtende Pull Requests statt direkter Commits;
• Staging vor Produktion;
• Audit-Logs mit Prompt, Tool-Aufruf, Parameter, Ergebnis und Freigabe;
• Kosten- und Mengenlimits für API-Aktionen;
• Alarme bei ungewöhnlichen Mustern.

In größeren Umgebungen wird daraus Policy-as-Code: Regeln, die nicht nur in einem Confluence-Dokument stehen, sondern technisch vor jeder Ausführung geprüft werden.

Ein Beispiel:

Ein Agent darf ein Datenbank-Schema analysieren, Migrationsvorschläge erzeugen und Tests schreiben. Er darf die Migration aber nicht selbst gegen Produktion ausführen. Dafür braucht es einen Pull Request, einen erfolgreichen Testlauf, ein Backup, ein Review und eine menschliche Freigabe.

Ein anderer Agent darf Supportfälle zusammenfassen und Antwortentwürfe vorbereiten. Er darf aber keine Nachricht an Kunden senden, keine Preise ändern und keine personenbezogenen Daten in ein externes System kopieren.

Diese Unterscheidungen sind nicht Bürokratie. Sie sind Produktqualität.

Was deutsche Unternehmen besonders beachten sollten

Für deutsche Unternehmen kommen mehrere Themen zusammen: Datenschutz, Verfügbarkeit, Nachvollziehbarkeit, Kundenvertrauen und oft gewachsene Systemlandschaften.

Viele Mittelstandsunternehmen haben nicht eine saubere Plattform, sondern eine Mischung aus ERP, CRM, Excel, Spezialsoftware, SaaS-Tools, manuellen Freigaben und historisch gewachsenen Schnittstellen. Genau dort sind Agenten verlockend. Sie können Lücken überbrücken, Prozesse beschleunigen und interne Tools schneller möglich machen.

Aber genau dort ist unklarer Tool-Zugriff besonders riskant.

Wenn niemand genau dokumentiert hat, welches System welche Daten enthält, welcher Export kritisch ist oder welche API Nebenwirkungen hat, kann ein Agent diese Komplexität nicht magisch sicher machen. Er kann sie höchstens schneller bedienen.

Deshalb sollte die Einführung von Agenten nicht mit „welches Tool ist gerade am beeindruckendsten?“ beginnen.

Sie sollte mit einer nüchternen Systemkarte beginnen:

• Welche Daten sind sensibel?
• Welche Systeme sind produktionskritisch?
• Welche Aktionen sind reversibel?
• Welche Aktionen sind teuer, rechtlich relevant oder kundenwirksam?
• Wo sind Backups und Wiederherstellung getestet?
• Welche Freigaben gibt es heute schon?
• Welche davon müssen technisch erzwungen werden?

Erst danach lohnt sich die Frage, welcher Agent welchen Workflow übernehmen darf.

Die produktive Mitte: nicht blockieren, sondern begrenzen

Es wäre falsch, aus diesen Risiken zu schließen, dass Unternehmen KI-Agenten vermeiden sollten.

Das Gegenteil ist wahrscheinlicher: Teams, die Agenten gut integrieren, werden schneller lernen, schneller liefern und mehr interne Reibung abbauen.

Aber die Gewinner werden nicht die sein, die jedem Agenten pauschal alle Rechte geben. Die Gewinner werden die sein, die gute Grenzen bauen.

Eine sinnvolle Einführungsstrategie sieht oft so aus:

1. Lesender Modus: Der Agent analysiert Code, Dokumentation, Tickets, Logs oder Daten, führt aber keine Änderungen aus.
2. Vorschlagsmodus: Der Agent erstellt Pull Requests, Migrationsentwürfe, Antwortentwürfe oder Prozessvorschläge.
3. Begrenzte Ausführung: Der Agent darf ungefährliche, reversible Aktionen in klar definierten Umgebungen ausführen.
4. Freigabepflichtige Ausführung: Riskante Aktionen brauchen Review, Tests, Backup und menschliche Zustimmung.
5. Messung und Anpassung: Logs, Fehlerfälle, Kosten und Zeitgewinn werden regelmäßig ausgewertet.

So entsteht Vertrauen nicht durch Hoffnung, sondern durch Betriebserfahrung.

Der eigentliche Vorteil: bessere Systeme, nicht nur schnellere Arbeit

Die Diskussion um KI-Agenten wird oft als Produktivitätsdebatte geführt. Wie viel schneller schreiben wir Code? Wie viele Tickets schaffen wir? Wie viel günstiger wird Entwicklung?

Das ist verständlich, aber zu kurz gedacht.

Der größere Vorteil entsteht, wenn Unternehmen durch Agenten gezwungen werden, ihre Systeme besser zu strukturieren: klare APIs, saubere Rollen, zuverlässige Tests, dokumentierte Datenflüsse, gute Deployment-Prozesse, nachvollziehbare Entscheidungen.

Denn Agenten funktionieren am besten in Umgebungen, die auch für Menschen gut wartbar sind.

Wenn ein System nur durch informelles Wissen, manuelle Ausnahmen und „frag mal Anna, die weiß das“ stabil bleibt, wird ein Agent dort früher oder später Unsinn machen. Wenn ein System klare Grenzen und gute Rückmeldungen hat, kann ein Agent echten Wert liefern.

Das ist der Punkt, an dem McDougall Digital typischerweise ansetzt: nicht bei KI als Spielzeug, sondern bei KI-gestützter Softwareentwicklung für ernsthafte Produkte.

Wir helfen Teams dabei, Agenten nicht einfach „anzuschließen“, sondern sinnvoll in Architektur, Entwicklungsprozesse und Betrieb einzubauen. Dazu gehören Tool- und API-Grenzen, Rollenmodelle, CI/CD, Tests, Review-Flows, Auditierbarkeit und pragmatische Sicherheitsentscheidungen, die zum Unternehmen passen.

Fazit

KI-Agenten brauchen mehr als Login-Daten.

Sobald sie Tools bedienen, APIs aufrufen und interne Systeme verändern können, wird Autorisierung zur zentralen Architekturfrage. Wer darf was ausführen? Unter welchen Bedingungen? Mit welchem Nachweis? Mit welchem Rollback?

Die gute Nachricht: Dafür braucht es nicht immer ein riesiges Enterprise-Programm. Oft reicht ein klarer erster Schritt: Agentenrollen definieren, produktive Schreibrechte begrenzen, Freigaben für riskante Aktionen erzwingen und alle Tool-Aufrufe nachvollziehbar machen.

Wenn Sie KI-Agenten in Entwicklung, internen Tools oder Betriebsprozessen einsetzen möchten, lohnt sich diese Arbeit früh.

McDougall Digital kann dabei helfen, bestehende Workflows zu prüfen, sichere Agenten-Grenzen zu entwerfen und KI-gestützte Softwareentwicklung so aufzusetzen, dass sie nicht nur schnell wirkt, sondern auch langfristig tragfähig bleibt.