TMF Catalyst: Trusted Agentic AI for Access Management

Überblick

Unter der Nummer C26.0.921 lief 2026 im TM Forum der Catalyst „Trusted Agentic AI for Access Management“. Beteiligt waren Vodafone Group, die Deutsche Telekom AG, Celfocus, die GIP Exyr GmbH und die Tallence AG. Die Leitfrage: Wie darf ein KI-Agent Zugriffsrechte in einem Telekommunikationsnetz verändern, ohne dass der Agent selbst zur Vertrauensinstanz wird?

Tallence lieferte die Antwort in Form von Digital Identity Management, der ODA-Komponente TMFC020, als Trust Anchor der Demo: die Stelle, an der jede Zugriffsentscheidung fällt, protokolliert wird und nachvollziehbar bleibt. Dazu kam der Legal Agent, der Gesetzestexte in Policy-Vorschläge übersetzt. Ich habe den Tallence-Beitrag als Ein-Personen-Team gebaut, von der Architektur über Terraform und die Python-Lambdas bis zu zwei React-Anwendungen und dem Agenten. Gezeigt wurde das Ergebnis zur DTW 2026; den Catalyst begleiteten dort ein Interview in Mobile Europe und veröffentlichte Statements von Vodafone und Deutsche Telekom.

Herausforderung

Telekommunikationsanbieter betreiben ihr Identitäts- und Zugriffsmanagement über viele Systeme hinweg. Zugriffsentscheidungen verteilen sich auf OSS, Netz und Werkzeugketten, und jede Regulierungsänderung erreicht diese Landschaft als Text, nicht als Konfiguration. Aus DSGVO, BDSG, Sicherheitsüberprüfungsgesetz und KRITIS-Dachgesetz wird eine durchsetzbare Regel erst, wenn jemand sie interpretiert und in ein Berechtigungssystem einträgt.

Genau dort entstehen die Kosten. Statisches RBAC folgt einer dynamischen Rechtslage nicht, manuelle Interpretation erzeugt Fehler und Verzögerungen, und was in einem System durchgesetzt wird, gilt im nächsten nicht. Die Folge sind Auditrisiken, unkontrollierter Zugriff auf kritische Infrastruktur und eine Änderungsgeschwindigkeit, die neue Dienste ausbremst.

Die eigentliche Hürde des Catalyst lag aber woanders. Ein Sprachmodell an ein Berechtigungssystem zu hängen ist einfach. Schwierig ist die Zusage, die ein Betreiber gegenüber seinem Auditor braucht: dass eine KI-vorgeschlagene Regeländerung deterministisch, nachvollziehbar und auditierbar bleibt, auch dann, wenn das Modell sich irrt oder manipuliert wird. Ein Agent, der Zugriffsrechte selbst entscheidet, ist genau das Gegenteil einer Kontrollinstanz.

Rolle

Ich habe den gesamten Tallence-Beitrag verantwortet und dabei drei Rollen parallel ausgefüllt:

• Product Owner: Use-Case-Schnitt mit den Partnern, Abgleich der erwarteten Entscheidungen, Demo-Drehbuch
• Architekt: Trust-Boundaries, Cedar-Schema, Gateway-Trennung, Datenresidenz und Least Privilege
• Full-Stack-Entwickler: Terraform-Module, Python-Lambdas, zwei React-SPAs, der Agent und die Pipeline

Der analystenseitige Legal Agent war zugleich mein Weg, jeden Winkel der Implementierung zu verstehen. Wer die Oberfläche baut, die eine Policy-Änderung auslöst, muss jeden Vertrag darunter kennen: das Token-Format, die Rollenprüfung, die Idempotenz eines Rollbacks, die Form der Impact-Analyse. Der Agent diente der Validierung der Use Cases und lieferte gleichzeitig den vollen Funktionsumfang, den die Demo brauchte.

Vorgehen

Ich habe die Autorisierung als Daten modelliert, nicht als Code. Ein Cedar-Schema in Amazon Verified Permissions beschreibt die Entitäten Operator und Customer mit ihren Attributen sowie die beiden Aktionen read und configure. Eine Baseline-Policy erlaubt Netzwerktechnikern den Zugriff, zwei zur Laufzeit erzeugte Forbid-Policies setzen die regulatorischen Einschränkungen darüber. Damit lässt sich die Autorisierungslogik ohne Deployment ändern, und die Entscheidung fällt in einer Policy-Engine, nicht in einem Prompt.

Vor die Lambdas habe ich zwei unabhängige AgentCore Gateways gesetzt, die als managed MCP-Server per Streamable HTTP und SigV4 erreichbar sind. Das Northbound-Gateway bewertet Zugriffe, einzeln und als Batch. Das Southbound-Gateway verändert Policies. Beide haben eigene Lambda-Rollen, eigene IAM-Consumer und eigene Tool-Schemata. Jede Entscheidung schreibt einen unveränderlichen Datensatz.

Die Identitäten liefert Keycloak auf ECS Fargate mit Aurora Serverless dahinter. Die ausgegebenen Token tragen die TMF672-Operator-Attribute, die Cedar als Principal-Attribute auswertet: Rolle, EU-Ansässigkeit, Clearance-Level und Land. Ein Audit-Frontend auf CloudFront und S3 macht die Entscheidungshistorie durchsuchbar.

Der Legal Agent läuft als Strands-Agent auf AgentCore Runtime, mit Server-Sent Events für den Stream. Claude Sonnet 4.6 wird ausschließlich über das EU-Inferenzprofil angesprochen. Die juristische Grundlage kommt aus einer Bedrock Knowledge Base mit S3 Vectors über vier Gesetzestexte, der Gesprächszustand aus AgentCore Memory. Für den Dokumenten-Pfad hängt an einem S3-Bucket eine EventBridge-Regel, die eine Step-Functions-Maschine startet: Diff-Hash gegen Doppelverarbeitung, Knowledge-Base-Ingestion, Dry-Run-Impact-Analyse, dann ein waitForTaskToken-Halt mit 24 Stunden Frist, bis ein Mensch entscheidet.

Vom Dokument zur Policy: Ingestion, Analyse, menschliche Freigabe, Anwendung

Die Infrastruktur liegt vollständig in Terraform, ausgerollt über GitLab CI/CD. Funktionale und Sicherheitstests wurden mit KICS, ruff, bandit, semgrep, pytest und Hypothesis realisiert.

Entscheidungen

Der Agent schlägt vor, die Policy-Engine entscheidet. Cedar-Policies in Verified Permissions sind die einzige Autorisierungsinstanz. Das Modell formuliert Vorschläge und Begründungen, aber kein Prompt und kein Tool-Aufruf kann eine Zugriffsentscheidung herbeiführen. Diese Trennung ist der Grund, warum die Demo überhaupt „trusted“ heißen darf.

Human-in-the-Loop als Architektureigenschaft, nicht als Prompt-Anweisung. Jede Änderung läuft zuerst als Dry-Run und braucht danach eine ausdrückliche Bestätigung. Zusätzlich ist die Service-Identität des Dokumenten-Workflows auf zwei Ebenen von zustandsändernden Aufrufen ausgeschlossen: im Agenten und unabhängig davon in der Rollenprüfung des Berechtigungssystems. Ein umgangener Prompt setzt damit trotzdem keine Policy.

Zwei Gateways statt eines. Der Agent bekommt ausschließlich den Southbound-Pfad. Er kann Regeln ändern, aber das Operator- und Berechtigungsinventar nicht durchsuchen. Das passt zur Rolle eines Legislation Analyst, der Vorgaben setzt und keine Nutzer inspiziert, und es begrenzt den Schaden eines kompromittierten Agenten auf einen Pfad, der ohne Freigabe nichts verändert.

Inferenz nur in der EU. Der Agent akzeptiert ausschließlich das EU-Inferenzprofil und verweigert den Start bei jedem anderen. Eine Demo, die Datenschutz-Compliance vorführt und dabei Daten aus der EU herausträgt, widerlegt sich selbst.

Die menschliche Identität reist mit. Das Keycloak-Token des Analysten wandert unverändert in den Southbound-Aufruf. Im Audit Trail steht damit die handelnde Person und nicht ein Servicekonto — der Unterschied zwischen einem Protokoll und einem Nachweis.

Function-URL-Streaming statt API Gateway für den Chat. HTTP-APIs konnten bis vor kurzem Antworten nicht streamen. Der Chat-Pfad läuft deshalb über eine Lambda Function URL im Streaming-Modus, same-origin hinter CloudFront mit Origin Access Control. Der Preis war eine einzige Node.js-Lambda in einem sonst durchgehend python-basierten Repository.

Ergebnisse

• Drei Regulierungs-Use-Cases end-to-end lauffähig: Baseline-RBAC, Datenresidenz nach DSGVO und BDSG, Closed User Group nach SÜG und KRITIS-Dachgesetz
• Zwei unabhängige AgentCore Gateways mit fünf MCP-Tools, nutzbar aus jedem MCP-fähigen Client
• Vier Gesetzestexte als RAG-Korpus, Begründungen mit wörtlichem Zitat und Quellenangabe statt frei formulierter Rechtsauskunft
• Unveränderlicher Audit Trail für jede Entscheidung, Dry-Run separat gekennzeichnet, Freigabefenster von 24 Stunden im Dokumenten-Workflow
• 100 Prozent der Infrastruktur in Terraform, Deployment über OIDC ohne langlebige AWS-Zugangsdaten
• Vollständig serverless in eu-central-1, kein einziger verwalteter Server außer den Fargate-Tasks des Identity Providers
• Vorführung im Rahmen des Catalyst zur DTW 2026