XSUAA bei AI-Calls – wer authentifiziert wen, wenn Claude antwortet
JWT vom User, API-Key zu Anthropic, Service-User für den Anonymizer – die Identity-Kette in einer CAP-App mit AI ist mehrschichtig. Wo XSUAA-Scopes greifen, wo Tech-User nötig sind, und wie Sie Audit-Spuren über alle drei Schichten hinweg erhalten.
Drei Identitäten in einem Call-Stack
Wenn Frau Müller im Browser einen Bug-Repro-Knopf klickt, der Claude befragt, sind drei Identitäten beteiligt:
- End-User (Frau Müller) – JWT von XSUAA, durch Approuter validiert
- Tech-User (BAMVP_AI_RW) – falls Claude auf CAP-Daten zugreifen muss, läuft das oft mit einem Service-User
- API-Caller (Anthropic API-Key) – der Schlüssel, mit dem Ihre CAP-App bei Anthropic anklopft
Diese Identitäten greifen in unterschiedlichen Phasen, und ein Architektur-Bug bei einer von ihnen reisst die Audit-Spur auf.
```mermaid sequenceDiagram participant U as User-Browser participant AR as Approuter participant CAP as CAP Backend participant XS as XSUAA participant AN as Anonymizer participant CL as Anthropic
U->>AR: GET /bug-repro (Cookie) AR->>XS: validate session XS-->>AR: JWT (sub: müller) AR->>CAP: forward + JWT CAP->>XS: check scope cap.bug-repro XS-->>CAP: scope ok CAP->>AN: GET sliced data (Tech-User) AN-->>CAP: anonymisierte slices CAP->>CL: POST /messages (API-Key + system prompt) CL-->>CAP: response CAP->>AR: response + audit-log entry AR-->>U: 200 OK ```
Schicht 1 – Der End-User-JWT
Frau Müller authentifiziert sich gegen Azure AD, das per SAML in SAP IAS fliesst, das wiederum den XSUAA-Token ausstellt. Der JWT enthält:
- sub (User-ID, audit-relevant)
- scope (z.B. cap.bug-repro, cap.read-anonymized)
- xs.user.attributes (z.B. business_unit, region)
Die Scope-Prüfung im CAP-Service ist Pflicht: nur User mit cap.bug-repro dürfen den AI-Call auslösen. Implementierung über @requires in CDS-Annotationen, durchgesetzt von @sap/cds-auth.
Schicht 2 – Der Tech-User für Daten-Zugriff
Wenn der CAP-Service intern auf den Anonymizer-Service zugreifen muss, läuft das nicht mit dem User-JWT (der hat dort keine Scopes), sondern mit einem dedizierten Tech-User wie BAMVP_AI_RW.
Dieser Tech-User: - hat JIT-aktivierbare Scopes (Standard: 4h-Window) - ist in jeder Subaccount-Instanz separat angelegt - wird im HANA Secure Store abgelegt, nicht in env-Variables - dessen Aktivität wird im Audit Log verlinkt mit dem ursprünglichen User-JWT
Das verlinken ist der Trick: ohne diese Verkettung sehen Sie im Audit-Log nur „BAMVP_AI_RW liest Daten“, nicht „BAMVP_AI_RW liest Daten, weil Müller den Bug-Repro-Knopf geklickt hat“. Die Verkettung passiert über request_id als Header in jedem internen Call.
Schicht 3 – Der Anthropic API-Key
Der API-Key ist eine pure Maschinen-Identität, ohne User-Bezug. Was Anthropic sieht: „Subscriber X hat um 14:23 ein Request mit 1200 Tokens geschickt“.
Was Ihr Audit-Log sehen muss: „Müller löste um 14:23 einen Anthropic-Call aus, mit Hash der User-Message X, Response-Token-Count Y.“ Diese Information loggen Sie selbst, vor und nach dem Call. Anthropic gibt keinen User-Bezug zurück.
API-Key-Rotation: alle 90 Tage, automatisiert über die Anthropic-Console-API, mit Zero-Downtime durch Doppel-Key-Pattern (alter Key bleibt 24h gültig).
Audit-Spur – die durchgängige Anforderung
Eine vollständige Audit-Spur für einen einzigen AI-Call enthält:
1. User-JWT-Sub (Müller)
2. CAP-Endpoint (/api/bug-repro/start)
3. CAP-Internal-Call zu Anonymizer mit Tech-User (BAMVP_AI_RW)
4. Anonymisierten Slice (Hash, nicht Inhalt)
5. Anthropic-Call mit API-Key-Identifier (z.B. last 4 chars)
6. Response-Token-Usage
7. CAP-Response zum User
Alle 7 Einträge teilen die request_id. Ohne diese ID ist die Spur unbrauchbar.
Was bei Audit-Anfragen passiert
Wenn der DPO oder eine Aufsichtsbehörde fragt „welche AI-Anfragen hat Müller in Q1 ausgelöst?“, gibt es zwei mögliche Antworten:
Schlecht: „Wir haben Logs, aber müssen 5 Systeme korrelieren.“
Gut: „Hier ist der Audit-Export. 47 Anfragen, alle mit anonymisierten Daten, hier die Hashes.“
Der Unterschied ist die durchgängige request_id und die Tech-User-Verlinkung.
Wer das in 30 Min ordnen will
Ein Architektur-Review (30 Min) zeichnet Ihre aktuelle Identity-Kette nach und identifiziert die Lücken in der Audit-Spur. Konkretes Output: Zwei-Seiten-Befund mit Lücken-Liste.
Stand: 2026-05-10
