ti20.ai · eine Produktlinie von Borchert IT-Consulting
KI-Assistenten rufen Werkzeuge auf.
Wer entscheidet, was sie dürfen?
ti20.ai ist der semantische Policy Enforcement Point zwischen KI-Agent und Fachdienst: Es prüft jeden MCP-Werkzeugaufruf — Werkzeug und Argumente — gegen ZETA-konforme Richtlinien, verleiht Agenten über Token-Austausch kurzlebige, zweckgebundene Identitäten und protokolliert jede Entscheidung in einer prüfbaren Hash-Kette.
Die Lücke
gemSpec_ZETA kennt Menschen auf attestierten Geräten (Stufe 1) und Versicherte mit Wallet (Stufe 2) — aber keine Agenten, die für eine Ärztin handeln. ZETA autorisiert zur Token-Zeit und prüft danach HTTP-Anfragen; ein MCP-Werkzeugaufruf ist ein POST mit beliebigem Inhalt: welches Werkzeug, welche PZN, welcher Behandlungskontext, bleibt unsichtbar. Hersteller, die heute Copiloten ausliefern, geben ihnen das volle Nutzer-Token — nicht aus Leichtsinn, sondern weil es keinen spezifizierten Weg gibt.
Drei Bausteine — alle aus ZETA-Bordmitteln
RFC 8693 Token-Austausch: die Ärztin bleibt sub, der Agent ist azp. Zweckgebunden, ≤ 300 s, DPoP-gebunden, kein Refresh-Token.
Terminiert MCP, versteht den Werkzeugaufruf, fragt den PDP je Aufruf. Verweigerungen tragen die Begründung der Richtlinie — wörtlich.
Jede Entscheidung als Glied einer Hash-Kette, Argumente nur als Hash. Ein Prüf-Endpunkt statt eines Versprechens.
So sieht es aus
POST /mcp/pharma · DPoP-Agent-Token (sub = Ärztin, azp = ti20-agent, purpose = pharma-lookup) tools/call get_fachinformation {"pzn":"01551110"} → 200 allowed by policy tools/call get_fachinformation {"pzn":"04444444"} → 403 get_fachinformation: PZN 04444444 outside licensed set tools/call search_concept {"term":"Herzinsuffizienz"} → 403 purpose "pharma-lookup" not admitted for tool "search_concept" Authorization: Bearer … (kein DPoP-Nachweis) → 401 GET /audit/verify → {"entries": 4, "valid": true, "head": "b607…"}
Der Demo-Upstream „pharma" antwortet aus einem synthetischen Datensatz; die Werkzeuge sind read-only.
Endpunkte verlangen Agent-Token aus dem Realm ti20 auf auth.ti20.io — öffentlich ist nur diese Seite.
Was offen ist — und was folgt
Ein Ergänzungsvorschlag zu gemSpec_ZETA in gemSpec-Notation (Agent-Token-Profil, Anforderungen an den semantischen PEP, Policy-Input-Dokument) und ein Positionspapier liegen vor und werden mit der gematik diskutiert. Profil und Referenz-Gateway werden unter offener Lizenz veröffentlicht, sobald sie den dafür nötigen Reifegrad haben; das gehärtete Gateway, Policy-Pakete je Domäne und Integration sind das Produkt. Attestierung der Agenten-Laufzeit und Rückkanal-Filterung sind benannte offene Punkte.