Coding-Agenten in regulierten Unternehmen: Leitplanken statt Stillstand

Bei einem Kunden, mit dem ich arbeite, sind MCP-Server derzeit noch nicht freigegeben. Damit fehlt den Coding-Agenten ein Teil der Werkzeuge, mit denen sie auf interne Informationen zugreifen oder Arbeitsschritte ausführen könnten. Die Vorsicht dahinter ist nachvollziehbar: Ein Agent, der Code schreiben kann, sollte nicht automatisch auf jedes System zugreifen und jede Änderung ausrollen dürfen.

Ich halte es trotzdem für den falschen Weg, Agenten dauerhaft so weit einzuschränken, dass sie kaum noch nützlich sind. Die Alternative ist nicht ein Agent mit unbegrenzten Rechten. Sie ist ein klar abgegrenzter Einsatz, bei dem Berechtigungen, Prüfungen und Verantwortlichkeiten zum tatsächlichen Risiko passen.

In diesem Post geht es darum, wie solche Leitplanken aussehen können. Nicht als fertige Compliance-Checkliste für jedes Unternehmen, sondern als praktischer Ansatz, den eine Organisation mit ihren eigenen Sicherheits-, Datenschutz- und Betriebsverantwortlichen konkretisieren muss.

Nicht „Dürfen wir KI nutzen?“, sondern „Wofür und unter welchen Bedingungen?“

Die allgemeine Frage nach KI ist zu groß, um sie sinnvoll freizugeben. Ein Agent, der einen Test in einem Repository ergänzt, hat ein anderes Risikoprofil als ein Agent, der Produktionsdaten liest oder eine Änderung an einer produktiven Infrastruktur ausführt.

Für eine konkrete Entscheidung sollten deshalb zuerst der Anwendungsfall und seine Grenzen beschrieben werden:

• Welche Aufgabe soll der Agent erledigen?
• Welche Daten braucht er dafür, und wohin können diese Daten gelangen?
• Welche Werkzeuge und Identitäten verwendet er?
• Welche Änderungen kann er ausführen?
• Welche Folgen hätte eine falsche Handlung?
• Wer trägt die Verantwortung für Ergebnis und Freigabe?

Erst daraus lässt sich ableiten, welche Schutzmaßnahmen nötig sind. Ein pauschales Ja ist genauso wenig hilfreich wie ein dauerhaftes pauschales Nein.

Skills vermitteln Vorgaben, sie erzwingen sie nicht

Zentral gepflegte Skills sind ein guter Weg, einem Agenten Sicherheitsrichtlinien, Architekturstandards und Betriebsanforderungen zur Verfügung zu stellen. Sie können schon bei der Spec-Erstellung dafür sorgen, dass der Agent relevante Vorgaben berücksichtigt, statt sie erst im Review kennenzulernen.

Das ist aber noch kein Nachweis, dass er die Vorgaben eingehalten hat. Ein Agent kann einen Skill nicht laden, eine Anweisung missverstehen oder sie bei einer späteren Entscheidung nicht berücksichtigen. Auch ein Mensch, der eine Richtlinie gelesen hat, ist damit noch nicht automatisch compliant.

Ich würde deshalb drei Ebenen auseinanderhalten:

• Kontext: Skills und Referenzen erklären, was gelten soll und wie es umgesetzt wird.
• Technische Grenzen: Berechtigungen und automatisierte Kontrollen begrenzen, was möglich ist, und prüfen verbindliche Anforderungen.
• Verantwortung: Zuständige Menschen entscheiden über Freigaben, Risiken und Ausnahmen.

Diese Ebenen ergänzen sich. Keine davon ersetzt die anderen.

Berechtigungen am Auftrag ausrichten

Ein Coding-Agent braucht nicht dieselben Rechte wie der Mensch, der ihn startet. Und er braucht für eine konkrete Aufgabe nicht alle Rechte, die er bei irgendeiner zukünftigen Aufgabe gebrauchen könnte.

Für einen ersten Einsatz würde ich die Grenzen beispielsweise so ziehen:

Das ist eine mögliche Startkonfiguration, keine allgemeine Vorgabe für alle Unternehmen. Entscheidend ist, dass die Grenze technisch umgesetzt wird. Die Anweisung „Ändere nichts in Produktion“ reicht nicht aus, wenn der Agent mit einer Identität arbeitet, die genau das tun kann.

MCP ist eine Schnittstelle, keine pauschale Vertrauensentscheidung

Bei MCP lohnt sich dieselbe Differenzierung. Ein Server, der freigegebene Dokumentation lesend bereitstellt, ist anders zu bewerten als einer, der administrative Änderungen ausführen kann. Die Freigabe sollte deshalb nicht nur am Namen der Schnittstelle hängen, sondern am konkreten Server, seinen Tools, Datenflüssen und Berechtigungen.

Zu prüfen wäre beispielsweise, wer den Server betreibt, wie er authentifiziert wird, welche Daten er erhält und welche Aktionen er ermöglicht. Lesender Zugriff ist dabei nicht automatisch unkritisch: Auch die Weitergabe vertraulicher Informationen kann ein Risiko sein.

Außerdem müssen Inhalte aus Dokumenten, Tickets oder anderen externen Quellen als Daten behandelt werden und dürfen nicht unbemerkt die geltenden Anweisungen oder Berechtigungsgrenzen verändern. Das Risiko verschwindet nicht dadurch, dass die Quelle intern ist.

Freigaben brauchen prüfbare Ergebnisse

Ein Review wird nicht dadurch belastbar, dass der Agent am Ende schreibt, er habe alle Richtlinien eingehalten. Die verantwortliche Person braucht nachvollziehbare Ergebnisse.

Je nach Änderung können dazu gehören:

• Der konkrete Diff und die zugehörige Spec.
• Testergebnisse und automatisierte Policy-Checks.
• Die Version der verwendeten Unternehmensvorgaben.
• Dokumentierte Abweichungen und offene Punkte.
• Ein Plan für Rollout und Rücknahme, wenn die Änderung das erfordert.
• Die erforderlichen fachlichen und betrieblichen Freigaben.

Welche Nachweise tatsächlich nötig sind, sollte vor dem Start feststehen. Dann kann der Agent sie während der Arbeit erzeugen, statt dass sie nachträglich rekonstruiert werden müssen.

Auch Protokollierung braucht Grenzen. Für Nachvollziehbarkeit sollten relevante Aktionen und Entscheidungen erfasst werden, aber nicht wahllos sensible Inhalte, Zugangsdaten oder personenbezogene Daten in Logs landen.

Risiken und Ausnahmen brauchen einen Verantwortlichen

Nicht jedes Risiko lässt sich vor einem Pilotprojekt vollständig beseitigen. Das ist bei anderen Technologien nicht anders. Entscheidend ist, dass verbleibende Risiken nicht stillschweigend beim Entwickler hängen bleiben.

Eine dokumentierte Entscheidung sollte festhalten, für welchen Einsatz sie gilt, welche Schutzmaßnahmen vorgesehen sind, welches Risiko verbleibt, wer darüber entscheiden darf und wann die Entscheidung erneut geprüft wird. Eine Ausnahme braucht außerdem einen klaren Umfang und gegebenenfalls ein Ablaufdatum.

Der Agent kann dabei helfen, die Unterlagen vorzubereiten. Er darf daraus aber keine eigene Freigabe ableiten. Die Entscheidung bleibt bei der zuständigen Rolle nach den Regeln der Organisation.

Mit einem kleinen, nützlichen Pilot anfangen

Ein guter Pilot muss nicht möglichst spektakulär sein. Er sollte einen realen Nutzen haben und gleichzeitig einen überschaubaren Wirkungsbereich behalten. Zum Beispiel kann ein Agent Tests ergänzen oder eine standardisierte Pipeline-Änderung als Pull Request vorbereiten, ohne selbst mergen oder ausrollen zu dürfen.

Vor dem Pilot werden die Grenzen festgelegt: zugelassene Repositories, Daten, Tools, Identitäten und Aktionen. Dazu kommen zentrale Skills für die relevanten Vorgaben und automatisierte Prüfungen für Anforderungen, die sich technisch kontrollieren lassen.

Nach dem Pilot würde ich nicht nur fragen, ob der Code schneller fertig war. Interessanter ist auch:

• Welche Vorgaben wurden übersehen?
• Wo mussten Reviewer korrigieren?
• Haben die technischen Grenzen wie erwartet funktioniert?
• Waren die Nachweise für eine Freigabe ausreichend?
• Welche zusätzlichen Rechte wären für den nächsten Schritt wirklich nötig?

Erst auf dieser Grundlage wird der Umfang erweitert. So wächst die Autonomie mit den Erfahrungen und nicht mit dem Optimismus über das Tool.

Ein brauchbarer freigegebener Weg ist auch ein Schutz vor Schatten-IT

Fachabteilungen sind die Kunden der IT. Wenn die IT nicht liefert, können sie sich mit KI inzwischen leichter eigene Lösungen bauen. Das ist aus ihrer Sicht verständlich, kann aber zu Anwendungen führen, bei denen Datenverarbeitung, Berechtigungen und Betriebsverantwortung ungeklärt bleiben.

Die Antwort sollte deshalb nicht nur ein Verbot sein. Es braucht einen zugänglichen Weg für kleine Vorhaben: freigegebene Werkzeuge, verständliche Vorgaben und eine erreichbare Anlaufstelle für Entscheidungen.

Zentrale Skills können auch dabei helfen, Fachabteilungen die relevanten Regeln verfügbar zu machen. Sie ersetzen aber weder die technische Umgebung noch die Klärung, wer eine Lösung später betreibt. Je einfacher der freigegebene Weg ist, desto weniger Anlass gibt es, ihn zu umgehen.

Fazit

Coding-Agenten brauchen in regulierten Unternehmen weder unbegrenzte Rechte noch dauerhafte Handlungsunfähigkeit. Sie brauchen einen klaren Auftrag, passende Berechtigungen, prüfbare Ergebnisse und Menschen, die für Freigaben und Risiken verantwortlich sind.

Skills sind dabei die Wissensschicht. Technische Kontrollen und Freigabeprozesse sorgen dafür, dass verbindliche Anforderungen nicht allein von der Aufmerksamkeit eines Modells abhängen.

Mein Vorschlag ist, mit einem abgegrenzten Anwendungsfall zu starten und die Schutzmaßnahmen gemeinsam mit den zuständigen Stellen festzulegen. Wenn der Pilot zeigt, wo Kontext fehlt und wo Kontrollen greifen müssen, lässt sich der nächste Schritt fundiert entscheiden. Das ist nachhaltiger, als entweder alles zu erlauben oder auf unbestimmte Zeit nichts zu ermöglichen.