Context-aware Authentication für KI-Agenten

Worum es geht

Context-aware Authentication prüft nicht nur, wer ein Agent ist. Jede sensitive Aktion wird zusätzlich an delegierenden Nutzer, Auftrag, Sitzung, Zielressource, Risiko und aktuelle Umgebung gebunden.

Der Kontrollpfad

1

Delegation binden

Nutzer, Agent und Auftrag verknüpfen

2

Identität belegen

Kurzlebige Workload-ID prüfen

3

Kontext bewerten

Risiko, Ziel und Sitzung vergleichen

4

Zugriff entscheiden

Erlauben, begrenzen oder eskalieren

Mögliche Folgen

Kontextgebundener Zugriff

Step-up

Blockiert

Statische API-Schlüssel verlieren Delegation und Kontext. Kurzlebige, zielgebundene Tokens reduzieren Wiederverwendung und begrenzen kompromittierte Läufe.

Die drei wichtigsten Maßnahmen

Schutzschicht 1

Eigene Workload-Identität

Gib jedem Agenten und Lauf eine nachweisbare, kurzlebige Identität statt gemeinsam genutzter Schlüssel.

Schutzschicht 2

Delegation erhalten

Übertrage Nutzer, Mandant, Zweck, erlaubte Tools und Zielressourcen als überprüfbare Claims.

Schutzschicht 3

Kontinuierlich neu bewerten

Erzwinge Step-up oder Re-Autorisierung bei Zielwechsel, erhöhtem Risiko oder ungewöhnlichem Verhalten.

Gestohlene oder fehlgeleitete Tokens sind kurzlebig, eng gebunden und außerhalb ihres Auftrags wenig nutzbar.

Drei Umsetzungsmuster

Token auf Server und Tool binden

MCP

Agent

Token Exchange

MCP-Tool

Das Token gilt nur für den ausgewählten Server, das konkrete Tool und eine kurze Laufzeit.

Mandant und Zweck prüfen

Daten

Delegation

Policy

Datensatz

Zugriff erfolgt nur, wenn Nutzer, Mandant, Datenklasse und Zweck zusammenpassen.

Bei Kontextwechsel neu autorisieren

High Risk

Anomalie

Step-up

Neuer Scope

Rechteänderungen, Exporte oder neue Zielsysteme erfordern frische Authentisierung und Freigabe.

Minimalstandard und Tests

Authentisierung und Autorisierung müssen außerhalb des Modells liegen. Prompttexte oder Modellbegründungen sind keine vertrauenswürdigen Identitätsnachweise.

Minimalstandard

• Agenten besitzen eigene, kurzlebige und rotierbare Workload-Identitäten.
• Delegierender Nutzer, Mandant, Auftrag und Sitzung bleiben nachvollziehbar.
• Tokens sind auf Audience, Scope, Zielressource und Laufzeit begrenzt.
• Sensitive Aktionen werden unmittelbar vor der Ausführung neu bewertet.
• Risikoänderungen lösen Step-up, Re-Autorisierung oder Blockierung aus.
• Entscheidung, Claims, Policy-Version und Zielressource werden protokolliert.

Testfälle müssen mindestens abdecken:

• Token-Replay, falsche Audience und abgelaufene Credentials
• Cross-Tenant-Zugriffe und verlorene Delegationskette
• Ziel-, Tool- oder Scope-Wechsel während eines Laufs
• kompromittierte Sitzung, ungewöhnlicher Ort und Rechteeskalation

Quellen

• NIST SP 800-207 – Zero Trust Architecture
• OAuth 2.0 Security Best Current Practice
• SPIFFE