Sicherheitsmodell

Agentenfähig bedeutet nicht unkontrolliert. Ein MCP-first System beschreibt jede Fähigkeit maschinenlesbar, und legt gleichzeitig fest, wer sie aufrufen darf, unter welchen Bedingungen, und welche Spuren dabei entstehen. Sicherheit ist kein nachträglicher Zusatz, sondern Teil des Capability-Designs.

Sechs Autorisierungsebenen

Authentifizierung beantwortet: Wer bist du? Autorisierung beantwortet: Was darfst du tun? Ein MCP-first System braucht beide Fragen, und beantwortet sie auf sechs voneinander unabhängigen Ebenen, die gemeinsam den effektiven Zugriff bestimmen.

Ebene 1: User Role

Die Rolle des eingeloggten Benutzers bildet die breiteste Ebene. Sie bestimmt grundsätzliche Zugriffsklassen, nicht einzelne Tools.

admin
manager
employee
viewer
external_client

Ebene 2: Tenant Scope

In Multi-Tenant-Systemen muss jeder Zugriff mandantengebunden sein. Kein Agent darf tenantübergreifend lesen oder schreiben, auch wenn seine Benutzerrolle dies technisch erlauben würde.

tenant:abc
project:123
contact:456

Ebene 3: Tool Scope

Jedes Tool ist mit eigenen Scopes abgesichert. Ein Agent erhält ausschließlich die Scopes, die für seine definierte Aufgabe notwendig sind.

contacts:read
contacts:write
projects:read
projects:write
files:read
files:write
emails:draft
emails:send
calendar:create
billing:read
billing:write
admin:users
admin:security

Ebene 4: Resource Scope

Über Tool-Scopes hinaus kann der Zugriff auf einzelne Resource-Typen beschränkt werden. Damit ist sichergestellt, dass ein Agent mit contacts:read trotzdem nicht jede Kontaktressource einsehen kann.

resource.project.visible
resource.contact.visible
resource.employee.visible
resource.file.downloadable
resource.email.readable

Ebene 5: Risk Level

Jedes Tool trägt eine deklarierte Risikostufe. Diese Stufe fließt in die Confirmation Policy und die Audit-Konfiguration ein.

Ebene 6: Confirmation Policy

Die Confirmation Policy legt fest, welche Zusatzhürde vor der Ausführung genommen werden muss. Sie wird pro Tool konfiguriert und vom Policy Layer erzwungen, nicht vom Agent selbst.

no_confirmation_required
confirmation_required
step_up_auth_required
admin_approval_required
four_eyes_required
not_allowed_for_ai

Tool-Sichtbarkeit

Ob ein Tool existiert, ist bereits eine sicherheitsrelevante Information. Ein Agent, der ein verbotenes Tool kennt, kann es als Angriffsfläche nutzen, auch wenn der spätere Aufruf blockiert würde.

Ein Sales Assistant erhält zum Beispiel folgende gefilterte Tool-Liste:

Human-in-the-loop

MCP-first heißt nicht vollautomatisch. Es heißt vollständig steuerbar, aber kontrolliert. Bei sensiblen oder riskanten Aktionen unterbricht das System den Agenten und holt aktiv die Zustimmung des Benutzers ein.

Der Agent erkennt anhand der deklarierten Risk-Metadaten, dass eine Aktion menschliche Freigabe benötigt, und übergibt die Kontrolle. Erst nach expliziter Bestätigung wird das Tool ausgeführt.

Das folgende Beispiel zeigt einen typischen Freigabedialog für den Massenversand externer E-Mails, eine der häufigsten kritischen Agentenaktionen:

Step-up Authentication

Für besonders sensible Aktionen reicht eine aktive Session nicht aus. Selbst ein eingeloggter Administrator muss seine Identität neu bestätigen, bevor kritische Operationen ausgeführt werden.

Typische Auslöser für Step-up Auth:

• Admin-Rechte ändern oder vergeben
• Zahlungsdaten oder Abonnement ändern
• Gehaltsdaten oder Payroll-Exporte
• API Keys erzeugen oder rotieren
• Vollständige Datenexporte
• Benutzer oder Mandanten löschen

Akzeptierte Step-up-Methoden (je nach Systempolicy):

Erneute Passwortabfrage
TOTP / Authenticator-App
Passkey
Admin-Freigabe durch zweite Person
4-Augen-Prinzip

Consent Ledger

Jede Zustimmung zu einer Agentenaktion ist ein Ereignis, das dauerhaft gespeichert werden sollte. Der Consent Ledger ermöglicht es, im Nachhinein nachzuvollziehen, welche Aktion von wem, für welchen Umfang und mit welcher Sicherheitsmethode genehmigt wurde.

Gespeicherte Felder eines Consent-Eintrags:

consentId, eindeutige ID der Zustimmung
userId, genehmigender Benutzer
agentId, handelnder Agent
clientId, verbundener MCP-Client
toolName, aufgerufenes Tool
inputSummary, strukturierte Zusammenfassung der Eingaben (kein Klartext)
riskLevel, deklarierte Risikostufe des Tools
approvedAt, Zeitstempel der Freigabe
expiresAt, Gültigkeit der Freigabe (falls zeitlich begrenzt)
approvalMethod, verwendete Freigabemethode (z. B. "totp", "passkey", "manual")

Manche Freigaben können zeitlich begrenzt gültig sein, etwa eine einmalige Genehmigung für einen konkreten Versand. Andere gelten für eine Session oder einen konfigurierten Zeitraum. Die Policy bestimmt die Granularität.

Audit Trail

Jede MCP-Aktion erzeugt einen Audit-Eintrag. Dieser Eintrag ist unveränderlich, mandantengebunden und maschinell auswertbar. Er bildet die Grundlage für Compliance-Nachweise, Anomalie-Erkennung und interne Reviews.

{
  "event": "mcp.tool.executed",
  "tool": "emails.send_external",
  "tenantId": "tenant_123",
  "userId": "user_456",
  "agentId": "agent_sales_assistant",
  "clientId": "client_claude_desktop",
  "riskLevel": "critical",
  "confirmationId": "confirm_789",
  "inputHash": "sha256:a3f2c1...",
  "result": "success",
  "createdAt": "2026-06-11T10:00:00Z"
}

Das Audit-Log lässt sich maschinell auf Anomalien überwachen: ungewöhnliche Ausführungsfrequenzen, Aktionen außerhalb der üblichen Arbeitszeiten oder Zugriffe auf Scopes, die ein Agent normalerweise nicht nutzt, all das ist erkennbar, weil jede Aktion sauber typisiert und auditiert ist.