Warum Agenten eine Zugriffskontrolle brauchen

Die meisten Teams führen Agenten gleich ein: Eine Entwicklerin fügt ihrem Editor einen MCP-Server hinzu, kopiert einen API-Key in eine Konfigurationsdatei und erledigt an einem Nachmittag etwas Nützliches. Dann macht ein Kollege dasselbe mit einem anderen Key. Sechs Monate später kann niemand eine einfache Frage des Security-Teams beantworten: Welche Agenten haben Zugriff auf Produktionsdaten, und wer hat ihn erteilt?

Das Wildwuchs-Problem

Jeder MCP-Server auf einem Laptop ist eine eigene Vertrauensentscheidung, mit eigenen Zugangsdaten, eigenem Umfang und eigenem Logging, falls überhaupt. Multipliziert mit allen Entwicklern, Tools und Projekten ergibt das:

• langlebige Zugangsdaten verstreut über viele Rechner,
• keinen zentralen Ort, um Zugriffe beim Austritt zu entziehen,
• keine Aufzeichnung dessen, was ein Agent tatsächlich getan hat.

Ein Endpunkt, viele Berechtigungen

Eine Control Plane dreht das Modell um. Agenten verbinden sich mit einem MCP-Endpunkt. Dahinter registrieren Administratoren Tools, MCP-Server, Skills, Datenbanken und APIs einmal und vergeben sie an Rollen, Teams und Projekte. Listet der Agent eines Mitglieds seine Tools, sieht er nur, was dieses Mitglied nutzen darf.

Secrets bleiben auf dem Server. Der Agent möchte query_orders ausführen; das Gateway setzt die Datenbank-Zugangsdaten ein, führt den Aufruf aus und gibt das Ergebnis zurück. Der Klartext erreicht das Modell nie.

Guard-Regeln und Audit

Berechtigungen beantworten, wer was nutzen darf. Guard-Regeln beantworten, was niemals passieren darf: in natürlicher Sprache formuliert und vor jeder Aktion geprüft. Und weil jeder Aufruf durch einen Punkt läuft, landet jeder Aufruf in einem unveränderlichen, per Hash verketteten Audit-Log, dem Ihre Auditoren vertrauen können.

Das ist der Unterschied zwischen Agenten als Nebenprojekt und Agenten als Teil Ihrer Produktionslandschaft.