APIs, MCP und vernetzte KI-Systeme

Wie KI sicher und zuverlässig mit CRM, ERP, E-Mail, Dateien, Datenbanken und anderen Diensten verbunden wird

Fakten- und Recherchestand: 8. August 2026 Version: 1.0 Autor: Andreas Rüdiger Räumlicher Schwerpunkt: Deutschland / Europäische Union; technische Standards international Zielgruppe: Unternehmer, Entscheider, Integrationsverantwortliche, Vibe Coder, Entwickler, Berater und Projektverantwortliche Quellenbasis: 213 dokumentierte Standards, RFCs, Behörden-, Forschungs-, Produkt- und Incidentquellen Vorgesehener Dateiname: 16_apis-mcp-und-vernetzte-ki-systeme-faktendossier_2026-08-08

Auftrag, Reichweite und Kernbegriffe

AUFTRAG: Untersuchungsgegenstand sind Integrationen, in denen klassische Software, Datenbanken, SaaS-Dienste, Ereignisse, KI-Modelle und gegebenenfalls Agenten zusammenwirken. Bewertet werden Vertrag, Transport, Identität, Berechtigung, Datenqualität, Seiteneffekt, Fehlerverhalten, Beobachtbarkeit, Datenschutz und Betrieb. ^{[S-002; S-021; S-074; S-054; S-066]}

Arbeitsdefinitionen

Integration

Dauerhaft betriebener Vertrag zwischen Systemen, Identitäten und Datenzuständen; nicht nur ein erfolgreicher Testaufruf. ^{[S-021; S-001]}

System of Record

Verbindlicher Datenhalter für ein Objekt oder Feld; abgeleitete KI-Ausgaben werden davon getrennt. ^{[S-099; S-002]}

Tool Calling

Modell erzeugt einen strukturierten Aufrufvorschlag; die Anwendung validiert, autorisiert und führt aus. ^{[S-082; S-083; S-084]}

MCP

Offenes Protokoll zwischen Hosts/Clients und Servern zur Bereitstellung von Tools, Ressourcen, Prompts und weiteren Fähigkeiten. ^{[S-100; S-087]}

A2A

Protokoll zur Zusammenarbeit eigenständiger Agenten über Agent Cards, Tasks, Messages und Artifacts. ^{[S-208; S-211]}

Reconciliation

Nachträglicher Soll-Ist-Abgleich, der verlorene, doppelte, verspätete oder inkonsistente Änderungen erkennt und korrigierbar macht. ^{[S-187; S-046]}

Management Summary

Kernbefund: Eine belastbare KI-Integration ist keine Kette aus Prompt und API-Key. Sie ist ein kontrollierter Geschäftsvorgang mit eindeutigen Datenhaltern, minimalen Rechten, validierten Verträgen, begrenzter KI-Rolle, idempotenten Seiteneffekten, menschlichen oder technischen Freigaben, Wiederabgleich und betrieblicher Verantwortlichkeit. ^{[S-002; S-074; S-044; S-008; S-046]}

Architektur- und Entscheidungsmodell

ARCHITEKTUR-SYNTHESE: Eine Integrationsarchitektur wird belastbar, wenn jede Schicht eine klar begrenzte Aufgabe besitzt und ein Fehler der KI-Schicht nicht automatisch zu unkontrollierter Außenwirkung führt. ^{[S-001; S-008; S-033]}

Abbildung: Abbildung 1: Integrationslandkarte. Eigene Synthese zu direkter API, Webhook/Event, Queue/Stream, MCP und A2A auf Basis der jeweiligen offenen Spezifikationen. ^{[S-023; S-025; S-134; S-100; S-208]}

Schichtenmodell

Abbildung: Abbildung 2: Vertrauenszonen und System of Record. Eigene Architektur-Synthese; die KI-Schicht wird von autorisierter Geschäftswirkung getrennt. ^{[S-074; S-008; S-099]}

Entscheidungsmatrix für Integrationsmuster

Zuverlässigkeitskette

Abbildung: Abbildung 3: Ein 200-Statuscode belegt nur einen technischen Teilschritt. Geschäftserfolg verlangt validierte Wirkung, Nachweis und Wiederabgleich. ^{[S-023; S-044; S-049]}

Prüfregel: Für jede schreibende Aktion muss vorab beantwortet sein: Wer darf sie auslösen? Auf welches konkrete Objekt? Mit welcher Version? Wie wird ein Duplikat erkannt? Wie wird ein Teilfehler sichtbar? Wie wird die Wirkung geprüft, begrenzt, gestoppt oder kompensiert? ^{[S-032; S-098; S-044; S-052]}

MCP 2026-07-28 in der Architektur

Abbildung: Abbildung 4: MCP-Architektur mit Host, Clients und Servern. Eigene Darstellung auf Basis der Spezifikation 2026-07-28. ^{[S-087; S-102; S-103]}

86 belastbare Kernaussagen

Die Aussagen sind bewusst atomar formuliert. Jede Aussage trägt einen Status und unmittelbar zugeordnete Quellen-IDs.

Integration beginnt beim Geschäftsvorgang, nicht beim Protokoll

FAKTENBEFUND: Vor der Auswahl von REST, Webhook, MCP oder A2A müssen Auslöser, gewünschte Geschäftswirkung, zuständiges System, zulässige Daten, Fehlerfolgen und Verantwortliche feststehen. Eine technisch erfolgreiche Übertragung ist kein Nachweis dafür, dass der Geschäftsvorgang richtig, vollständig oder rechtzeitig abgeschlossen wurde. ^{[S-002; S-001; S-137]}

Das System of Record bleibt maßgeblich

FAKTENBEFUND: Ein LLM, ein Agent oder ein Workflow-Tool sollte nicht stillschweigend zum führenden Datenbestand werden. Für Kunden, Preise, Aufträge, Verträge und Buchungen muss feststehen, welches System den verbindlichen Zustand hält und wie abgeleitete Speicher mit ihm abgeglichen werden. ^{[S-099; S-098; S-004]}

Lesen, Entscheiden und Schreiben sind getrennte Risikostufen

FAKTENBEFUND: Eine Integration, die Daten nur liest, hat andere Folgen als eine, die Vorschläge erzeugt, Datensätze ändert, E-Mails versendet oder Zahlungen anstößt. Berechtigungen, Freigaben, Tests und Audit müssen sich an der maximalen Außenwirkung orientieren. ^{[S-032; S-033; S-008]}

KI ersetzt keine Integrationsschicht

FAKTENBEFUND: Modelle liefern probabilistische Ausgaben. Authentisierung, Autorisierung, Schema- und Geschäftsregelprüfung, Idempotenz, Transaktionen, Wiederholungen und Audit gehören deshalb in deterministische Software rund um das Modell. ^{[S-085; S-083; S-084; S-008]}

Die kleinste tragfähige Architektur ist meist die beste

FAKTENBEFUND: Ein einzelner synchroner API-Aufruf kann angemessen sein, wenn Latenz, Verfügbarkeit und Fehlerwirkung begrenzt sind. Queue, Event Bus, Workflow Engine, MCP oder A2A sind erst dann gerechtfertigt, wenn sie ein konkretes Problem wie Entkopplung, Wiederaufnahme, Standardisierung oder Agentenkooperation lösen. ^{[S-023; S-053; S-001]}

Integrationsverträge brauchen fachliche Semantik

FAKTENBEFUND: Feldnamen und Datentypen genügen nicht. Ein Vertrag muss beispielsweise klären, ob ein Betrag netto oder brutto ist, welche Zeitzone gilt, ob eine Löschung physisch oder logisch erfolgt und wie Statusübergänge zu interpretieren sind. ^{[S-021; S-022; S-002]}

Schnittstellen sind langlebige Produkte

FAKTENBEFUND: Sobald mehrere Systeme oder Teams von einer API, einem Event oder einem MCP-Server abhängen, entstehen Eigentum, Support, Versionierung, Sicherheits- und Abschaltpflichten. Der Aufwand endet nicht mit der ersten funktionierenden Verbindung. ^{[S-004; S-006; S-005]}

Point-to-Point-Verbindungen skalieren organisatorisch schlecht

FAKTENBEFUND: Viele direkte Sonderverbindungen vervielfachen Verträge, Secrets, Fehlerpfade und Abhängigkeiten. Ein Gateway, Integrationsdienst, Event Bus oder klarer Adapter kann Komplexität bündeln, darf aber nicht zu einem undokumentierten Monolithen werden. ^{[S-001; S-137; S-046]}

Datenminimierung gilt auch für technische Integrationen

FAKTENBEFUND: Nur weil ein API-Scope oder ein Export technisch verfügbar ist, darf nicht automatisch der gesamte Datenbestand in eine KI- oder Automationskette gelangen. Zweck, Rechtsgrundlage, Rollen und technische Schutzmaßnahmen müssen vorab bestimmt werden. ^{[S-066; S-068; S-077]}

Mandanten- und Kontextgrenzen müssen technisch erzwungen werden

FAKTENBEFUND: Ein Mandantenkennzeichen im Prompt ist keine Zugriffskontrolle. Datenbankabfragen, Toolparameter, Tokens und Serverautorisierung müssen verhindern, dass ein Nutzer oder Agent auf fremde Mandanten, Postfächer oder Datensätze zugreift. ^{[S-032; S-027; S-106]}

Ein Integrationsinventar ist eine Kontrollgrundlage

FAKTENBEFUND: Für jede Verbindung sollten Eigentümer, Zweck, Datenarten, Endpunkte, Identitäten, Scopes, Secrets, Versionen, Limits, Abhängigkeiten, SLO, Alarmierung und Abschaltweg dokumentiert sein. Ohne Inventar bleiben Schattenintegrationen und verwaiste Tokens unentdeckt. ^{[S-014; S-009; S-004]}

Exit und Abschaltung gehören zum Entwurf

FAKTENBEFUND: Providerwechsel, gekündigte Apps, abgelaufene Tokens, deaktivierte Nutzer oder stillgelegte Systeme dürfen keine unkontrollierten Datenkopien und dauerhaft gültigen Zugänge hinterlassen. Revoke, Datenlöschung, Export, Deinstallation und Nachweis sind Teil des Lebenszyklus. ^{[S-150; S-066; S-003]}

HTTP-Methoden und Statuscodes haben Semantik

FAKTENBEFUND: GET, POST, PUT, PATCH und DELETE sind nicht bloß technische Varianten. Sicherheit, Idempotenz, Cachebarkeit und Wiederholbarkeit hängen von der gewählten Methode und der konkreten Implementierung ab. Fehlermeldungen sollten maschinenlesbar und für Clients handhabbar sein. ^{[S-023; S-024]}

OpenAPI beschreibt Verträge, nicht die tatsächliche Implementierung

FAKTENBEFUND: Eine OpenAPI-Datei kann Endpunkte, Schemata, Authentisierung und Antworten dokumentieren. Sie beweist jedoch weder, dass der Server die Beschreibung einhält, noch dass Geschäftsregeln, Autorisierung oder Fehlerfälle korrekt umgesetzt sind. ^{[S-021; S-011]}

Arazzo kann mehrstufige API-Abläufe beschreiben

FAKTENBEFUND: Arazzo 1.1.0 ergänzt einzelne API-Beschreibungen um Workflows, Abhängigkeiten und Ausgaben mehrerer Aufrufe. Es ist damit für agentische oder automatisierte Sequenzen nützlich, ersetzt aber keine Laufzeitsteuerung, Freigabe oder Kompensation. ^{[S-119; S-021]}

JSON Schema begrenzt Form, nicht Wahrheit

FAKTENBEFUND: Ein Schema kann Pflichtfelder, Typen, Wertebereiche und Strukturen prüfen. Es kann nicht von sich aus feststellen, ob ein Kunde existiert, ein Preis zulässig ist oder ein Modell einen Text inhaltlich korrekt interpretiert hat. ^{[S-022; S-085; S-086]}

Structured Outputs reduzieren Syntaxfehler, nicht Geschäftsrisiken

FAKTENBEFUND: Schema-konforme Modellausgaben erleichtern Parsing und Validierung. Sie beseitigen weder Halluzinationen noch falsche Zuordnung, fehlende Quellen, unzulässige Aktionen oder fehlerhafte Werte innerhalb eines formal gültigen Schemas. ^{[S-085; S-086; S-163]}

GraphQL verlagert Abfrageflexibilität zum Client

FAKTENBEFUND: GraphQL erlaubt Clients, benötigte Felder aus einem typisierten Schema auszuwählen. Das kann Overfetching reduzieren, erhöht aber Anforderungen an Autorisierung auf Feld- und Objektebene, Abfragekomplexität, Limits und Beobachtbarkeit. ^{[S-122; S-038; S-124]}

gRPC eignet sich besonders für stark typisierte Servicekommunikation

FAKTENBEFUND: Protocol Buffers und generierter Code unterstützen performante, sprachübergreifende Verträge sowie Streaming. Browserzugang, Debugging, Gateway-Kompatibilität und öffentliche Partnerintegration können jedoch zusätzlichen Aufwand erfordern. ^{[S-125; S-126; S-127]}

OData ist in Unternehmenssystemen verbreitet, aber kein Sicherheitsmodell

FAKTENBEFUND: OData standardisiert Abfragen und Operationen über Datenmodelle. Filter, Expansion und Navigation müssen trotzdem limitiert und autorisiert werden; insbesondere SAP- und Dataverse-Integrationen verlangen fachliche Kenntnis des jeweiligen Objektmodells. ^{[S-128; S-196; S-027]}

Fehlerantworten brauchen stabile Kategorien

FAKTENBEFUND: Clients müssen unterscheiden können, ob eine Anfrage ungültig, nicht autorisiert, gedrosselt, vorübergehend fehlgeschlagen oder fachlich abgelehnt wurde. Einheitliche Problem-Details verbessern Automatisierung und Support, solange sensible Interna nicht offengelegt werden. ^{[S-024; S-037; S-031]}

Versionierung ist mehr als eine Versionsnummer

FAKTENBEFUND: Kompatibilität hängt von Feldern, Bedeutungen, Defaults, Fehlercodes, Scopes und Verhalten ab. Deprecation-Hinweise, Sunset-Planung, Migrationspfad, Parallelbetrieb und Consumer-Tests sind wichtiger als die Frage, ob die Version im Pfad oder Header steht. ^{[S-006; S-138; S-139]}

Verbraucherseitige Vertragstests erkennen Integrationsbrüche früh

FAKTENBEFUND: Tests sollten reale Erwartungen von Clients gegen Providerverträge prüfen. Sie ersetzen keine End-to-End-Tests, reduzieren aber das Risiko, dass eine formal kleine API-Änderung bestehende Automationen unbemerkt zerstört. ^{[S-011; S-016; S-001]}

Paginierung und inkrementeller Abgleich sind Pflicht bei wachsenden Datenmengen

FAKTENBEFUND: Vollständige Listenabfragen werden mit zunehmender Datenmenge langsam, teuer und fehleranfällig. Cursor, Delta-Token, Change Feeds und gespeicherte Fortsetzungsstände ermöglichen belastbare Synchronisation, erfordern aber Ablauf- und Neuaufbaulogik. ^{[S-187; S-193; S-179]}

Zeit, Zeitzonen und Reihenfolge sind Teil des Datenvertrags

FAKTENBEFUND: Zeitstempel brauchen Format, Zeitzone und Bedeutung. Ein später eingetroffenes Ereignis kann fachlich älter sein; verteilte Systeme benötigen deshalb Versions-, Sequenz- oder Änderungskennzeichen statt alleiniger Sortierung nach Empfangszeit. ^{[S-025; S-171; S-181]}

Dateien brauchen Metadaten, Prüfsummen und Lebenszyklusregeln

FAKTENBEFUND: Dateiinhalte allein reichen nicht. MIME-Typ, Größe, Eigentümer, Virenprüfung, Herkunft, Prüfsumme, Version, Aufbewahrung und Löschung bestimmen, ob ein Dokument sicher verarbeitet und später nachgewiesen werden kann. ^{[S-182; S-183; S-035]}

API Keys identifizieren meist eine Anwendung, nicht automatisch einen Nutzer

FAKTENBEFUND: Ein Schlüssel ist für einfache Server-zu-Server-Szenarien möglich, trägt aber häufig keine feingranulare Nutzereinwilligung oder Delegation. Er muss wie ein Geheimnis behandelt, begrenzt, überwacht und rotierbar sein. ^{[S-030; S-027; S-041]}

OAuth ist Delegation, nicht pauschal Authentisierung

FAKTENBEFUND: OAuth 2.0 regelt den begrenzten Zugriff eines Clients auf geschützte Ressourcen. Nutzeranmeldung wird typischerweise über OpenID Connect ergänzt. Access Token, ID Token und Refresh Token dürfen nicht als austauschbar behandelt werden. ^{[S-072; S-156; S-141]}

Authorization Code mit PKCE ist der Regelfall für öffentliche Clients

FAKTENBEFUND: PKCE bindet den Autorisierungscode an den anfragenden Client und erschwert Code-Interception. Aktuelle OAuth-Sicherheitsempfehlungen verwerfen unsichere historische Muster wie den Implicit Grant für neue Implementierungen. ^{[S-073; S-074; S-140]}

OAuth 2.1 ist am Stichtag noch ein Entwurf

FAKTENBEFUND: Der Internet-Draft bündelt moderne Sicherheitspraktiken, ist am 8. August 2026 jedoch kein veröffentlichter RFC. Architekturen sollten sich auf bestehende normative RFCs und aktuelle Sicherheits-Best-Practices stützen und den Entwurfsstatus offen benennen. ^{[S-140; S-074]}

Scopes sind grobe Berechtigungsgrenzen, keine vollständige Objektprüfung

FAKTENBEFUND: Ein Token mit CRM-Schreibscope bedeutet nicht, dass jeder Datensatz oder jedes Feld bearbeitet werden darf. Der Ressourcenserver muss zusätzlich Mandant, Eigentümer, Rolle, Objekt und konkreten Vorgang autorisieren. ^{[S-072; S-032; S-027]}

Token-Passthrough verletzt Sicherheitsgrenzen

FAKTENBEFUND: Ein MCP- oder Integrationsserver darf ein für ihn ausgestelltes Token nicht ungeprüft an nachgelagerte Dienste weiterreichen. Audience, Ressource und Berechtigungsumfang müssen zum Ziel passen; andernfalls entstehen Confused-Deputy- und Nachweisprobleme. ^{[S-106; S-144; S-154]}

Token Exchange kann Identitätsketten kontrolliert abbilden

FAKTENBEFUND: RFC 8693 ermöglicht den Austausch eines Tokens gegen ein anderes für eine definierte Ressource oder Delegationsbeziehung. Das ist kein Freibrief: Policy, Audience, Laufzeit, Claims und Audit müssen die tatsächliche Vertrauenskette begrenzen. ^{[S-148; S-075]}

Proof-of-Possession reduziert den Wert gestohlener Bearer Tokens

FAKTENBEFUND: mTLS-gebundene Tokens oder DPoP können Tokens an einen Schlüssel binden. Sie erhöhen Implementierungskomplexität, schützen aber besser als reine Bearer Tokens, die von jedem Besitzer verwendet werden können. ^{[S-146; S-147; S-141]}

Refresh Tokens verdienen stärkeren Schutz als kurzlebige Access Tokens

FAKTENBEFUND: Mit Refresh Tokens lassen sich neue Access Tokens beziehen. Rotation, Bindung, Widerruf, sichere Speicherung und Erkennung von Wiederverwendung sind deshalb zentrale Kontrollen, insbesondere bei dauerhaft verbundenen Apps. ^{[S-074; S-150; S-030]}

Secrets gehören nicht in Prompts, Code oder Workflow-Exports

FAKTENBEFUND: API Keys, Client Secrets, private Schlüssel und Tokens müssen in dafür vorgesehenen Secret Stores mit Zugriffstrennung, Rotation und Audit liegen. Maskierung in Logs allein verhindert keine Exfiltration durch Fehlkonfiguration oder Toolzugriff. ^{[S-030; S-017; S-204]}

Servicekonten brauchen eigenen Lebenszyklus

FAKTENBEFUND: Nichtmenschliche Identitäten benötigen Eigentümer, Zweck, minimale Rechte, Ablauf- oder Rotationsregeln, Überwachung und Abschaltung. Gemeinsame Dauerzugänge erschweren Zuordnung und werden häufig nach Projektende vergessen. ^{[S-014; S-009; S-041]}

MFA schützt nicht vor jeder Kontenübernahme

FAKTENBEFUND: Social Engineering, Sessiondiebstahl, kompromittierte Recovery-Prozesse oder gestohlene OAuth-Tokens können MFA umgehen. Hochwirksame Integrationen brauchen phishing-resistente Verfahren, Sessionkontrollen, Kontextprüfung und schnelle Tokenrotation. ^{[S-071; S-205; S-202]}

Webhooks werden grundsätzlich mindestens einmal gedacht

FAKTENBEFUND: Provider können Ereignisse erneut zustellen, wenn eine Antwort ausbleibt oder unklar ist. Empfänger müssen Duplikate anhand einer stabilen Ereignis- oder Vorgangs-ID erkennen und den fachlichen Seiteneffekt idempotent machen. ^{[S-076; S-045; S-044]}

Ein Webhook sollte schnell angenommen und später verarbeitet werden

FAKTENBEFUND: Signatur, Zeitfenster und minimale Formvalidierung können am Eingang erfolgen; aufwendige KI-, Datei- oder CRM-Schritte gehören typischerweise hinter eine Queue. So sinkt das Risiko von Provider-Timeouts und Zustellwiederholungen. ^{[S-185; S-076; S-169]}

Webhook-Signaturen brauchen Rohdaten und Replay-Schutz

FAKTENBEFUND: Die Signaturprüfung muss dem vom Provider definierten Verfahren folgen und häufig über den unveränderten Request-Body erfolgen. Zeitstempel, Nonce oder Ereignis-ID begrenzen Replay; TLS ersetzt die Nachrichtenauthentisierung nicht vollständig. ^{[S-136; S-131; S-076]}

Queues entkoppeln Verfügbarkeit und Last

FAKTENBEFUND: Ein Produzent kann Arbeit ablegen, ohne auf die vollständige Verarbeitung zu warten. Sichtbarkeits-Timeouts, Acknowledgements, Retention, Dead-Letter-Queues und maximale Wiederholungen bestimmen jedoch, ob Nachrichten verloren, doppelt oder endlos verarbeitet werden. ^{[S-168; S-169; S-170]}

Backoff und Jitter verhindern koordinierte Wiederholungsstürme

FAKTENBEFUND: Sofortige, gleichzeitige Retries können einen gestörten Dienst zusätzlich überlasten. Exponentieller Backoff mit Zufallsanteil, Retry-Limits und Fehlerklassifikation ist robuster als blindes Wiederholen. ^{[S-043; S-155; S-046]}

429 ist ein Steuerungssignal, kein Ausnahmefall ohne Plan

FAKTENBEFUND: Provider drosseln nach Nutzer, Organisation, App, Endpunkt oder Ressource. Clients müssen Retry-After oder anbieterspezifische Hinweise beachten, Arbeit puffern und Prioritäten setzen; mehr Parallelität verschärft die Lage häufig. ^{[S-155; S-190; S-049]}

Exactly once ist selten eine Ende-zu-Ende-Garantie

FAKTENBEFUND: Messaging-Plattformen können bestimmte Semantiken innerhalb enger Grenzen anbieten. Sobald externe APIs, Datenbanken und E-Mail-Versand beteiligt sind, muss die fachliche Einmaligkeit über Idempotenzschlüssel, Zustandsprüfung, Transaktionen oder Kompensation abgesichert werden. ^{[S-172; S-045; S-099]}

Reihenfolge muss fachlich definiert werden

FAKTENBEFUND: Globale Reihenfolge ist teuer und oft unnötig. Meist genügt Ordnung pro Kunde, Auftrag oder Schlüssel. Partitionierung, Sequenznummern und Versionskonflikte müssen zur fachlichen Einheit passen. ^{[S-171; S-025; S-098]}

Transactional Outbox schließt eine typische Dual-Write-Lücke

FAKTENBEFUND: Wird eine Datenbankänderung gemeinsam mit einem Outbox-Eintrag in einer Transaktion gespeichert und später per CDC veröffentlicht, sinkt das Risiko, dass Daten geschrieben, aber das zugehörige Ereignis nicht versendet wird. ^{[S-099; S-177; S-179]}

Langlaufende Abläufe brauchen dauerhaften Zustand

FAKTENBEFUND: Angebotsfreigaben, Rückfragen, externe Wartezeiten oder mehrtägige Agentenaufgaben lassen sich nicht zuverlässig als ein einzelner HTTP-Request betreiben. Eine Workflow- oder Task-Engine muss Zustand, Timer, Wiederaufnahme und Fehlerpfade persistieren. ^{[S-173; S-175; S-112]}

Kompensation ersetzt keine echte Transaktion, kann aber Wirkung begrenzen

FAKTENBEFUND: Bei verteilten Systemen ist ein globales Rollback häufig nicht verfügbar. Stattdessen werden abgeschlossene Schritte mit fachlich definierten Gegenaktionen korrigiert, etwa Reservierung stornieren oder Entwurf zurückziehen. Nicht jede Außenwirkung ist vollständig reversibel. ^{[S-137; S-174; S-003]}

Reconciliation findet leise Verluste und Divergenzen

FAKTENBEFUND: Zusätzlich zur Echtzeitverarbeitung sollten Soll-Ist-Abgleiche prüfen, ob Quell- und Zielsystem dieselben relevanten Objekte, Versionen und Status enthalten. Dies erkennt abgelaufene Delta-Tokens, verlorene Events, manuelle Änderungen und unbemerkte Teilfehler. ^{[S-187; S-193; S-046]}

Tool Calling ist ein Modellvorschlag, kein autorisierter Befehl

FAKTENBEFUND: Das Modell wählt anhand von Beschreibungen ein Werkzeug und erzeugt Argumente. Die Anwendung muss Werkzeugfreigabe, Nutzerrechte, Parameter, Geschäftsregeln und Risikogrenzen prüfen, bevor eine reale Operation ausgeführt wird. ^{[S-082; S-083; S-084]}

Werkzeugbeschreibungen beeinflussen Verhalten und Angriffsfläche

FAKTENBEFUND: Name, Beschreibung und Schema steuern, wann ein Modell ein Tool auswählt. Mehrdeutige, überbreite oder manipulierbare Beschreibungen können Fehlaufrufe und Prompt-Injection-Wirkung verstärken; besonders schreibende Tools sollten klein und eindeutig sein. ^{[S-107; S-033; S-201]}

Toolantworten sind unvertrauenswürdige Eingaben

FAKTENBEFUND: Inhalte aus Webseiten, Tickets, Dateien oder CRM-Feldern können Anweisungen enthalten, die ein Modell als Prompt interpretiert. Ergebnisse müssen gekennzeichnet, begrenzt und von Systemanweisungen getrennt werden; nachgelagerte Aktionen benötigen unabhängige Policy. ^{[S-033; S-034; S-201]}

MCP standardisiert die Verbindung, nicht die Vertrauenswürdigkeit

FAKTENBEFUND: Ein MCP-Server kann Tools, Resources und Prompts einheitlich anbieten. Das Protokoll garantiert nicht, dass Servercode, Metadaten, Daten oder Werkzeuge sicher, korrekt oder für den konkreten Nutzer zulässig sind. ^{[S-100; S-089; S-115]}

MCP 2026-07-28 besitzt einen zustandslosen Kern

FAKTENBEFUND: Die aktuelle Spezifikation entfernt den früheren Initialisierungshandshake und verlangt, dass Anfragen notwendige Versions- und Fähigkeitsinformationen tragen. Langlaufender Zustand wird über Erweiterungen wie Tasks modelliert, nicht durch eine implizit vertrauenswürdige Sitzung. ^{[S-101; S-102; S-112]}

stdio und Streamable HTTP haben unterschiedliche Vertrauensmodelle

FAKTENBEFUND: Ein lokal gestarteter stdio-Server erbt Prozess-, Datei- und Benutzerrechte des Hosts. Ein entfernter HTTP-Server benötigt Netzwerk-, TLS-, Origin-, Authentisierungs- und Autorisierungskontrollen. Lokal bedeutet nicht automatisch ungefährlich. ^{[S-103; S-104; S-198]}

MCP-Autorisierung stützt sich auf etablierte OAuth-Bausteine

FAKTENBEFUND: HTTP-basierte MCP-Server verwenden Protected Resource Metadata, Authorization-Server-Discovery und OAuth-Sicherheitsanforderungen. Der Server muss Tokens für sich selbst validieren und darf keine fremden Zielressourcen durch Token-Passthrough bedienen. ^{[S-104; S-105; S-106]}

MCP-Ressourcen sind nicht automatisch RAG oder Memory

FAKTENBEFUND: Resources stellen adressierbare Inhalte bereit. Ob, wie und wann ein Host sie auswählt, indexiert, in Kontext einfügt oder dauerhaft speichert, ist eine separate Architekturentscheidung. Ressourcenberechtigung und Datenminimierung bleiben erforderlich. ^{[S-108; S-087; S-066]}

MCP-Prompts sind Vorlagen, keine unveränderlichen Systemregeln

FAKTENBEFUND: Serverseitige Promptvorlagen können Nutzerabläufe vereinheitlichen. Hosts müssen Herkunft, Sichtbarkeit und Einfluss kontrollieren; ein Prompt eines Drittservers darf nicht stillschweigend höher priorisierte Sicherheits- oder Unternehmensregeln überschreiben. ^{[S-109; S-033; S-089]}

MCP Sampling verschiebt Modellaufrufe zum Host

FAKTENBEFUND: Ein Server kann den Host um eine Modellgenerierung bitten, während der Host Modellzugriff, Kontext, Einwilligung und Kosten kontrolliert. Dadurch entsteht eine zusätzliche Vertrauensgrenze: Der Server darf keine unbegrenzten oder verdeckten Modellaufrufe erzwingen. ^{[S-110; S-089; S-092]}

A2A und MCP lösen verschiedene Integrationsprobleme

FAKTENBEFUND: MCP verbindet einen Host beziehungsweise Agenten mit Werkzeugen, Ressourcen und Promptbausteinen. A2A verbindet eigenständige Agentensysteme über Agent Cards, Messages, Tasks und Artifacts. Eine Architektur kann beide verwenden, ohne sie gleichzusetzen. ^{[S-213; S-208; S-100]}

A2A-Agenten bleiben aus Sicht des Gegenübers opak

FAKTENBEFUND: Ein A2A-Client muss die internen Modelle, Tools oder Speicher eines entfernten Agenten nicht kennen. Er benötigt aber einen belastbaren Vertrag über Fähigkeiten, Authentisierung, Taskzustände, Artefakte, Fehler und Nachweis; Agent Cards sind Discovery-Metadaten, kein Vertrauensbeweis. ^{[S-211; S-212; S-208]}

E-Mail-Integration braucht Push plus Wiederabgleich

FAKTENBEFUND: Push- oder Webhook-Nachrichten melden Änderungen, enthalten aber nicht immer den vollständigen Inhalt und können ausfallen oder ablaufen. Mailbox-Integrationen sollten Message-ID, History- oder Delta-Stand und periodischen Wiederabgleich kombinieren. ^{[S-188; S-186; S-187]}

E-Mail-Versand ist ein Außenwirkungsschritt

FAKTENBEFUND: Ein generierter Entwurf ist intern reversibel; eine versandte E-Mail nicht. Absenderidentität, Empfänger, Anhänge, Datenschutz, Freigabe, Message-ID, Bounce- und Zustellstatus müssen deshalb getrennt vom Textgenerieren behandelt werden. ^{[S-077; S-184; S-023]}

CRM-Synchronisation braucht Objekt- und Feldverantwortung

FAKTENBEFUND: Kontakt, Firma, Lead, Opportunity und Aktivität haben anbieterspezifische Identitäten und Regeln. Deduplizierung nur über Namen oder Modellähnlichkeit erzeugt Fehlzuordnungen; externe IDs, Matchregeln und menschliche Klärung sind erforderlich. ^{[S-189; S-192; S-002]}

CRM-Events ersetzen keinen periodischen Konsistenzcheck

FAKTENBEFUND: Pub/Sub, Webhooks oder Journale ermöglichen zeitnahe Änderungen. Retention, Limits, fehlerhafte Abonnements und manuelle Datenänderungen können dennoch Lücken erzeugen; Checkpoints und Reconciliation bleiben nötig. ^{[S-191; S-193; S-190]}

ERP-Integration erfordert fachliche Prozesskenntnis

FAKTENBEFUND: Technischer Zugriff auf Business-Partner-, Material- oder Auftragsobjekte sagt nicht, welche Felder führend sind, welche Buchungsperioden gelten oder welcher Status eine rechtliche beziehungsweise finanzielle Wirkung hat. KI darf diese Semantik nicht erraten. ^{[S-195; S-196; S-002]}

Kennzahlen sollten deterministisch berechnet werden

FAKTENBEFUND: Umsatz, Marge, Bestand, Durchlaufzeit oder offene Posten gehören in geprüfte SQL-, BI- oder Regelmodelle. Ein LLM kann Ergebnisse erklären und Fragen formulieren, sollte aber nicht verdeckt die verbindliche Berechnungslogik ersetzen. ^{[S-099; S-001; S-008]}

CDC überträgt Änderungen, nicht automatisch Geschäftsbedeutung

FAKTENBEFUND: Logical Decoding oder Debezium können Inserts, Updates und Deletes erkennen. Downstream-Systeme müssen Schemaänderungen, Tombstones, Transaktionsgrenzen, Replays und fachliche Ereignisse weiterhin korrekt interpretieren. ^{[S-179; S-180; S-177]}

Objektspeicher-Ereignisse können mehrfach oder verzögert eintreffen

FAKTENBEFUND: Datei-Uploads sollten über Objekt-Key, Version und Prüfsumme identifiziert werden. Verarbeitung darf nicht allein davon ausgehen, dass jedes Event einmal und in strenger Reihenfolge kommt. ^{[S-181; S-183; S-044]}

Große Dateien brauchen gestufte Verarbeitung

FAKTENBEFUND: Upload, Virenprüfung, Textextraktion, Klassifikation, Indexierung und Freigabe sind getrennte Schritte mit eigenen Limits. Multipart Upload und Wiederaufnahme lösen Transportprobleme, nicht automatisch Inhalts- und Datenschutzfragen. ^{[S-182; S-035; S-066]}

Provider-Limits sind Bestandteil der Architektur

FAKTENBEFUND: CRM-, Mail-, Modell- und Dateidienste setzen unterschiedliche Quoten. Batchgrößen, Prioritäten, Caching, Backpressure und Wiederholungspläne müssen anhand des konkreten Kontos und Endpunkts dimensioniert werden, nicht anhand allgemeiner Internetwerte. ^{[S-190; S-155; S-049]}

Low-Code verbindet schnell, aber übernimmt keine Verantwortung

FAKTENBEFUND: Ein visueller Workflow verkürzt Implementierung, ändert jedoch nichts an OAuth-Scopes, Secrets, Idempotenz, Datenminimierung, Versionsbrüchen und Incidentpflichten. Exportierbarkeit, Testbarkeit und Eigentum des Workflows bleiben zu klären. ^{[S-007; S-004; S-030]}

Direkter Datenbankzugriff ist selten eine neutrale Abkürzung

FAKTENBEFUND: Er umgeht gegebenenfalls Geschäftslogik, Autorisierung und Audit des Anwendungssystems. Wo kein unterstütztes API existiert, sind Read-Replica, Views, CDC oder klar begrenzte Integrationskonten meist sicherer als unkontrollierte Schreibzugriffe auf Produktivtabellen. ^{[S-099; S-032; S-040]}

Observability muss Systemgrenzen überqueren

FAKTENBEFUND: Ein einzelner Workflow kann Mail, Queue, Modell, CRM und Versanddienst durchlaufen. Korrelations- und Trace-IDs, strukturierte Logs, Metriken und Statusübergänge müssen diese Kette verbinden, ohne sensible Prompts, Tokens oder Personendaten unkontrolliert zu protokollieren. ^{[S-058; S-055; S-031]}

Technischer Erfolg und fachlicher Erfolg sind getrennte Metriken

FAKTENBEFUND: HTTP 200 oder ein abgeschlossener Job beweist nicht, dass der richtige Kontakt aktualisiert oder die richtige Nachricht versandt wurde. Fachliche Kontrollen benötigen beispielsweise Datensatz-ID, erwartete Version, Angebotsnummer, Versandstatus und Reconciliation. ^{[S-049; S-001; S-099]}

SLIs und SLOs müssen pro kritischem Pfad definiert werden

FAKTENBEFUND: Verfügbarkeit allein genügt nicht. Relevante Kennzahlen sind unter anderem Ereignisalter, End-to-End-Latenz, Fehlerquote, Dedupe-Rate, Queue-Alter, Modellvalidierungsfehler, Freigabedauer und Wiederabgleichsdifferenzen. ^{[S-049; S-056; S-050]}

Alarmierung braucht eine handlungsfähige Reaktion

FAKTENBEFUND: Ein Alert ohne Eigentümer, Schwelle, Runbook, Diagnosezugang und Eskalationsweg erzeugt Lärm. Kritische Schreib- oder Versandpfade sollten bei Unsicherheit kontrolliert stoppen, statt Fehler automatisch zu vervielfachen. ^{[S-050; S-051; S-010]}

Auditprotokolle müssen Manipulation und Datenabfluss begrenzen

FAKTENBEFUND: Erfasst werden sollten Identität, Vorgang, Ziel, Entscheidung, Freigabe, Ergebnis und Korrelation. Tokens, vollständige vertrauliche Inhalte und unnötige Personendaten gehören nicht in Logs. Zugriff und Aufbewahrung des Audits brauchen eigene Kontrollen. ^{[S-031; S-066; S-014]}

Backups sichern nicht automatisch externe Systeme

FAKTENBEFUND: Eigene Datenbanken können gesichert werden, aber CRM-, Mail- oder SaaS-Zustände liegen beim Provider. Export, Versionierung, Wiederherstellung, Konfigurationsbackup und Wiederaufbau der Integrationen müssen je System getestet werden. ^{[S-060; S-061; S-012]}

Ein Kill Switch muss die Wirkung wirklich stoppen

FAKTENBEFUND: Das Deaktivieren des Modells genügt nicht, wenn Queues weiterlaufen, Tokens gültig bleiben oder geplante Jobs schreiben. Stoppschalter sollten Trigger, Worker, ausgehende Aktionen und Credentials kontrolliert sperren und einen sicheren Wiederanlauf erlauben. ^{[S-010; S-052; S-003]}

Drittintegrationen vergrößern die Lieferkette

FAKTENBEFUND: Ein verbundenes Tool kann über OAuth-Tokens, Webhooks, Browser-Sessions oder gespeicherte Secrets auf Kernsysteme wirken. Vorfälle bei GitHub, Salesloft/Drift und CircleCI zeigen, dass die Sicherheit des eigenen Systems von Integrationsanbietern abhängt. ^{[S-202; S-207; S-204]}

MCP-Server sind Softwarelieferanten mit hoher Hebelwirkung

FAKTENBEFUND: Ein Server kann lokalen Code ausführen, Dateien lesen oder entfernte Systeme bedienen. Registry-Eintrag, Popularität oder Open-Source-Status ersetzen keine Codeprüfung, Signatur, Versionpinning, Sandbox, Rechtebegrenzung und Updatekontrolle. ^{[S-115; S-199; S-200]}

Änderungen an Modellen können Integrationen brechen

FAKTENBEFUND: Neue Modellversionen können Toolauswahl, Argumente, Formatierung, Latenz und Ablehnungsverhalten verändern. Regressionstests mit realistischen Fällen und kontrollierter Rollout sind notwendig, selbst wenn das API-Schema gleich bleibt. ^{[S-011; S-008; S-048]}

Kosten entstehen überwiegend an Übergängen und Sonderfällen

FAKTENBEFUND: Neben Tokens zählen API-Aufrufe, Datenübertragung, Queue- und Speicherbetrieb, Monitoring, Support, manuelle Freigaben, Fehlerbehandlung, Provideränderungen und Sicherheitsarbeit. Eine Demo ohne Betriebskosten ist keine belastbare Wirtschaftlichkeitsrechnung. ^{[S-053; S-003; S-001]}

Ein produktiver KI-Workflow braucht nachweisbare Verantwortungsgrenzen

FAKTENBEFUND: Für Datenquelle, Modell, Tool, externe Aktion, Freigabe, Incident und Datenschutz muss feststehen, wer entscheidet und wer reagiert. Weder der Modellanbieter noch ein Protokoll übernehmen automatisch die Verantwortung des einsetzenden Unternehmens. ^{[S-068; S-067; S-092]}

33 Praxisfelder

LESEHINWEIS: Die Praxisfelder verbinden Spezifikationen mit Mindestartefakten und Warnsignalen. Sie sind als Architektur- und Projektprüfung gedacht, nicht als bloßes Begriffslexikon. ^{[S-002; S-003; S-004]}

Geschäftsvorgang und System of Record

Jede Integration braucht einen fachlich benannten Vorgang und einen verbindlichen Datenhalter. „Die KI verarbeitet E-Mails“ ist keine ausreichende Anforderung; belastbar wird sie erst mit Auslöser, Eingängen, Zuständen, zulässigen Entscheidungen, Zielsystem und Abschlusskriterium. ^{[S-002; S-137; S-099]}

Integrationsinventar und Eigentum

Ein Inventar macht sichtbar, welche Apps, Tokens, Webhooks, MCP-Server und Datenströme tatsächlich existieren. Es ist Grundlage für Betrieb, Datenschutz, Incidentreaktion und Abschaltung. ^{[S-014; S-009; S-004]}

REST und HTTP

REST-basierte HTTP-APIs sind für viele Integrationen ausreichend, wenn Ressourcen, Methoden, Authentisierung, Fehler, Idempotenz und Versionierung sauber beschrieben sind. Die Einfachheit des Transports darf nicht mit Einfachheit des Geschäftsvertrags verwechselt werden. ^{[S-023; S-021; S-024]}

GraphQL

GraphQL gibt Clients flexible, typisierte Abfragen. In vernetzten KI-Systemen ist es nützlich, wenn unterschiedliche Aufgaben variable Datenausschnitte benötigen. Die Flexibilität erhöht jedoch Anforderungen an Feldberechtigungen, Abfragekomplexität, Kostenkontrolle und Caching. ^{[S-122; S-124; S-038]}

gRPC und Protocol Buffers

gRPC eignet sich für interne, stark typisierte und leistungsorientierte Servicekommunikation. Streaming und Codegenerierung sind Vorteile; öffentliche Partnerintegration, Browser, Debugging und Gatewaybetrieb müssen gesondert geplant werden. ^{[S-125; S-126; S-127]}

OData und Unternehmensobjekte

OData standardisiert Datenmodelle, Abfragen und Operationen und ist in SAP- und Microsoft-Landschaften verbreitet. Für belastbare Automatisierung müssen Filter, Navigation, Batch, ETags, fachliche Objektregeln und Providerlimits verstanden werden. ^{[S-128; S-196; S-184]}

OpenAPI, JSON Schema und Arazzo

OpenAPI beschreibt einzelne HTTP-Schnittstellen, JSON Schema Datenformen und Arazzo mehrstufige Aufruffolgen. Zusammen bilden sie einen guten maschinenlesbaren Vertrag, aber keine vollständige Laufzeit-, Sicherheits- oder Geschäftslogik. ^{[S-021; S-022; S-119]}

Versionierung, Deprecation und Sunset

Integrationen leben länger als einzelne Modell- oder Softwareversionen. Änderungen brauchen Kompatibilitätsbewertung, Ankündigung, parallelen Betrieb, Migration, Messung verbliebener Nutzung und kontrollierte Abschaltung. ^{[S-006; S-138; S-139]}

Fehlerverträge und Geschäftsablehnung

Ein Fehlervertrag trennt Transport-, Authentisierungs-, Drosselungs-, Validierungs-, Konflikt- und Geschäftsfehler. Dadurch kann die Automation entscheiden, ob sie korrigiert, wartet, eskaliert oder endgültig abbricht. ^{[S-024; S-155; S-023]}

API Keys und statische Credentials

Statische Schlüssel sind leicht zu integrieren, besitzen aber häufig große Reichweite und lange Lebensdauer. Sie eignen sich nur für klar begrenzte Serveridentitäten und brauchen Speicherung, Rotation, Monitoring und schnelle Sperrung. ^{[S-030; S-041; S-014]}

OAuth 2.0 und OpenID Connect

OAuth delegiert Ressourcenzugriff; OpenID Connect ergänzt Identitätsaussagen. Sichere Implementierung verlangt passende Flows, exakte Redirect-URIs, PKCE, State/Nonce, Tokenprüfung, Scope-Minimierung und Lifecycle-Management. ^{[S-072; S-156; S-074]}

Dienstidentitäten, Token Exchange und Proof-of-Possession

Komplexe Ketten brauchen nachvollziehbare nichtmenschliche Identitäten. Token Exchange, Resource Indicators, mTLS und DPoP können Reichweite und Weitergabe begrenzen, erhöhen aber Betriebs- und Schlüsselmanagementaufwand. ^{[S-148; S-144; S-146; S-147]}

Scopes, Rollen und objektbezogene Autorisierung

Scopes steuern grob, welche API ein Token nutzen darf. Die eigentliche Geschäftsberechtigung muss häufig zusätzlich Mandant, Rolle, Eigentümer, Datensatz, Feld, Status und Betrag berücksichtigen. ^{[S-032; S-027; S-107]}

Secrets, Schlüssel und Rotation

Secrets verbinden nahezu alle Integrationskomponenten. Ihre Ablage, Ausgabe, Rotation und Revocation sind ein eigenständiger Betriebsprozess, nicht bloß eine Konfigurationsfrage. ^{[S-030; S-204; S-017]}

Webhooks

Webhooks melden Ereignisse schnell, sind aber in der Praxis wiederholbar, verzögert und providerabhängig. Eingang und Verarbeitung müssen entkoppelt und jeder Seiteneffekt dedupliziert werden. ^{[S-076; S-185; S-136]}

Polling, Delta und Change Feeds

Polling ist nicht grundsätzlich falsch. Bei fehlendem Push, geringer Änderungsrate oder notwendiger Kontrolle kann es der einfachste robuste Weg sein. Delta- und History-Token reduzieren Last, verlangen aber gespeicherten Zustand und Wiederaufbau bei Ablauf. ^{[S-187; S-188; S-193]}

Queues und Dead-Letter-Handling

Queues puffern Last und entkoppeln Verfügbarkeit. Ihre Zuverlässigkeit hängt an Sichtbarkeitszeit, Acknowledgement, Retention, Retrylimit und einem bearbeitbaren Dead-Letter-Prozess. ^{[S-168; S-169; S-170]}

Event Streaming und AsyncAPI

Streams eignen sich für hohe Änderungsraten und mehrere unabhängige Verbraucher. Ereignisschema, Schlüssel, Partition, Retention, Replay, Consumergruppen und Datenschutz bestimmen die tatsächliche Nutzbarkeit. ^{[S-091; S-171; S-120]}

Idempotenz, Deduplizierung und Reihenfolge

Wiederholungen sind unvermeidbar. Fachliche Einmaligkeit entsteht durch stabile Schlüssel, gespeicherten Verarbeitungszustand und atomare oder kompensierende Seiteneffekte. ^{[S-045; S-044; S-099]}

Timeouts, Retries, Backoff und Circuit Breaker

Jeder externe Aufruf kann langsam, teilweise oder uneindeutig fehlschlagen. Timeouts begrenzen Ressourcen; Retries behandeln nur vorübergehende Fehler; Circuit Breaker und Backpressure schützen abhängige Systeme. ^{[S-043; S-046; S-155]}

Rate Limits und Backpressure

Ratenlimits schützen Provider und verteilen Kapazität. Ein robuster Client priorisiert Arbeit, respektiert Rückmeldungen, puffert kontrolliert und reduziert Parallelität statt das Limit durch weitere Retries zu verschärfen. ^{[S-155; S-190; S-049]}

Transaktion, Outbox, Saga und Kompensation

Verteilte Vorgänge können selten in einer einzigen Datenbanktransaktion abgeschlossen werden. Outbox verhindert verlorene Events; Sagas und Kompensation strukturieren mehrstufige Wirkung und Rücknahme. ^{[S-099; S-177; S-137]}

Function und Tool Calling

Tool Calling übersetzt Modellentscheidungen in strukturierte Operationsvorschläge. Es ist besonders nützlich, wenn Sprache auf klar begrenzte Funktionen abgebildet wird. Die Anwendung bleibt für Validierung und Ausführung verantwortlich. ^{[S-082; S-083; S-084]}

Structured Outputs und Validierung

Strukturierte Ausgaben erleichtern robuste Weiterverarbeitung. Sie sollten als typisierte, aber inhaltlich noch zu prüfende Vorschläge behandelt werden. ^{[S-085; S-086; S-163]}

MCP-Architektur und Fähigkeiten

MCP standardisiert, wie Hosts mit Servern über Tools, Resources, Prompts und optionale Fähigkeiten interagieren. Der Host hält Nutzerinteraktion, Modell und Policy; jeder Server bleibt eine eigene Vertrauens- und Berechtigungsdomäne. ^{[S-087; S-100; S-107; S-108]}

MCP-Autorisierung und Server-Supply-Chain

Die aktuelle MCP-Spezifikation nutzt etablierte OAuth-Metadaten und verbietet riskantes Token-Passthrough. Zusätzlich bleibt die Softwarelieferkette des Servers zu prüfen, besonders bei lokal installierten Servern mit Dateisystem- oder Shellrechten. ^{[S-104; S-106; S-199]}

A2A und Multi-Agenten-Kommunikation

A2A 1.0 standardisiert Kommunikation zwischen eigenständigen Agentensystemen. Agent Cards beschreiben Fähigkeiten und Sicherheit; Tasks, Messages, Parts und Artifacts strukturieren länger laufende oder multimodale Zusammenarbeit. ^{[S-208; S-211; S-209]}

E-Mail und Kalender

Mail- und Kalenderintegration verbindet unstrukturierte Kommunikation mit hochwirksamen Unternehmensdaten. Push, Delta, Message-IDs, Anhänge, Absenderidentität, Datenschutz, Spam und Versandfreigabe müssen gemeinsam betrachtet werden. ^{[S-184; S-188; S-077]}

CRM-Integration

CRM-Systeme bündeln Identitäten, Aktivitäten, Verkaufschancen und oft vertrauliche Kommunikation. Automatisierung muss Anbieterobjekte, Dubletten, Eigentümer, Phasen, Scopes, Limits und manuelle Änderungen beherrschen. ^{[S-189; S-192; S-194]}

ERP- und SAP-Integration

ERP-Daten tragen finanzielle und operative Bedeutung. APIs und Events stellen Technik bereit; fachliche Buchungsregeln, Stammdatenverantwortung, Status, Perioden und Berechtigungen bleiben systemspezifisch. ^{[S-195; S-196; S-197]}

Dateien und Objektspeicher

Dateien sind unstrukturierte, potenziell schädliche und häufig personenbezogene Eingaben. Upload, Speicherung, Version, Extraktion, Indexierung, Freigabe und Löschung benötigen getrennte Zustände. ^{[S-181; S-183; S-035]}

Datenbanken, CDC und Reconciliation

Datenbanken liefern konsistente Transaktionen innerhalb ihrer Grenze; CDC macht Änderungen transportierbar. Externe Verbraucher benötigen Schema-, Offset-, Replay- und Datenschutzregeln sowie einen Abgleich zur Quelle. ^{[S-099; S-179; S-177]}

Observability, Audit, Freigabe und Exit

Eine produktive Integration ist erst beherrschbar, wenn Datenfluss, technische Ausführung, fachliche Wirkung und menschliche Freigaben nachvollziehbar sind und die Kette kontrolliert gestoppt, wiederaufgenommen oder entfernt werden kann. ^{[S-054; S-049; S-010]}

25 Standard-, Protokoll- und Technikprofile

Die Profile beantworten nicht nur „Was ist es?“, sondern vor allem „Wofür passt es, wo endet es und welche Kontrollen fehlen sonst?“

HTTP und REST

OpenAPI, JSON Schema und Arazzo

GraphQL

gRPC und Protocol Buffers

OData 4.01

Webhooks

CloudEvents und AsyncAPI

Apache Kafka

SQS-ähnliche Arbeitsqueues

Durable Workflow Engine / Temporal

OAuth 2.0 und OpenID Connect

Token Exchange, mTLS und DPoP

LLM Function / Tool Calling

Structured Outputs

MCP Core 2026-07-28

MCP Tools, Resources und Prompts

MCP Authorization

MCP Tasks und Extensions

A2A Protocol 1.0

Microsoft Graph

Gmail Push Notifications

Salesforce und HubSpot

SAP BTP, OData und Event Mesh

PostgreSQL, Logical Decoding und Debezium

OpenTelemetry und SRE-Kontrollen

12 dokumentierte Vorfälle und Lessons Learned

EINORDNUNG: Die Fälle beweisen nicht, dass jede ähnliche Architektur scheitert. Sie zeigen konkrete Fehlerklassen an realen Vertrauens-, Token-, Daten-, Update- und Betriebsgrenzen. ^{[S-010; S-003]}

MCP Inspector: unauthentisierte Remote-Code-Ausführung

mcp-remote: Command Injection über Authorization Endpoint

MCPJam Inspector: Netzwerkbindung plus fehlende Authentisierung

Indirekte Prompt Injection über GitHub-Inhalte und MCP-Werkzeuge

GitHub: gestohlene OAuth-Tokens von Drittintegrationen

npm/GitHub: Kettenwirkung bis zu Cloud-Credentials

CircleCI 2023: Sessionkompromittierung und Massenrotation

Retool 2023: Social Engineering trotz MFA

Salesforce Connected Apps: Vishing und Datenextortion

Salesloft Drift: kompromittierte OAuth-Tokens als Brücke zu Salesforce

GitLab-Datenbankausfall: fehlgeschlagene Backups und manuelle Fehler

Atlassian 2022: fehlerhaftes Skript löschte Kundensites

Querschnitt der Vorfälle

18 vollständige Referenzszenarien

Jedes Szenario trennt KI-Rolle und deterministische Verantwortung. Diese Trennung ist das zentrale Qualitätsmerkmal.

Eingehende Angebotsanfrage aus E-Mail

Support-E-Mail zu Ticket und Antwortentwurf

Rechnungseingang mit ERP-Vorerfassung

CRM-Lead aus Webformular und Kalender

Vertriebsnotiz aus Gespräch zu CRM-Aktivität

ERP-Bestände zu Frühwarn-Dashboard

Auftragseingang aus Portal zu ERP

Produktdaten aus ERP zu Shop und KI-Text

Datei-Upload zu Wissensbasis

MCP-Server für CRM-Lesezugriff

MCP-Server für freizugebende CRM-Schreibaktionen

MCP-Dateiserver für lokale Projektordner

A2A: Vertriebsagent delegiert Produktprüfung

A2A plus MCP: externer Agent nutzt interne Werkzeuge indirekt

Kunden-Onboarding über mehrere SaaS-Dienste

Datenqualitätsmonitor für CRM und ERP

Interner Rechercheassistent mit Web- und Dateitools

Incidentgesteuerte Abschaltung einer Integrationskette

56-stufiger Weg von der Integrationsidee zum beherrschten Betrieb

UMSETZUNGSLOGIK: Der Weg ist absichtlich nicht als „Prompt schreiben, Connector wählen, einschalten“ aufgebaut. Er beginnt mit Geschäftswirkung und endet mit Exit, weil Rechte, Daten und laufende Jobs auch nach einem Anbieterwechsel fortbestehen können. ^{[S-002; S-003; S-004; S-150]}

Phase 1 — Geschäftsvorgang und Grenze

Bevor Technik gewählt wird, müssen Zweck, Wirkung, Daten und Verantwortung feststehen.

Phase 2 — Quellen, Verträge und Datenmodell

Die technische Verbindung wird als prüfbarer Vertrag statt als lose Folge von Toolaufrufen entworfen.

Phase 3 — Authentisierung, Autorisierung und Secrets

Zugriff wird pro Identität, Ressource und Operation begrenzt und widerrufbar.

Phase 4 — Zuverlässige Zustellung und Zustand

Duplikate, Teilfehler, Limits und Wiederanlauf werden absichtlich beherrscht.

Phase 5 — KI-, Tool-, MCP- und A2A-Grenzen

Probabilistische Komponenten dürfen nur kontrolliert auf reale Systeme wirken.

Phase 6 — Geschäftsregeln, Freigaben und Tests

Die beabsichtigte Wirkung wird vor Produktion mit realistischen und bösartigen Fällen geprüft.

Phase 7 — Deployment, Beobachtbarkeit und Incidentfähigkeit

Die Integrationskette wird messbar, stoppbar und wiederherstellbar betrieben.

Phase 8 — Governance, Betrieb und Exit

Nach dem Go-live bleiben Rechte, Verträge, Modelle, Kosten und Lieferkette kontrolliert.

Prüf-, Go-live-, Betriebs- und Exit-Checklisten

Geschäfts- und Datenvertrag

API- und Eventvertrag

Identität, OAuth und Secrets

Tool Calling und MCP

Reliability, Go-live und Betrieb

Abbildung: Abbildung 5: Retry, Deduplizierung und Seiteneffekt. Eigene Synthese; Wiederholung ist nur mit begrenzter Wirkung sicher. ^{[S-043; S-044; S-171]}

Exit und Stilllegung

• Alle OAuth Grants, API Keys, Service Accounts, Webhooks, MCP-Server und Agentenbeziehungen inventarisieren und widerrufen. ^{[S-150; S-009]}
• Queues, Cronjobs, durable Workflows, Retries, DLQ und ausstehende Freigaben kontrolliert beenden oder übergeben. ^{[S-170; S-173]}
• Daten, Audit, Konfiguration und Schemas in dokumentierten Formaten exportieren und Integrität prüfen. ^{[S-062; S-004]}
• Providerdaten, Caches, Logs, Indizes, Backups und lokale Kopien nach Rechts- und Aufbewahrungsplan behandeln. ^{[S-066; S-162]}
• Fallbackbetrieb beziehungsweise neue Integration mit Reconciliation gegen das System of Record starten. ^{[S-046; S-013]}

Zwei vollständige Referenzarchitekturen und Entscheidungsmatrizen

E-Mail → KI → CRM → Angebot → Freigabe → Versand

Abbildung: Abbildung 6: Referenzablauf einer Angebotsanfrage. KI extrahiert und formuliert; Identität, Preise, Freigabe und Versand bleiben kontrolliert. ^{[S-188; S-085; S-189; S-077]}

Fehler- und Freigabematrix für den E-Mail-Prozess

ERP → Datenplattform → KI-Auswertung → Dashboard → Benachrichtigung

Abbildung: Abbildung 7: Referenzablauf für ERP-Daten. KPI werden deterministisch berechnet; KI erklärt Auffälligkeiten und nennt Evidenz. ^{[S-196; S-177; S-179; S-008]}

Wann keine KI benötigt wird

API, MCP oder A2A?

20 Mythenprüfungen

„Eine API-Verbindung ist zuverlässig, sobald der erste Testaufruf funktioniert.“

Urteil: Falsch. Der Happy Path sagt nichts über Limits, Timeouts, Duplikate, Schemaänderungen, Tokenablauf, Teilfehler, Reconciliation oder Betrieb aus. ^{[S-011; S-047; S-001]}

„HTTP 200 bedeutet, dass der Geschäftsvorgang erfolgreich war.“

Urteil: Falsch. 200 belegt lediglich eine erfolgreiche HTTP-Verarbeitung nach Serverdefinition. Richtiger Datensatz, fachlicher Status und Außenwirkung müssen separat nachgewiesen werden. ^{[S-023; S-049]}

„Webhooks werden genau einmal geliefert.“

Urteil: Falsch. Wiederholungen und Lücken sind üblich. Empfänger brauchen Deduplizierung, Idempotenz und einen Wiederabgleich. ^{[S-076; S-044; S-187]}

„Eine Queue verhindert doppelte Verarbeitung.“

Urteil: Falsch. Viele Queues liefern mindestens einmal. Die fachliche Einmaligkeit entsteht am Consumer und Seiteneffekt. ^{[S-168; S-045]}

„Exactly once löst sämtliche Duplikatprobleme.“

Urteil: Irreführend. Garantien gelten nur innerhalb definierter Grenzen. Externe CRM-, Mail- oder ERP-Wirkungen benötigen weiterhin Idempotenz oder Kompensation. ^{[S-172; S-099]}

„OAuth bedeutet automatisch sichere Anmeldung.“

Urteil: Falsch. OAuth regelt Delegation; Identität kommt typischerweise über OIDC. Sichere Flows, Tokenprüfung, Scopes und Revocation bleiben nötig. ^{[S-072; S-156; S-074]}

„Ein Access Token mit richtigem Scope ersetzt Objektberechtigungen.“

Urteil: Falsch. Scopes sind grob. Server müssen Mandant, Rolle, Datensatz, Feld und Aktion zusätzlich autorisieren. ^{[S-032; S-027]}

„MFA verhindert die Übernahme von Integrationskonten.“

Urteil: Falsch. Sessiondiebstahl, Recovery, Social Engineering und gestohlene OAuth-Tokens können MFA umgehen. ^{[S-205; S-202; S-071]}

„Structured Output macht LLM-Antworten wahr.“

Urteil: Falsch. Ein Schema erzwingt Form. Formal gültige Werte können weiterhin inhaltlich falsch oder unzulässig sein. ^{[S-085; S-022]}

„Tool Calling ist eine autorisierte Aktion.“

Urteil: Falsch. Das Modell schlägt Werkzeug und Argumente vor. Anwendung und Server müssen unabhängig validieren und autorisieren. ^{[S-082; S-107; S-032]}

„MCP ist eine neue Datenbank oder ein Memory-System.“

Urteil: Falsch. MCP standardisiert Protokollzugriff auf Fähigkeiten und Ressourcen. Speicherung, Retrieval, Indexierung und Memory sind separate Komponenten. ^{[S-087; S-108]}

„Ein MCP-Registry-Eintrag ist ein Sicherheitszertifikat.“

Urteil: Falsch. Auffindbarkeit und Metadaten belegen weder Codequalität noch Rechte, Herkunft, Supply-Chain-Sicherheit oder Eignung. ^{[S-115; S-199]}

„Lokale MCP-Server sind ungefährlich, weil sie nicht in der Cloud laufen.“

Urteil: Falsch. Lokale Server können mit Benutzerrechten auf Dateien, Prozesse und Secrets zugreifen; fehlende Bindungs- oder Authkontrollen führten bereits zu RCE-Advisories. ^{[S-198; S-200]}

„A2A ersetzt MCP.“

Urteil: Falsch. A2A verbindet eigenständige Agenten; MCP verbindet Hosts/Agenten mit Tools, Ressourcen und Promptbausteinen. Beide können sich ergänzen. ^{[S-213; S-100]}

„Ein Agent Card beweist, dass ein Agent vertrauenswürdig ist.“

Urteil: Falsch. Die Karte beschreibt Fähigkeiten und Sicherheitsanforderungen. Vertrauen erfordert Identitäts-, Betreiber-, Policy- und Ergebnisprüfung. ^{[S-211; S-212]}

„Low-Code übernimmt Retry, Datenschutz und Sicherheit automatisch.“

Urteil: Falsch. Plattformen stellen Bausteine bereit. Die konkrete Konfiguration von Scopes, Secrets, Idempotenz, Datenpfad und Fehlerwirkung bleibt Projektverantwortung. ^{[S-007; S-066; S-030]}

„Direkter Datenbankzugriff ist immer schneller und deshalb besser.“

Urteil: Falsch. Er kann Geschäftslogik, Autorisierung und Supportgrenzen umgehen und erhöht Kopplung und Schadenspotenzial. ^{[S-099; S-032; S-040]}

„Backups sind vorhanden, also ist Wiederherstellung geklärt.“

Urteil: Falsch. Erst ein getesteter Restore mit Zeit- und Datenverlustzielen belegt die Nutzbarkeit. ^{[S-078; S-012; S-061]}

„Mehr Agenten machen einen Prozess automatisch intelligenter.“

Urteil: Falsch. Mehr Komponenten erhöhen Kommunikations-, Zustands-, Berechtigungs- und Fehlerkomplexität. Sie sind nur sinnvoll, wenn getrennte Zuständigkeiten einen messbaren Vorteil bringen. ^{[S-208; S-001]}

„Die KI trägt die Verantwortung für den ausgeführten Workflow.“

Urteil: Falsch. Das einsetzende Unternehmen und seine Verantwortlichen müssen Daten, Tools, Freigaben, Betrieb und Rechtsgrundlage kontrollieren. ^{[S-068; S-067; S-092]}

20 offene Technik-, Rechts- und Praxisfragen

Offene Punkte werden ausdrücklich als projektspezifisch oder schnell veränderlich ausgewiesen. Technische Modebegriffe ersetzen keine belastbare Antwort.

Glossar — 145 Begriffe

A2A

Offenes Protokoll zur Kommunikation eigenständiger Agentensysteme über Agent Cards, Messages, Tasks und Artifacts. ^[S-208]

Access Token

Credential, mit dem ein Client auf eine geschützte Ressource zugreift; Reichweite und Lebensdauer sind zu prüfen. ^[S-072]

Acknowledgement

Bestätigung eines Consumers, dass eine Nachricht erfolgreich verarbeitet wurde und aus der Queue entfernt werden kann. ^[S-169]

Agent

Softwarekomponente, die Ziele verarbeitet, Modelle und Werkzeuge nutzt und dabei Zustände oder Aktionen koordiniert. ^{[S-211; S-087]}

Agent Card

A2A-Metadokument zu Identität, Fähigkeiten, Endpunkten und Sicherheitsanforderungen eines Agenten. ^[S-211]

AMQP

Offenes Messaging-Protokoll für zuverlässige, interoperable Nachrichtenübertragung. ^[S-134]

API

Definierter Vertrag, über den Software Daten oder Funktionen eines anderen Systems nutzt. ^[S-021]

API Gateway

Zwischenschicht für Routing, Authentisierung, Limits, Beobachtbarkeit und Schutz von APIs. ^[S-027]

API Key

Statisches Geheimnis zur Identifikation oder Autorisierung einer Anwendung; häufig ohne Nutzerdelegation. ^[S-030]

Artifact

Strukturiertes Ergebnis einer A2A-Aufgabe, beispielsweise Datei, Text oder Datenobjekt. ^[S-211]

AsyncAPI

Spezifikation zur Beschreibung nachrichten- und ereignisgetriebener Schnittstellen. ^[S-120]

Audience

Bezeichner der Ressource oder des Dienstes, für den ein Token bestimmt ist. ^[S-075]

Authentisierung

Feststellung oder Prüfung, welche Identität eine Anfrage stellt. ^[S-071]

Autorisierung

Entscheidung, ob eine identifizierte Entität eine konkrete Ressource und Operation nutzen darf. ^[S-032]

Backoff

Wachsende Wartezeit zwischen Wiederholungsversuchen, um gestörte Dienste nicht zusätzlich zu überlasten. ^[S-043]

Backpressure

Mechanismus, mit dem ein langsamer Verbraucher den Zufluss neuer Arbeit begrenzt oder puffert. ^[S-046]

Batch

Gebündelte Verarbeitung mehrerer Datensätze oder Operationen in einem Lauf oder Request. ^[S-023]

Bearer Token

Token, das grundsätzlich von jedem Besitzer verwendet werden kann und deshalb besonders geschützt werden muss. ^[S-141]

BPMN

Notation zur Modellierung von Geschäftsprozessen, Ereignissen, Entscheidungen und Aktivitäten. ^[S-137]

Callback

Vom aufgerufenen System später ausgelöste Rückmeldung an einen zuvor registrierten Endpunkt. ^[S-076]

Canary

Begrenzter Rollout an einen kleinen Teil der Nutzer oder Last zur Früherkennung von Problemen. ^[S-047]

Capability Negotiation

Aushandlung oder Erkennung der von Client und Server unterstützten Protokollfähigkeiten. ^[S-102]

CDC

Change Data Capture; Erfassung und Weitergabe von Änderungen aus einem Datenbestand. ^[S-177]

Circuit Breaker

Schutzmuster, das Aufrufe an einen wiederholt fehlerhaften Dienst vorübergehend stoppt. ^[S-046]

Client Credentials

OAuth-Muster für den Zugriff einer Anwendung in eigenem Namen ohne interaktiven Nutzer. ^[S-072]

CloudEvents

Spezifikation für einheitliche Metadaten von Ereignissen. ^[S-025]

Compensation

Fachliche Gegenaktion, die Wirkung eines bereits abgeschlossenen Schrittes begrenzt oder korrigiert. ^[S-137]

Consumer

Komponente, die Nachrichten, Events oder Datenänderungen empfängt und verarbeitet. ^[S-171]

Consumer Group

Gruppe von Streamverbrauchern, die Partitionen untereinander aufteilt. ^[S-171]

Contract Test

Test, ob Provider und Consumer die vereinbarten Schnittstellenerwartungen einhalten. ^[S-011]

Correlation ID

Vorgangskennzeichen, das zusammengehörige Schritte über mehrere Systeme verbindet. ^[S-058]

Cursor

Fortsetzungswert für paginierte oder inkrementelle Abfragen. ^[S-187]

Dead-Letter-Queue

Separate Queue für Nachrichten, die nach begrenzten Versuchen nicht erfolgreich verarbeitet wurden. ^[S-170]

Deduplication

Erkennung mehrfach eingetroffener Nachrichten oder Vorgänge anhand stabiler Schlüssel. ^[S-044]

Delta Query

Abfrageverfahren, das nur Änderungen seit einem gespeicherten Stand liefert. ^[S-187]

Deprecation

Ankündigung, dass eine Funktion künftig nicht mehr empfohlen oder entfernt wird. ^[S-138]

Discovery

Automatisierte Ermittlung von Endpunkten, Metadaten oder Fähigkeiten eines Dienstes. ^[S-142]

DLQ

Kurzform für Dead-Letter-Queue. ^[S-170]

Domain Event

Fachlich benanntes Ereignis, das eine relevante Zustandsänderung der Domäne ausdrückt. ^[S-025]

DPoP

OAuth-Verfahren, das Access Tokens kryptografisch an einen Schlüssel des Clients bindet. ^[S-147]

Dry-Run

Ausführung, die geplante Wirkung zeigt, aber keine produktive Änderung vornimmt. ^[S-040]

ETag

HTTP-Metadatum zur Identifikation einer Ressourcenversion und für bedingte Anfragen. ^[S-023]

Event

Aufzeichnung, dass etwas zu einem bestimmten Zeitpunkt oder Zustand geschehen ist. ^[S-025]

Event Bus

Infrastruktur, über die Produzenten Ereignisse veröffentlichen und Verbraucher abonnieren. ^[S-120]

Event ID

Eindeutiges Kennzeichen eines Ereignisses zur Korrelation und Deduplizierung. ^[S-025]

Eventual Consistency

Zustand, bei dem verteilte Kopien nicht sofort, aber nach Verarbeitung aller Änderungen übereinstimmen sollen. ^[S-098]

Exactly Once

Begriff für genau-einmalige Verarbeitung innerhalb definierter Grenzen; keine pauschale Ende-zu-Ende-Garantie. ^[S-172]

Function Calling

Providerbegriff für die Auswahl einer definierten Funktion und strukturierter Argumente durch ein Modell. ^[S-082]

GraphQL

Typisierte Abfragesprache und Laufzeit für flexible API-Abfragen und Mutationen. ^[S-122]

gRPC

RPC-Framework mit Protocol Buffers, Codegenerierung und Streaming. ^[S-125]

History ID

Gmail-Fortsetzungsstand für inkrementelle Mailboxänderungen. ^[S-188]

HMAC

Kryptografischer Nachrichtenauthentisierungscode, häufig zur Webhook-Signaturprüfung eingesetzt. ^[S-136]

HTTP 202

Status für angenommene, aber noch nicht abgeschlossene Verarbeitung. ^[S-023]

HTTP 409

Status für Konflikte mit dem aktuellen Zustand einer Ressource. ^[S-023]

HTTP 429

Status für zu viele Anfragen beziehungsweise Drosselung. ^[S-155]

ID Token

OIDC-Token mit Aussagen über die authentisierte Sitzung beziehungsweise Identität; kein allgemeines API-Access-Token. ^[S-156]

Idempotency Key

Vom Client oder System verwendeter Schlüssel, der wiederholte gleiche Vorgänge auf eine fachliche Wirkung abbildet. ^[S-045]

Idempotenz

Eigenschaft, dass eine wiederholte Operation dieselbe beabsichtigte Wirkung wie eine einzelne Ausführung hat. ^[S-023]

Ingress

Eingangspunkt, an dem externe Requests, Webhooks oder Nachrichten in das eigene System gelangen. ^[S-027]

Integration Test

Test des Zusammenspiels mehrerer Komponenten oder Systeme. ^[S-011]

Introspection

Prüfung eines OAuth-Tokens über einen vorgesehenen Endpunkt. ^[S-149]

Issuer

Aussteller eines Tokens oder einer Identitätsaussage. ^[S-075]

Jitter

Zufälliger Anteil einer Retry-Wartezeit zur Vermeidung synchroner Wiederholungsstürme. ^[S-043]

JSON

Textbasiertes Datenformat für strukturierte Werte, Objekte und Arrays. ^[S-130]

JSON Schema

Vokabular zur Beschreibung und Validierung von JSON-Strukturen. ^[S-022]

JSON-RPC

Protokoll für Methodenaufrufe und Antworten über JSON, unter anderem in Protokollökosystemen verwendet. ^[S-129]

JWT

Kompakte Darstellung signierter oder verschlüsselter Claims in einem Tokenformat. ^[S-153]

Kafka

Verteilte Plattform für dauerhafte, partitionierte Ereignisströme. ^[S-091]

Kill Switch

Kontrollierter Mechanismus zum Stoppen von Triggern, Workern oder Außenaktionen einer Integration. ^[S-010]

Least Privilege

Prinzip, nur die minimal notwendigen Rechte für Zweck und Dauer zu vergeben. ^[S-032]

Logical Decoding

PostgreSQL-Verfahren, das Änderungen aus dem Write-Ahead-Log in logische Datensätze überführt. ^[S-179]

MCP

Model Context Protocol; offenes Protokoll zur Verbindung von KI-Hosts mit Tools, Ressourcen und weiteren Fähigkeiten. ^[S-100]

MCP Client

Komponente im Host, die eine Verbindung zu genau einem MCP-Server verwaltet. ^[S-087]

MCP Host

Anwendung, die Nutzerinteraktion, Modell, Policies und mehrere MCP-Clients orchestriert. ^[S-087]

MCP Prompt

Vom Server angebotene Promptvorlage, die der Host kontrolliert in einen Nutzerablauf übernehmen kann. ^[S-109]

MCP Resource

Adressierbarer Inhalt, den ein MCP-Server einem Host bereitstellt. ^[S-108]

MCP Server

Dienst oder lokaler Prozess, der MCP-Fähigkeiten wie Tools oder Resources anbietet. ^[S-087]

MCP Task

Dauerhafter Handle und Zustandsrahmen für langlaufende MCP-Vorgänge. ^[S-112]

MCP Tool

Vom Server beschriebene ausführbare Operation mit Eingabeschema. ^[S-107]

Message

Kommunikationseinheit in A2A, die Inhalte als Parts und eine Rolle trägt. ^[S-211]

Message Broker

Infrastruktur zum Puffern, Routing und Zustellen von Nachrichten. ^[S-134]

Message ID

Eindeutige Kennung einer Nachricht, oft für Korrelation und Deduplizierung verwendbar. ^[S-002]

mTLS

Mutual TLS; beide Kommunikationsseiten weisen sich mit Zertifikaten aus. ^[S-146]

Nonce

Einmalwert zur Bindung oder Replay-Vermeidung in Sicherheitsprotokollen. ^[S-156]

OAuth

Standardrahmen für delegierten Zugriff auf geschützte Ressourcen. ^[S-072]

OAuth Scope

Bezeichner für einen angeforderten oder gewährten Berechtigungsumfang. ^[S-072]

Object-Level Authorization

Prüfung, ob eine Identität auf einen konkreten Datensatz zugreifen darf. ^[S-027]

Observability

Fähigkeit, internen Zustand eines Systems über Traces, Metriken und Logs zu verstehen. ^[S-054]

OData

OASIS-Protokoll für typisierte Datenservices und standardisierte Queryoptionen. ^[S-128]

OpenAPI

Spezifikation zur maschinenlesbaren Beschreibung von HTTP-APIs. ^[S-021]

OpenID Connect

Identitätsschicht auf OAuth 2.0 für standardisierte Anmeldung und ID Tokens. ^[S-156]

Outbox Pattern

Muster, bei dem Datenänderung und zu publizierendes Event in einer lokalen Transaktion gespeichert werden. ^{[S-099; S-177]}

Pagination

Aufteilung großer Ergebnislisten in Seiten oder Cursorabschnitte. ^[S-187]

Part

A2A-Inhaltselement für Text, Datei oder strukturierte Daten. ^[S-211]

PKCE

Erweiterung, die den OAuth-Autorisierungscode an den anfragenden Client bindet. ^[S-073]

Poison Message

Nachricht, die wegen Inhalt oder Fehler wiederholt nicht erfolgreich verarbeitet werden kann. ^[S-170]

Polling

Regelmäßiges aktives Abfragen eines Systems auf neue Daten oder Statusänderungen. ^[S-023]

Problem Details

Standardisiertes JSON- beziehungsweise HTTP-Format für maschinenlesbare Fehlerinformationen. ^[S-024]

Producer

Komponente, die Nachrichten oder Ereignisse erzeugt und veröffentlicht. ^[S-171]

Prompt Injection

Manipulation, bei der untrusted Inhalte ein Modell zu unerwünschtem Verhalten oder Toolgebrauch anweisen. ^[S-033]

Protected Resource Metadata

OAuth-Metadaten einer geschützten Ressource zur Ermittlung von Authorization Server und Anforderungen. ^[S-154]

Protocol Buffer

Sprach- und plattformneutrales Schema- und Binärformat, häufig mit gRPC verwendet. ^[S-127]

Pub/Sub

Muster, bei dem Publisher Nachrichten zu Themen senden und Subscriber sie unabhängig empfangen. ^[S-191]

Queue

Puffer für Aufgaben oder Nachrichten zwischen Produzent und Verbraucher. ^[S-168]

Rate Limit

Begrenzung von Anzahl oder Volumen zulässiger Anfragen in einem Zeitraum. ^[S-155]

Reconciliation

Soll-Ist-Abgleich zwischen Systemen zur Erkennung von Verlust, Duplikat oder Divergenz. ^[S-046]

Refresh Token

Längerlebiges OAuth-Credential zur Beschaffung neuer Access Tokens. ^[S-074]

Replay

Erneute Zustellung oder Verarbeitung eines früheren Events, Requests oder Tokenbeweises. ^[S-136]

Resource Indicator

OAuth-Parameter zur Angabe der Zielressource eines Tokens. ^[S-144]

REST

Architekturstil für ressourcenorientierte, zustandslose Interaktion über ein einheitliches Interface. ^[S-023]

Retry

Erneuter Ausführungsversuch nach einem als vorübergehend bewerteten Fehler. ^[S-043]

Revocation

Ungültigmachen eines Tokens oder Zugangs vor seinem regulären Ablauf. ^[S-150]

RPO

Recovery Point Objective; maximal tolerierter Datenverlustzeitraum. ^[S-012]

RTO

Recovery Time Objective; Zielzeit bis zur Wiederherstellung eines Dienstes. ^[S-012]

Saga

Folge lokaler Transaktionen mit Zuständen und gegebenenfalls kompensierenden Aktionen. ^[S-137]

Sampling

MCP-Fähigkeit, über die ein Server den Host kontrolliert um Modellgenerierung bittet. ^[S-110]

Schema Evolution

Kontrollierte Änderung eines Daten- oder Nachrichtenvertrags über Versionen hinweg. ^[S-006]

Scope Creep

Unkontrollierte Ausweitung von Zweck, Daten oder Berechtigungen einer Integration. ^[S-003]

Secret Store

System zur geschützten Ablage, Ausgabe und Rotation von Geheimnissen. ^[S-030]

Service Account

Nichtmenschliche Identität für Anwendungen oder Automationen. ^[S-014]

SLA

Vertragliche oder organisatorische Leistungszusage zwischen Parteien. ^[S-049]

SLI

Service Level Indicator; gemessene Kennzahl für eine relevante Diensteigenschaft. ^[S-049]

SLO

Service Level Objective; Zielwert für einen SLI über einen Zeitraum. ^[S-049]

Source of Truth

Verbindlicher Ursprung einer Information innerhalb eines definierten Kontextes. ^[S-002]

SSE

Server-Sent Events; unidirektionaler Ereignisstrom vom HTTP-Server zum Client. ^[S-133]

State

Persistierter Zustand eines Vorgangs, Tasks, Workflows oder Datensatzes. ^[S-173]

State Machine

Modell aus Zuständen und erlaubten Übergängen für einen Vorgang. ^[S-137]

Stream

Fortlaufende geordnete Folge von Nachrichten oder Ereignissen. ^[S-171]

Structured Output

Modellausgabe, die einem vorgegebenen Daten- oder JSON-Schema folgen soll. ^[S-085]

Sunset

Geplanter Zeitpunkt, ab dem eine API oder Funktion nicht mehr verfügbar sein soll. ^[S-139]

System of Record

System, das für einen definierten Datensatz oder Zustand als verbindlich gilt. ^[S-002]

Task

In A2A oder MCP persistierter Vorgang mit Status und Ergebnisbezug. ^{[S-211; S-112]}

Timeout

Zeitgrenze, nach der ein wartender Aufruf oder Schritt abgebrochen beziehungsweise als fehlgeschlagen behandelt wird. ^[S-046]

Token Exchange

OAuth-Verfahren zum Austausch eines Tokens gegen ein anderes für definierte Ziel- oder Delegationsbeziehungen. ^[S-148]

Token Passthrough

Ungeprüftes Weiterreichen eines erhaltenen Tokens an einen anderen Dienst; in MCP-Sicherheitsregeln untersagt. ^[S-106]

Tool Calling

Allgemeines Muster, bei dem ein Modell ein verfügbares Tool und strukturierte Argumente auswählt. ^[S-083]

Trace

Zusammenhängende Aufzeichnung eines verteilten Vorgangs über mehrere Spans und Systeme. ^[S-055]

Trace Context

Standardisierte Weitergabe von Trace-Identität und Kontext zwischen Diensten. ^[S-058]

Transactional Outbox

Konkrete Outbox-Umsetzung mit atomarer Speicherung von Geschäftsdaten und Eventdatensatz. ^[S-099]

Trust Boundary

Grenze, an der Daten, Identität oder Code aus einer anderen Vertrauensdomäne eintreten. ^[S-040]

Webhook

HTTP-basierter Callback, mit dem ein Anbieter Ereignisse an einen registrierten Empfänger sendet. ^[S-076]

Webhook Signature

Kryptografischer Nachweis, dass ein Webhook-Body vom erwarteten Absender stammt und unverändert ist. ^[S-136]

Workflow Engine

Laufzeit zur persistenten Orchestrierung mehrstufiger und langlaufender Abläufe. ^[S-173]

Write-Ahead Log

Datenbankprotokoll, das Änderungen vor ihrer endgültigen Datenseitenschreibung festhält. ^[S-179]

Zero Trust

Sicherheitsansatz, der keiner Netzposition pauschal vertraut und jeden Zugriff explizit prüft. ^[S-009]

Quellenmethodik und Belegmatrix

Auswahlprinzip

• Primärquellen werden bevorzugt: RFCs, offene Protokollspezifikationen, Gesetze, Behördenmaterial, offizielle technische Dokumentation, Originalstudien und offizielle Post-Mortems.
• Herstellerdokumentation wird nur für das dokumentierte Produktverhalten verwendet; sie wird nicht als neutraler Beleg für generelle Überlegenheit behandelt.
• Living Standards, Drafts, Produkt- und Sicherheitsseiten tragen hohe oder sehr hohe Refresh-Priorität.
• Ein fehlendes Veröffentlichungsdatum wird ausdrücklich als „Living Documentation; geprüft 08.08.2026“ oder UNKLAR geführt, nicht erfunden.
• Architekturregeln, die aus mehreren Quellen abgeleitet sind, werden als Synthese bezeichnet; die Quellen-ID belegt die Bausteine, nicht ein angebliches wörtliches Zitat.
• Sicherheitsfälle werden aus offiziellen Advisories, Herstellerberichten oder anerkannten Post-Mortems übernommen und mit ihrem konkreten Scope beschrieben.

Kennzahlen

Kompakte Belegmatrix

Vollständiges Quellenregister — 213 Einträge

Jeder Eintrag enthält Herausgeber, Titel, Veröffentlichungsdatum beziehungsweise expliziten Status, Dokumenttyp, Relevanz, Refresh-Priorität und direkte URL. Die Quellen-ID bleibt unabhängig von der thematischen Sortierung stabil.

A. Recht, Datenschutz und Governance

Datenschutz: Drittlandtransfer

^[S-069] Durchführungsbeschluss (EU) 2021/914 — Standardvertragsklauseln

• Autor/Herausgeber: Europäische Kommission
• Datum: 04.06.2021
• Dokumenttyp: EU-Durchführungsbeschluss
• Status: In Kraft
• Relevanz: Instrument für bestimmte Drittlandübermittlungen personenbezogener Daten.
• Refresh-Priorität: mittel
• Direkte URL: [https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj](https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj)

^[S-070] Durchführungsbeschluss (EU) 2023/1795 — EU-US Data Privacy Framework

• Autor/Herausgeber: Europäische Kommission
• Datum: 10.07.2023
• Dokumenttyp: Angemessenheitsbeschluss
• Status: In Kraft am Stichtag; Rechtsentwicklung beobachten
• Relevanz: Angemessenheitsrahmen für zertifizierte US-Organisationen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj](https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj)

Datenschutz: Rollen

^[S-068] Guidelines 07/2020 on the concepts of controller and processor in the GDPR

• Autor/Herausgeber: European Data Protection Board
• Datum: 07.07.2021
• Dokumenttyp: Behördenleitlinie
• Status: Final
• Relevanz: Rollenverteilung Verantwortlicher, gemeinsam Verantwortliche und Auftragsverarbeiter.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.edpb.europa.eu/system/files/2023-10/edpb_guidelines_202007_controllerprocessor_final_en.pdf](https://www.edpb.europa.eu/system/files/2023-10/edpb_guidelines_202007_controllerprocessor_final_en.pdf)

E-Mail und Datenschutz

^[S-077] Orientierungshilfe Maßnahmen zum Schutz personenbezogener Daten bei der Übermittlung per E-Mail

• Autor/Herausgeber: Datenschutzkonferenz (DSK)
• Datum: 16.06.2021
• Dokumenttyp: Behördenorientierung
• Status: Veröffentlicht; Aktualität gegen Stand der Technik prüfen
• Relevanz: Risikobasierte Schutzmaßnahmen für E-Mail-Übermittlungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.datenschutzkonferenz-online.de/media/oh/20210616_orientierungshilfe_e_mail_verschluesselung.pdf](https://www.datenschutzkonferenz-online.de/media/oh/20210616_orientierungshilfe_e_mail_verschluesselung.pdf)

Recht und Compliance

^[S-066] Verordnung (EU) 2016/679 — Datenschutz-Grundverordnung

• Autor/Herausgeber: Europäische Union
• Datum: 27.04.2016
• Dokumenttyp: EU-Verordnung
• Status: In Kraft
• Relevanz: Datenschutzrechtliche Anforderungen an personenbezogene Daten in Entwicklung und Betrieb.
• Refresh-Priorität: mittel
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

^[S-067] Verordnung (EU) 2024/1689 — AI Act

• Autor/Herausgeber: Europäische Union
• Datum: 13.06.2024
• Dokumenttyp: EU-Verordnung
• Status: In Kraft; gestaffelte Anwendung
• Relevanz: Pflichten über den Lebenszyklus bestimmter KI-Systeme, einschließlich Qualität und Monitoring.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2024/1689/oj](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)

B. Identität, OAuth, Tokens und Berechtigungen

Autorisierung

^[S-141] RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage

• Autor/Herausgeber: IETF
• Datum: 10.2012
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Nutzung und Risiken von Bearer Access Tokens.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc6750.html](https://www.rfc-editor.org/rfc/rfc6750.html)

^[S-150] RFC 7009 — OAuth 2.0 Token Revocation

• Autor/Herausgeber: IETF
• Datum: 08.2013
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Widerruf von Access- und Refresh-Tokens.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7009.html](https://www.rfc-editor.org/rfc/rfc7009.html)

^[S-143] RFC 7591 — OAuth 2.0 Dynamic Client Registration Protocol

• Autor/Herausgeber: IETF
• Datum: 07.2015
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Dynamische Registrierung von OAuth-Clients; MCP 2026 kennzeichnet den bisherigen Einsatz als deprecatet.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7591.html](https://www.rfc-editor.org/rfc/rfc7591.html)

^[S-149] RFC 7662 — OAuth 2.0 Token Introspection

• Autor/Herausgeber: IETF
• Datum: 10.2015
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Abfrage des aktiven Zustands und der Metadaten eines Tokens.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7662.html](https://www.rfc-editor.org/rfc/rfc7662.html)

^[S-142] RFC 8414 — OAuth 2.0 Authorization Server Metadata

• Autor/Herausgeber: IETF
• Datum: 06.2018
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Maschinenlesbare Metadaten eines Authorization Servers.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8414.html](https://www.rfc-editor.org/rfc/rfc8414.html)

^[S-148] RFC 8693 — OAuth 2.0 Token Exchange

• Autor/Herausgeber: IETF
• Datum: 01.2020
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Austausch und Delegation von Tokens zwischen Diensten.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8693.html](https://www.rfc-editor.org/rfc/rfc8693.html)

^[S-146] RFC 8705 — OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

• Autor/Herausgeber: IETF
• Datum: 02.2020
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Sendergebundene Tokens und mTLS-Clientauthentisierung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8705.html](https://www.rfc-editor.org/rfc/rfc8705.html)

^[S-144] RFC 8707 — Resource Indicators for OAuth 2.0

• Autor/Herausgeber: IETF
• Datum: 02.2020
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Bindung einer Autorisierungsanfrage an Zielressourcen.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8707.html](https://www.rfc-editor.org/rfc/rfc8707.html)

^[S-145] RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification

• Autor/Herausgeber: IETF
• Datum: 03.2022
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Issuer-Identifikation gegen Mix-up-Angriffe.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9207.html](https://www.rfc-editor.org/rfc/rfc9207.html)

^[S-147] RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP)

• Autor/Herausgeber: IETF
• Datum: 09.2023
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Anwendungsseitige Proof-of-Possession-Bindung für Access Tokens.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9449.html](https://www.rfc-editor.org/rfc/rfc9449.html)

^[S-154] RFC 9728 — OAuth 2.0 Protected Resource Metadata

• Autor/Herausgeber: IETF
• Datum: 23.04.2025
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Metadaten geschützter Ressourcen und Discovery-Baustein des MCP-Autorisierungsmodells.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9728.html](https://www.rfc-editor.org/rfc/rfc9728.html)

^[S-140] The OAuth 2.1 Authorization Framework — draft-ietf-oauth-v2-1-15

• Autor/Herausgeber: IETF OAuth Working Group
• Datum: 02.03.2026; läuft 03.09.2026 ab
• Dokumenttyp: Internet-Draft
• Status: Work in progress; kein RFC
• Relevanz: Konsolidierter Entwurf moderner OAuth-Praxis; Status darf nicht als fertiger Standard dargestellt werden.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/)

Fälle: Identität

^[S-205] MFA isn’t MFA: the social engineering attack that compromised 27 cloud customers

• Autor/Herausgeber: Retool
• Datum: 13.09.2023
• Dokumenttyp: Offizieller Incidentbericht
• Status: Historischer Vorfall
• Relevanz: Social Engineering und Kontowiederherstellung führten zu Zugriff auf Kundensysteme.
• Refresh-Priorität: niedrig
• Direkte URL: [https://retool.com/blog/mfa-isnt-mfa](https://retool.com/blog/mfa-isnt-mfa)

Fälle: Secrets und CI

^[S-204] January 4, 2023 Incident Report

• Autor/Herausgeber: CircleCI
• Datum: 12.01.2023
• Dokumenttyp: Offizieller Incidentbericht
• Status: Historischer Vorfall
• Relevanz: Gestohlene Sitzung ermöglichte Exfiltration gespeicherter Variablen, Schlüssel und Tokens; breite Rotation erforderlich.
• Refresh-Priorität: niedrig
• Direkte URL: [https://circleci.com/blog/jan-4-2023-incident-report/](https://circleci.com/blog/jan-4-2023-incident-report/)

Identität

^[S-156] OpenID Connect Core 1.0 incorporating errata set 2

• Autor/Herausgeber: OpenID Foundation
• Datum: 15.12.2023
• Dokumenttyp: Offene Identitätsspezifikation
• Status: Final Specification
• Relevanz: Identitätsschicht auf OAuth 2.0 für Authentisierung und Claims.
• Refresh-Priorität: mittel
• Direkte URL: [https://openid.net/specs/openid-connect-core-1_0.html](https://openid.net/specs/openid-connect-core-1_0.html)

^[S-157] OpenID Connect Discovery 1.0 incorporating errata set 2

• Autor/Herausgeber: OpenID Foundation
• Datum: 15.12.2023
• Dokumenttyp: Offene Identitätsspezifikation
• Status: Final Specification
• Relevanz: Discovery von OpenID-Provider-Metadaten.
• Refresh-Priorität: mittel
• Direkte URL: [https://openid.net/specs/openid-connect-discovery-1_0.html](https://openid.net/specs/openid-connect-discovery-1_0.html)

Identität und APIs

^[S-072] RFC 6749 — The OAuth 2.0 Authorization Framework

• Autor/Herausgeber: IETF
• Datum: 10.2012
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Grundrahmen delegierter Autorisierung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc6749.html](https://www.rfc-editor.org/rfc/rfc6749.html)

^[S-073] RFC 7636 — Proof Key for Code Exchange by OAuth Public Clients

• Autor/Herausgeber: IETF
• Datum: 09.2015
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Schutz des Authorization Code Flow gegen Code-Abgriff.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7636.html](https://www.rfc-editor.org/rfc/rfc7636.html)

^[S-075] RFC 8725 — JSON Web Token Best Current Practices

• Autor/Herausgeber: IETF
• Datum: 02.2020
• Dokumenttyp: Best Current Practice / RFC
• Status: BCP 225
• Relevanz: Sichere Validierung und Nutzung von JWT.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8725.html](https://www.rfc-editor.org/rfc/rfc8725.html)

^[S-074] RFC 9700 — Best Current Practice for OAuth 2.0 Security

• Autor/Herausgeber: IETF
• Datum: 01.2025
• Dokumenttyp: Best Current Practice / RFC
• Status: BCP 240
• Relevanz: Aktuelle Sicherheitspraktiken und überholte OAuth-Muster.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9700.html](https://www.rfc-editor.org/rfc/rfc9700.html)

Identität und Authentisierung

^[S-071] SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management

• Autor/Herausgeber: NIST
• Datum: 31.07.2025
• Dokumenttyp: Behördenstandard
• Status: Final; ersetzt SP 800-63B
• Relevanz: Aktueller Referenzrahmen für Authenticatoren, MFA, Passwort- und Phishingresistenz.
• Refresh-Priorität: hoch
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/63/b/4/final](https://csrc.nist.gov/pubs/sp/800/63/b/4/final)

Konfiguration und Secrets

^[S-030] Secrets Management Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Security-Leitlinie
• Status: Living Documentation
• Relevanz: Lebenszyklus und Schutz von Zugangsdaten und Schlüsseln.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)

MCP: Autorisierung

^[S-106] Authorization Security Considerations — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Audience-Prüfung, Verbot des Token-Passthroughs, sichere Tokenspeicherung und Refresh-Token-Schutz.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations)

^[S-105] Authorization Server Discovery — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Protected Resource Metadata und Discovery des zuständigen Authorization Servers.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/authorization-server-discovery](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/authorization-server-discovery)

^[S-104] Authorization — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Autorisierungsrahmen für HTTP-basierte MCP-Implementierungen und Credential-Bezug bei stdio.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)

Tokens

^[S-151] RFC 7515 — JSON Web Signature (JWS)

• Autor/Herausgeber: IETF
• Datum: 05.2015
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Signaturformat für JSON-basierte Sicherheitsobjekte.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7515.html](https://www.rfc-editor.org/rfc/rfc7515.html)

^[S-152] RFC 7517 — JSON Web Key (JWK)

• Autor/Herausgeber: IETF
• Datum: 05.2015
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: JSON-Darstellung kryptografischer Schlüssel.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7517.html](https://www.rfc-editor.org/rfc/rfc7517.html)

^[S-153] RFC 7519 — JSON Web Token (JWT)

• Autor/Herausgeber: IETF
• Datum: 05.2015
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Kompaktes Claim-Format; sichere Profile erfordern zusätzliche Regeln.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7519.html](https://www.rfc-editor.org/rfc/rfc7519.html)

C. Model Context Protocol

Fälle: MCP-Sicherheit

^[S-201] MCP Horror Stories: GitHub Prompt Injection

• Autor/Herausgeber: Docker
• Datum: 14.08.2025
• Dokumenttyp: Sicherheitsanalyse / Demonstration
• Status: Security Research; kein bestätigter Massenvorfall
• Relevanz: Demonstration einer indirekten Prompt Injection mit möglicher Datenexfiltration über Werkzeugrechte.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.docker.com/blog/mcp-horror-stories-github-prompt-injection/](https://www.docker.com/blog/mcp-horror-stories-github-prompt-injection/)

^[S-200] GHSA-232v-j27c-5pp6 — MCPJam Inspector unauthenticated RCE

• Autor/Herausgeber: GitHub Advisory Database
• Datum: 16.01.2026
• Dokumenttyp: Sicherheitsadvisory
• Status: Behobene Schwachstelle
• Relevanz: Netzwerkbindung und fehlende Authentisierung führten zu unauthentisierter Codeausführung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://github.com/advisories/GHSA-232v-j27c-5pp6](https://github.com/advisories/GHSA-232v-j27c-5pp6)

^[S-199] GHSA-6xpm-ggf7-wc3p — mcp-remote command injection

• Autor/Herausgeber: GitHub Advisory Database
• Datum: 09.07.2025
• Dokumenttyp: Sicherheitsadvisory
• Status: Behobene Schwachstelle
• Relevanz: Unvertrauenswürdiger Authorization Endpoint konnte zu Befehlsinjektion führen.
• Refresh-Priorität: hoch
• Direkte URL: [https://github.com/advisories/GHSA-6xpm-ggf7-wc3p](https://github.com/advisories/GHSA-6xpm-ggf7-wc3p)

^[S-198] GHSA-7f8r-222p-6f5g — MCP Inspector remote code execution

• Autor/Herausgeber: Model Context Protocol / GitHub Security Advisory
• Datum: 13.06.2025
• Dokumenttyp: Offizielles Sicherheitsadvisory
• Status: Behoben ab Version 0.14.1
• Relevanz: Fehlende Authentisierung zwischen Inspector-Client und Proxy ermöglichte unauthentisierte Befehlsausführung.
• Refresh-Priorität: hoch
• Direkte URL: [https://github.com/modelcontextprotocol/inspector/security/advisories/GHSA-7f8r-222p-6f5g](https://github.com/modelcontextprotocol/inspector/security/advisories/GHSA-7f8r-222p-6f5g)

MCP

^[S-087] Architecture - Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Host-Client-Server-Architektur und Protokollkern von MCP.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/architecture](https://modelcontextprotocol.io/specification/2026-07-28/architecture)

^[S-089] Security Best Practices

• Autor/Herausgeber: Model Context Protocol
• Datum: Veröffentlichungsdatum UNKLAR; Draft, geprüft 08.08.2026
• Dokumenttyp: Offizielle Sicherheitsdokumentation
• Status: Draft / Living Documentation
• Relevanz: Angriffe und Gegenmaßnahmen für MCP-Implementierungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/docs/draft/tutorials/security/security_best_practices](https://modelcontextprotocol.io/docs/draft/tutorials/security/security_best_practices)

^[S-088] The 2026-07-28 Specification

• Autor/Herausgeber: Soria Parra und Delimarsky / Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizieller Release-Beitrag
• Status: Aktueller Release-Stand
• Relevanz: Stateless Core, MRTR, Header-Routing, Caching und Auth-Härtung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://blog.modelcontextprotocol.io/posts/2026-07-28/](https://blog.modelcontextprotocol.io/posts/2026-07-28/)

MCP: Erweiterungen

^[S-114] Enterprise-Managed Authorization Extension

• Autor/Herausgeber: Model Context Protocol
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Protokollerweiterung
• Status: Living Documentation
• Relevanz: Unternehmensgesteuerte Autorisierung und administrative Einbindung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization)

^[S-113] Extensions Overview

• Autor/Herausgeber: Model Context Protocol
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Protokolldokumentation
• Status: Living Documentation
• Relevanz: Formaler Erweiterungsrahmen für optionale Protokollfähigkeiten.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/extensions/overview](https://modelcontextprotocol.io/extensions/overview)

^[S-112] Tasks Extension — Overview

• Autor/Herausgeber: Model Context Protocol
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Protokollerweiterung
• Status: Offizielle Erweiterung; aktueller Stand prüfen
• Relevanz: Dauerhafte Handles, Polling und Zustände für langlaufende oder unterbrechbare Vorgänge.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/extensions/tasks/overview](https://modelcontextprotocol.io/extensions/tasks/overview)

MCP: Fähigkeiten

^[S-111] Elicitation — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Strukturierte Nutzereingaben und Schutz externer Drittanbieter-Credentials vor Transit durch den MCP-Client.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation](https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation)

^[S-109] Prompts — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Serverseitig angebotene Promptvorlagen, Eingabevalidierung und Sicherheitsgrenzen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/server/prompts](https://modelcontextprotocol.io/specification/2026-07-28/server/prompts)

^[S-108] Resources — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Bereitstellung adressierbarer Ressourcen, URI-Prüfung, Zugriffskontrolle und Pfadschutz.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/server/resources](https://modelcontextprotocol.io/specification/2026-07-28/server/resources)

^[S-110] Sampling — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Server können Modellaufrufe über Clients anfordern, während Client und Host Modellzugriff und Berechtigungen kontrollieren.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/client/sampling](https://modelcontextprotocol.io/specification/2026-07-28/client/sampling)

^[S-107] Tools — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Werkzeugdefinition, Eingabevalidierung, Zugriffskontrolle, Rate Limits, Bestätigungen, Timeouts und Protokollierung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/server/tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)

MCP: Governance

^[S-118] Linux Foundation Announces the Formation of the Agentic AI Foundation

• Autor/Herausgeber: Linux Foundation
• Datum: 09.12.2025
• Dokumenttyp: Offizielle Stiftungsmitteilung
• Status: Governance-Ankündigung
• Relevanz: Einordnung der MCP-Governance unter der Agentic AI Foundation.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)

^[S-117] Development Roadmap

• Autor/Herausgeber: Model Context Protocol
• Datum: 05.03.2026
• Dokumenttyp: Offizielle Roadmap
• Status: Planungsstand; nicht normativ
• Relevanz: Geplante Entwicklungsfelder des Protokolls und der SDK-/Ökosystemarbeit.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/development/roadmap](https://modelcontextprotocol.io/development/roadmap)

MCP: Kern

^[S-101] Key Changes — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielles Änderungsprotokoll
• Status: Aktueller Changelog
• Relevanz: Stateless Core, Wegfall des Initialisierungshandshakes, MRTR, Header-Routing, Cachebarkeit, Erweiterungsrahmen und Deprecation-Regeln.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog)

^[S-100] Model Context Protocol Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand am Stichtag
• Relevanz: Autoritative Spezifikation des offenen Protokolls zur Verbindung von LLM-Anwendungen mit Datenquellen und Werkzeugen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28)

^[S-102] Overview — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Zustandslosigkeit und Grundmuster des Protokolls.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/basic](https://modelcontextprotocol.io/specification/2026-07-28/basic)

MCP: Transport

^[S-103] Transports — Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Standardtransporte stdio und Streamable HTTP sowie Framing- und Transportanforderungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/basic/transports](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports)

MCP: Ökosystem

^[S-116] Introducing the MCP Registry Preview

• Autor/Herausgeber: Model Context Protocol
• Datum: 08.09.2025
• Dokumenttyp: Offizieller Projektbeitrag
• Status: Preview-Ankündigung
• Relevanz: Ziel, Umfang und Grenzen des offiziellen Registry-Ansatzes.
• Refresh-Priorität: hoch
• Direkte URL: [https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/](https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/)

^[S-115] Official MCP Registry

• Autor/Herausgeber: Model Context Protocol
• Datum: Living Registry; geprüft 08.08.2026
• Dokumenttyp: Offizielles Registry-Verzeichnis
• Status: Preview/fortlaufend
• Relevanz: Metadaten und Auffindbarkeit veröffentlichter MCP-Server; kein automatisches Sicherheitszertifikat.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://registry.modelcontextprotocol.io/](https://registry.modelcontextprotocol.io/)

D. Agent2Agent und agentische Protokolle

A2A: Abgrenzung

^[S-213] A2A and MCP

• Autor/Herausgeber: A2A Protocol Project / Linux Foundation
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Protokolldokumentation
• Status: Version 1.0
• Relevanz: Abgrenzung: A2A verbindet Agenten miteinander, MCP verbindet Agenten beziehungsweise Hosts mit Tools, Daten und Ressourcen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://a2a-protocol.org/latest/topics/a2a-and-mcp/](https://a2a-protocol.org/latest/topics/a2a-and-mcp/)

A2A: Governance

^[S-209] A2A Protocol Ships v1.0: Production-Ready Standard for Agent-to-Agent Communication

• Autor/Herausgeber: A2A Protocol Project / Linux Foundation
• Datum: 20.04.2026
• Dokumenttyp: Offizielle Release-Mitteilung
• Status: Version 1.0 veröffentlicht
• Relevanz: Release-Status und Einordnung als erste stabile, produktionsreife Fassung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://a2a-protocol.org/latest/announcing-1.0/](https://a2a-protocol.org/latest/announcing-1.0/)

A2A: Kern

^[S-208] Agent2Agent (A2A) Protocol Specification 1.0

• Autor/Herausgeber: A2A Protocol Project / Linux Foundation
• Datum: 20.04.2026; geprüft 08.08.2026
• Dokumenttyp: Offene Protokollspezifikation
• Status: Stabile Version 1.0
• Relevanz: Interoperabilität eigenständiger, potenziell opaker Agentensysteme über Agent Cards, Messages, Tasks und Artifacts.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://a2a-protocol.org/latest/specification/](https://a2a-protocol.org/latest/specification/)

^[S-211] Core Concepts

• Autor/Herausgeber: A2A Protocol Project / Linux Foundation
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Protokolldokumentation
• Status: Version 1.0
• Relevanz: Agent Cards, Messages, Parts, Artifacts, Tasks, Streaming und asynchrone Interaktion.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://a2a-protocol.org/latest/topics/key-concepts/](https://a2a-protocol.org/latest/topics/key-concepts/)

^[S-210] What's New in A2A Protocol v1.0

• Autor/Herausgeber: A2A Protocol Project / Linux Foundation
• Datum: 20.04.2026; geprüft 08.08.2026
• Dokumenttyp: Offizielle Release-Dokumentation
• Status: Version 1.0
• Relevanz: Strukturelle und semantische Änderungen gegenüber v0.3.
• Refresh-Priorität: hoch
• Direkte URL: [https://a2a-protocol.org/latest/whats-new-v1/](https://a2a-protocol.org/latest/whats-new-v1/)

A2A: Sicherheit

^[S-212] Enterprise Features

• Autor/Herausgeber: A2A Protocol Project / Linux Foundation
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Protokolldokumentation
• Status: Version 1.0
• Relevanz: Einbindung etablierter HTTP-, OAuth-, OIDC-, Monitoring- und Governanceverfahren.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://a2a-protocol.org/latest/topics/enterprise-ready/](https://a2a-protocol.org/latest/topics/enterprise-ready/)

E. API-Verträge, HTTP, Transport und Webhooks

API-Lebenszyklus

^[S-138] RFC 8594 — The Sunset HTTP Header Field

• Autor/Herausgeber: IETF
• Datum: 05.2019
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Kommunikation geplanter Außerbetriebnahme von HTTP-Ressourcen.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8594.html](https://www.rfc-editor.org/rfc/rfc8594.html)

^[S-139] RFC 9745 — The Deprecation HTTP Response Header Field

• Autor/Herausgeber: IETF
• Datum: 03.2025
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Standardisierte Kennzeichnung veralteter API-Ressourcen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9745.html](https://www.rfc-editor.org/rfc/rfc9745.html)

API-Verträge

^[S-120] AsyncAPI Specification 3.1.0

• Autor/Herausgeber: AsyncAPI Initiative
• Datum: 31.01.2026
• Dokumenttyp: Offene Spezifikation
• Status: Aktuelle veröffentlichte Version am Stichtag
• Relevanz: Protokollunabhängige Beschreibung nachrichten- und ereignisgetriebener Schnittstellen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.asyncapi.com/docs/reference/specification/latest](https://www.asyncapi.com/docs/reference/specification/latest)

^[S-121] Release Notes — AsyncAPI 3.1.0

• Autor/Herausgeber: AsyncAPI Initiative
• Datum: 31.01.2026
• Dokumenttyp: Offizieller Release-Beitrag
• Status: Veröffentlichte Version
• Relevanz: Änderungen und Status der Version 3.1.0.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.asyncapi.com/blog/release-notes-3.1.0](https://www.asyncapi.com/blog/release-notes-3.1.0)

^[S-123] GraphQL Specification Versions

• Autor/Herausgeber: GraphQL Specification Project
• Datum: Living Index; geprüft 08.08.2026
• Dokumenttyp: Offizieller Versionsindex
• Status: Stabile Ausgabe September 2025; Working Draft Juni 2026
• Relevanz: Trennung stabiler Editionen von Vorab-Working-Drafts.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://spec.graphql.org/](https://spec.graphql.org/)

^[S-122] GraphQL Specification — September 2025 Edition

• Autor/Herausgeber: GraphQL Specification Project
• Datum: 03.09.2025
• Dokumenttyp: Offene Spezifikation
• Status: Letzte stabile Ausgabe am Stichtag
• Relevanz: Typsystem, Abfragesprache, Validierung und Ausführung von GraphQL.
• Refresh-Priorität: hoch
• Direkte URL: [https://spec.graphql.org/September2025/](https://spec.graphql.org/September2025/)

^[S-124] GraphQL over HTTP

• Autor/Herausgeber: GraphQL over HTTP Working Group
• Datum: Working Draft; geprüft 08.08.2026
• Dokumenttyp: Vorab-Spezifikation
• Status: Working Draft, kein finaler Standard
• Relevanz: HTTP-Transportkonventionen für GraphQL; Status muss als Entwurf gekennzeichnet werden.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://graphql.github.io/graphql-over-http/](https://graphql.github.io/graphql-over-http/)

^[S-130] RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format

• Autor/Herausgeber: IETF / Bray
• Datum: 12.2017
• Dokumenttyp: Internet Standard
• Status: STD 90 / RFC
• Relevanz: Normative JSON-Grundlage für zahlreiche API- und Protokollverträge.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8259.html](https://www.rfc-editor.org/rfc/rfc8259.html)

^[S-129] JSON-RPC 2.0 Specification

• Autor/Herausgeber: JSON-RPC Working Group
• Datum: 26.03.2010
• Dokumenttyp: Offene Spezifikation
• Status: Stabile Spezifikation
• Relevanz: Nachrichtenformat für Remote Procedure Calls; Grundlage des MCP-Nachrichtenmodells.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.jsonrpc.org/specification](https://www.jsonrpc.org/specification)

^[S-128] OData Version 4.01 — Part 1: Protocol

• Autor/Herausgeber: OASIS
• Datum: 30.01.2020
• Dokumenttyp: OASIS Standard
• Status: OASIS Standard
• Relevanz: Standardisiertes Datenzugriffsprotokoll, relevant für zahlreiche ERP- und Geschäftsanwendungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html](https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html)

^[S-119] Arazzo Specification 1.1.0

• Autor/Herausgeber: OpenAPI Initiative
• Datum: 17.05.2026
• Dokumenttyp: Offene Spezifikation
• Status: Aktuelle veröffentlichte Version
• Relevanz: Maschinenlesbare Beschreibung von Sequenzen, Abhängigkeiten und Ergebnissen mehrerer API-Aufrufe.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://spec.openapis.org/arazzo/latest.html](https://spec.openapis.org/arazzo/latest.html)

^[S-127] Protocol Buffers Documentation

• Autor/Herausgeber: Protocol Buffers Project
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Sprach- und plattformneutrales, schemaorientiertes Serialisierungsformat.
• Refresh-Priorität: hoch
• Direkte URL: [https://protobuf.dev/overview/](https://protobuf.dev/overview/)

^[S-126] Core concepts, architecture and lifecycle

• Autor/Herausgeber: gRPC Authors
• Datum: 11.05.2026; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Unary-, Client-, Server- und bidirektionale Streaming-RPCs sowie Lebenszyklus.
• Refresh-Priorität: hoch
• Direkte URL: [https://grpc.io/docs/what-is-grpc/core-concepts/](https://grpc.io/docs/what-is-grpc/core-concepts/)

^[S-125] Introduction to gRPC

• Autor/Herausgeber: gRPC Authors
• Datum: 12.11.2024; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: IDL-basierte Remote Procedure Calls und Protocol Buffers als Standardformat.
• Refresh-Priorität: hoch
• Direkte URL: [https://grpc.io/docs/what-is-grpc/introduction/](https://grpc.io/docs/what-is-grpc/introduction/)

Ereignisse und Integration

^[S-025] CloudEvents Specification 1.0.2

• Autor/Herausgeber: Cloud Native Computing Foundation
• Datum: 03.02.2022
• Dokumenttyp: Offene Spezifikation
• Status: Version 1.0.2
• Relevanz: Standardisiertes Ereignisformat für verteilte Systeme.
• Refresh-Priorität: mittel
• Direkte URL: [https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md)

Rate Limits

^[S-155] RFC 6585 — Additional HTTP Status Codes

• Autor/Herausgeber: IETF
• Datum: 04.2012
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Status 429 Too Many Requests und weitere HTTP-Erweiterungen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc6585.html](https://www.rfc-editor.org/rfc/rfc6585.html)

Schnittstellen und Fehlerbehandlung

^[S-024] RFC 9457 — Problem Details for HTTP APIs

• Autor/Herausgeber: IETF / Nottingham, Wilde und Dalal
• Datum: 07.2023
• Dokumenttyp: Internetstandard
• Status: Standards Track
• Relevanz: Standardisiertes Fehlerformat für HTTP-APIs.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9457.html](https://www.rfc-editor.org/rfc/rfc9457.html)

Schnittstellen und Reliability

^[S-023] RFC 9110 — HTTP Semantics

• Autor/Herausgeber: IETF / Fielding, Nottingham und Reschke
• Datum: 06.2022
• Dokumenttyp: Internetstandard
• Status: Standards Track
• Relevanz: HTTP-Semantik, Methoden, Statuscodes und Idempotenz.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9110.html](https://www.rfc-editor.org/rfc/rfc9110.html)

Schnittstellen und Verträge

^[S-022] JSON Schema — Draft 2020-12 Core

• Autor/Herausgeber: JSON Schema project
• Datum: 31.08.2022
• Dokumenttyp: Offene Spezifikation
• Status: Aktuelle stabile Draft-Familie am Stichtag
• Relevanz: Validierung und Beschreibung strukturierter JSON-Daten.
• Refresh-Priorität: mittel
• Direkte URL: [https://json-schema.org/draft/2020-12/json-schema-core](https://json-schema.org/draft/2020-12/json-schema-core)

^[S-021] OpenAPI Specification 3.2.0

• Autor/Herausgeber: OpenAPI Initiative
• Datum: 19.09.2025
• Dokumenttyp: Offene Spezifikation
• Status: Aktuelle Fassung am Stichtag
• Relevanz: Maschinenlesbarer Vertrag für HTTP-APIs.
• Refresh-Priorität: hoch
• Direkte URL: [https://spec.openapis.org/oas/v3.2.0.html](https://spec.openapis.org/oas/v3.2.0.html)

Transport

^[S-132] RFC 6455 — The WebSocket Protocol

• Autor/Herausgeber: IETF
• Datum: 12.2011
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Bidirektionaler, langlebiger Nachrichtentransport über Web-Infrastruktur.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc6455.html](https://www.rfc-editor.org/rfc/rfc6455.html)

^[S-131] RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3

• Autor/Herausgeber: IETF
• Datum: 08.2018
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Transportverschlüsselung für netzbasierte Schnittstellen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8446.html](https://www.rfc-editor.org/rfc/rfc8446.html)

^[S-133] Server-sent events — HTML Living Standard

• Autor/Herausgeber: WHATWG
• Datum: Living Standard; geprüft 08.08.2026
• Dokumenttyp: Webstandard
• Status: Living Standard
• Relevanz: Einseitiger Ereignisstrom vom Server zum Browser über EventSource.
• Refresh-Priorität: hoch
• Direkte URL: [https://html.spec.whatwg.org/multipage/server-sent-events.html](https://html.spec.whatwg.org/multipage/server-sent-events.html)

Transport und TLS

^[S-039] Transport Layer Security Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: TLS-Konfiguration und Zertifikatsbetrieb.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)

Webhooks

^[S-136] Standard Webhooks Specification

• Autor/Herausgeber: Standard Webhooks
• Datum: Community Draft; geprüft 08.08.2026
• Dokumenttyp: Community-Spezifikation
• Status: Living Draft; kein IETF-Standard
• Relevanz: Gemeinsamer Vorschlag für Signaturen, Metadaten und Zustellung von Webhooks.
• Refresh-Priorität: hoch
• Direkte URL: [https://github.com/standard-webhooks/standard-webhooks/blob/main/spec/standard-webhooks.md](https://github.com/standard-webhooks/standard-webhooks/blob/main/spec/standard-webhooks.md)

F. Messaging, Workflows, Events und Datenintegration

Daten und Suche

^[S-098] PostgreSQL 18 Documentation: Concurrency Control

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Veröffentlichungsdatum UNKLAR; Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Dokumentation
• Status: Living Documentation
• Relevanz: Transaktionen, Isolation und MVCC.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/18/mvcc.html](https://www.postgresql.org/docs/18/mvcc.html)

^[S-099] PostgreSQL 18 Documentation: Transactions

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Veröffentlichungsdatum UNKLAR; Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Dokumentation
• Status: Living Documentation
• Relevanz: Atomare Änderungen und Rollback in relationalen Datenbanken.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/18/tutorial-transactions.html](https://www.postgresql.org/docs/18/tutorial-transactions.html)

Datenintegration

^[S-178] Debezium Features

• Autor/Herausgeber: Debezium Project
• Datum: Stable Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Logbasierte CDC im Vergleich zu Polling und Dual Writes.
• Refresh-Priorität: hoch
• Direkte URL: [https://debezium.io/documentation/reference/stable/features.html](https://debezium.io/documentation/reference/stable/features.html)

^[S-177] Debezium Reference Documentation

• Autor/Herausgeber: Debezium Project
• Datum: 04.08.2026; Stable 3.6
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Aktueller stabiler Stand am Stichtag
• Relevanz: Change Data Capture und geordnete Änderungsereignisse aus Datenbanken.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://debezium.io/documentation/reference/stable/index.html](https://debezium.io/documentation/reference/stable/index.html)

^[S-180] PostgreSQL 18 Documentation — Logical Decoding Concepts

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Dokumentation
• Status: Living Documentation
• Relevanz: Replikationsslots, geordnete Änderungsströme und betriebliche Speicherfolgen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/logicaldecoding-explanation.html](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html)

^[S-179] PostgreSQL 18 Documentation — Logical Replication

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Dokumentation
• Status: Living Documentation
• Relevanz: Publikations-/Abonnementmodell für logische Änderungsübertragung.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/logical-replication.html](https://www.postgresql.org/docs/current/logical-replication.html)

Events und Workflows

^[S-091] Kafka 4.3 Documentation: Design and delivery semantics

• Autor/Herausgeber: Apache Kafka
• Datum: 22.05.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Aktueller Dokumentationsstand
• Relevanz: Partitionierte Ereignislogs und Zustellsemantik.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://kafka.apache.org/43/documentation/](https://kafka.apache.org/43/documentation/)

Messaging

^[S-168] Amazon SQS standard queues

• Autor/Herausgeber: Amazon Web Services
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: At-least-once-Zustellung und mögliche Duplikate bzw. Reihenfolgeabweichungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html)

^[S-169] Amazon SQS visibility timeout

• Autor/Herausgeber: Amazon Web Services
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Zeitfenster für Verarbeitung und erneute Sichtbarkeit nicht gelöschter Nachrichten.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html)

^[S-170] Using dead-letter queues in Amazon SQS

• Autor/Herausgeber: Amazon Web Services
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Isolation dauerhaft fehlgeschlagener Nachrichten für Analyse und Wiederanlauf.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)

^[S-171] Design and delivery semantics — Kafka 4.1

• Autor/Herausgeber: Apache Kafka
• Datum: 22.05.2026; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Aktueller stabiler Dokumentationsstand
• Relevanz: At-least-once, idempotente Producer und Grenzen von Exactly-once-Aussagen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://kafka.apache.org/41/design/design/](https://kafka.apache.org/41/design/design/)

^[S-172] Producer Configs — enable.idempotence

• Autor/Herausgeber: Apache Kafka
• Datum: 22.05.2026; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Aktueller stabiler Dokumentationsstand
• Relevanz: Konfigurationsbedingungen des idempotenten Producers.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://kafka.apache.org/41/configuration/producer-configs/](https://kafka.apache.org/41/configuration/producer-configs/)

^[S-134] Advanced Message Queuing Protocol (AMQP) Version 1.0

• Autor/Herausgeber: OASIS
• Datum: 29.10.2012
• Dokumenttyp: OASIS Standard
• Status: OASIS Standard
• Relevanz: Interoperables Nachrichtenprotokoll für Broker- und Messaging-Szenarien.
• Refresh-Priorität: niedrig
• Direkte URL: [https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html](https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html)

^[S-135] MQTT Version 5.0

• Autor/Herausgeber: OASIS
• Datum: 07.03.2019
• Dokumenttyp: OASIS Standard
• Status: OASIS Standard
• Relevanz: Leichtgewichtiges Publish/Subscribe-Protokoll, insbesondere für Geräte- und Telemetrieszenarien.
• Refresh-Priorität: niedrig
• Direkte URL: [https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)

Storage und Events

^[S-183] Adding objects to versioning-enabled buckets

• Autor/Herausgeber: Amazon Web Services
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Objektversionierung als Schutz- und Wiederherstellungsbaustein.
• Refresh-Priorität: mittel
• Direkte URL: [https://docs.aws.amazon.com/AmazonS3/latest/userguide/AddingObjectstoVersioningEnabledBuckets.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AddingObjectstoVersioningEnabledBuckets.html)

^[S-181] Amazon S3 Event Notifications

• Autor/Herausgeber: Amazon Web Services
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Ereignisbenachrichtigungen für Objektänderungen; at-least-once-orientierte Verarbeitung erfordert Idempotenz.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html)

^[S-182] Uploading and copying objects using multipart upload

• Autor/Herausgeber: Amazon Web Services
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Mehrteilige Übertragung großer Objekte und notwendige Abschluss-/Abbruchlogik.
• Refresh-Priorität: mittel
• Direkte URL: [https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html)

Workflows

^[S-137] Business Process Model and Notation (BPMN) Version 2.0.2

• Autor/Herausgeber: Object Management Group
• Datum: 01.2014
• Dokumenttyp: OMG Standard
• Status: Formale Spezifikation
• Relevanz: Modellierung von Geschäftsprozessen und Orchestrierung; keine KI-spezifische Spezifikation.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.omg.org/spec/BPMN/2.0.2/](https://www.omg.org/spec/BPMN/2.0.2/)

^[S-175] Activity Definition — retry policy

• Autor/Herausgeber: Temporal Technologies
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Timeouts und Retry-Politik für nichtdeterministische Aktivitäten.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.temporal.io/activity-definition](https://docs.temporal.io/activity-definition)

^[S-176] Durable MCP weather server

• Autor/Herausgeber: Temporal Technologies
• Datum: 24.07.2026
• Dokumenttyp: Offizielles Referenzbeispiel
• Status: Beispiel, kein allgemeiner Standard
• Relevanz: Beispiel für die Kombination von MCP mit durable Workflows.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://docs.temporal.io/ai-cookbook/hello-world-durable-mcp-server](https://docs.temporal.io/ai-cookbook/hello-world-durable-mcp-server)

^[S-174] Failures and error handling

• Autor/Herausgeber: Temporal Technologies
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Trennung automatisch überstandener Infrastrukturfehler von fachlich zu behandelnden Fehlern.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.temporal.io/encyclopedia/failures-and-error-handling](https://docs.temporal.io/encyclopedia/failures-and-error-handling)

^[S-173] Understanding Temporal

• Autor/Herausgeber: Temporal Technologies
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Durable Execution, Event History und Replay für langlaufende Workflows.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.temporal.io/evaluate/understanding-temporal](https://docs.temporal.io/evaluate/understanding-temporal)

G. CRM-, ERP-, E-Mail- und SaaS-Integration

Integrationen: CRM

^[S-194] OAuth quickstart guide

• Autor/Herausgeber: HubSpot
• Datum: 29.03.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Anbieterbezogene OAuth-Einrichtung, Scopes und Tokenfluss.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.hubspot.com/docs/apps/legacy-apps/authentication/oauth-quickstart-guide](https://developers.hubspot.com/docs/apps/legacy-apps/authentication/oauth-quickstart-guide)

^[S-192] Webhooks API guide

• Autor/Herausgeber: HubSpot
• Datum: 03.2026; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Abonnements und Zustellung von HubSpot-Ereignissen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.hubspot.com/docs/api-reference/latest/webhooks/guide](https://developers.hubspot.com/docs/api-reference/latest/webhooks/guide)

^[S-193] Webhooks journal guide

• Autor/Herausgeber: HubSpot
• Datum: 09.06.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Journalbasierter Zugriff auf Webhook-Ereignisse und Nachholung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.hubspot.com/docs/api-reference/latest/webhooks-journal/guide](https://developers.hubspot.com/docs/api-reference/latest/webhooks-journal/guide)

^[S-191] Pub/Sub API — Overview

• Autor/Herausgeber: Salesforce
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Ereignisbasierte Salesforce-Integration über Pub/Sub.
• Refresh-Priorität: hoch
• Direkte URL: [https://developer.salesforce.com/docs/platform/pub-sub-api/overview](https://developer.salesforce.com/docs/platform/pub-sub-api/overview)

^[S-190] REST API Limits resource

• Autor/Herausgeber: Salesforce
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Abruf von Nutzung und API-Grenzen innerhalb einer Salesforce-Organisation.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_limits.htm](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_limits.htm)

^[S-189] Salesforce APIs

• Autor/Herausgeber: Salesforce
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Übersicht offizieller Salesforce-Schnittstellen.
• Refresh-Priorität: hoch
• Direkte URL: [https://developer.salesforce.com/docs/apis](https://developer.salesforce.com/docs/apis)

Integrationen: ERP

^[S-195] APIs in SAP Business Technology Platform

• Autor/Herausgeber: SAP
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: SAP-API-Landschaft und Einbindung über BTP.
• Refresh-Priorität: hoch
• Direkte URL: [https://help.sap.com/docs/btp/sap-business-technology-platform/apis](https://help.sap.com/docs/btp/sap-business-technology-platform/apis)

^[S-197] Advanced Event Mesh Adapter

• Autor/Herausgeber: SAP
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Ereignis- und Nachrichtenintegration mit SAP Advanced Event Mesh.
• Refresh-Priorität: hoch
• Direkte URL: [https://help.sap.com/docs/integration-suite/isuite-integrations-and-apis/advanced-event-mesh-adapter](https://help.sap.com/docs/integration-suite/isuite-integrations-and-apis/advanced-event-mesh-adapter)

^[S-196] Developing an OData API Project

• Autor/Herausgeber: SAP
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: OData-API-Projekte in SAP Integration Suite.
• Refresh-Priorität: hoch
• Direkte URL: [https://help.sap.com/docs/integration-suite/sap-integration-suite/developing-odata-api-project](https://help.sap.com/docs/integration-suite/sap-integration-suite/developing-odata-api-project)

Integrationen: Google

^[S-188] Configure push notifications in the Gmail API

• Autor/Herausgeber: Google
• Datum: 22.07.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Gmail-Änderungsbenachrichtigungen über Cloud Pub/Sub; Nutzdaten müssen anschließend abgerufen werden.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.google.com/workspace/gmail/api/guides/push](https://developers.google.com/workspace/gmail/api/guides/push)

Integrationen: Microsoft

^[S-184] Microsoft Graph REST API v1.0 reference

• Autor/Herausgeber: Microsoft
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Zentraler API-Zugang zu Microsoft-365-Daten und -Diensten.
• Refresh-Priorität: hoch
• Direkte URL: [https://learn.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0](https://learn.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0)

^[S-186] Microsoft Graph change notifications overview

• Autor/Herausgeber: Microsoft
• Datum: 05.03.2025
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Push-Benachrichtigungen für Änderungen in unterstützten Ressourcen.
• Refresh-Priorität: hoch
• Direkte URL: [https://learn.microsoft.com/en-us/graph/change-notifications-overview](https://learn.microsoft.com/en-us/graph/change-notifications-overview)

^[S-187] Microsoft Graph delta query overview

• Autor/Herausgeber: Microsoft
• Datum: 30.04.2025
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Inkrementeller Abgleich geänderter Ressourcen statt vollständiger Wiederabfrage.
• Refresh-Priorität: hoch
• Direkte URL: [https://learn.microsoft.com/en-us/graph/delta-query-overview](https://learn.microsoft.com/en-us/graph/delta-query-overview)

^[S-185] Receive change notifications through webhooks

• Autor/Herausgeber: Microsoft
• Datum: 21.04.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Webhook-Zustellung, Reaktionsanforderungen und mögliche Drosselung bzw. Verwerfung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://learn.microsoft.com/en-us/graph/change-notifications-delivery-webhooks](https://learn.microsoft.com/en-us/graph/change-notifications-delivery-webhooks)

H. Modelle, Tool Calling und Anbietermechanismen

Anbieter-Dokumentation

^[S-165] Build an agent with the tool runner

• Autor/Herausgeber: Anthropic
• Datum: 30.03.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Referenz für clientseitige Ausführung und Werkzeugschleifen.
• Refresh-Priorität: hoch
• Direkte URL: [https://platform.claude.com/docs/en/agents-and-tools/tool-use/build-a-tool-using-agent](https://platform.claude.com/docs/en/agents-and-tools/tool-use/build-a-tool-using-agent)

^[S-090] MCP connector and Claude Code MCP documentation

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Produktintegration von MCP.
• Refresh-Priorität: hoch
• Direkte URL: [https://platform.claude.com/docs/en/agents-and-tools/mcp-connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector)

^[S-164] Programmatic tool calling

• Autor/Herausgeber: Anthropic
• Datum: 20.01.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Programmatische Koordination von Werkzeugaufrufen.
• Refresh-Priorität: hoch
• Direkte URL: [https://platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling](https://platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling)

^[S-163] Structured outputs

• Autor/Herausgeber: Anthropic
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Schemaorientierte strukturierte Ausgaben in Claude.
• Refresh-Priorität: hoch
• Direkte URL: [https://platform.claude.com/docs/en/build-with-claude/structured-outputs](https://platform.claude.com/docs/en/build-with-claude/structured-outputs)

^[S-083] Tool use with Claude

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Aktueller Produktmechanismus für Werkzeugdefinition und -aufruf.
• Refresh-Priorität: hoch
• Direkte URL: [https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview)

^[S-084] Function calling with the Gemini API

• Autor/Herausgeber: Google
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Aktueller Produktmechanismus für Funktionsaufrufe.
• Refresh-Priorität: hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/function-calling](https://ai.google.dev/gemini-api/docs/function-calling)

^[S-167] Interactions API overview

• Autor/Herausgeber: Google
• Datum: 21.07.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: GA seit Juni 2026; empfohlen für neue Projekte
• Relevanz: Aktueller Interaktions- und Tooling-Pfad in der Gemini API.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/interactions-overview](https://ai.google.dev/gemini-api/docs/interactions-overview)

^[S-086] Structured outputs with the Gemini API

• Autor/Herausgeber: Google
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Schema-konforme strukturierte Modellausgaben.
• Refresh-Priorität: hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/structured-output](https://ai.google.dev/gemini-api/docs/structured-output)

^[S-166] Tools with the Gemini API

• Autor/Herausgeber: Google
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Werkzeugkategorien und produktbezogene Ausführung in Gemini.
• Refresh-Priorität: hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/tools](https://ai.google.dev/gemini-api/docs/tools)

^[S-161] Assistants API migration guide

• Autor/Herausgeber: OpenAI
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Assistants API deprecatet; Abschaltung 26.08.2026
• Relevanz: Zeitkritische Migration von einer unmittelbar vor Abschaltung stehenden API.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.openai.com/api/docs/assistants/migration](https://developers.openai.com/api/docs/assistants/migration)

^[S-159] Connectors and remote MCP servers

• Autor/Herausgeber: OpenAI
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Einbindung entfernter MCP-Server und Connectoren in die OpenAI API.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/tools-connectors-mcp](https://developers.openai.com/api/docs/guides/tools-connectors-mcp)

^[S-082] Function calling guide

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Aktueller Produktmechanismus für modellseitige Werkzeugaufrufe.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/function-calling](https://developers.openai.com/api/docs/guides/function-calling)

^[S-160] Migrate to the Responses API

• Autor/Herausgeber: OpenAI
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Aktueller API-Pfad für zustandsbezogene Interaktionen, Tools und Responses.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/migrate-to-responses](https://developers.openai.com/api/docs/guides/migrate-to-responses)

^[S-085] Structured Outputs guide

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Schema-konforme strukturierte Modellausgaben.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/structured-outputs](https://developers.openai.com/api/docs/guides/structured-outputs)

^[S-158] Using tools

• Autor/Herausgeber: OpenAI
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Werkzeugtypen und Steuerung in der OpenAI API.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/tools](https://developers.openai.com/api/docs/guides/tools)

^[S-162] Your data — API platform

• Autor/Herausgeber: OpenAI
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Datenbehandlung und Hinweis, dass entfernte MCP-Dienste eigene Aufbewahrungsbedingungen haben.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/your-data](https://developers.openai.com/api/docs/guides/your-data)

Caching und Kosten

^[S-096] Prompt caching

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Anbietermechanismus zur Wiederverwendung großer Prompt-Präfixe.
• Refresh-Priorität: hoch
• Direkte URL: [https://platform.claude.com/docs/en/build-with-claude/prompt-caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)

^[S-097] Context caching with the Gemini API

• Autor/Herausgeber: Google
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Anbietermechanismus zur Speicherung und Wiederverwendung von Kontext.
• Refresh-Priorität: hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/caching](https://ai.google.dev/gemini-api/docs/caching)

^[S-095] Prompt caching guide

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Anbietermechanismus zur Wiederverwendung von Prompt-Präfixen.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/prompt-caching](https://developers.openai.com/api/docs/guides/prompt-caching)

KI-Evaluation

^[S-029] Define success criteria and build evaluations

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Erfolgskriterien, Testfälle und Evaluation für LLM-Anwendungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://platform.claude.com/docs/en/test-and-evaluate/develop-tests](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)

^[S-028] Evaluation best practices

• Autor/Herausgeber: OpenAI
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Aktueller Leitfaden; Evals-Plattform mit angekündigter Abschaltung zum 30.11.2026
• Relevanz: Herstellerpraxis für aufgabenspezifische Datensätze, Evaluatoren, menschliche Kalibrierung und kontinuierliche Evaluation.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/evaluation-best-practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices)

KI-Observability

^[S-059] GenAI semantic conventions

• Autor/Herausgeber: OpenTelemetry
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Spezifikation
• Status: Teilweise experimentell; Living Specification
• Relevanz: Semantische Konventionen für Modellaufrufe, Agenten und GenAI-Ereignisse.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/specs/semconv/gen-ai/](https://opentelemetry.io/docs/specs/semconv/gen-ai/)

I. Sicherheit und Secure Development

API-Sicherheit

^[S-027] OWASP API Security Top 10 — 2023

• Autor/Herausgeber: OWASP
• Datum: 2023
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Risikokategorien für APIs, einschließlich Autorisierung und Ressourcenverbrauch.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/API-Security/editions/2023/en/0x11-t10/](https://owasp.org/API-Security/editions/2023/en/0x11-t10/)

Anwendungssicherheit

^[S-032] Authorization Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Security-Leitlinie
• Status: Living Documentation
• Relevanz: Serverseitige Autorisierung und Least Privilege.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)

Cybersecurity-Governance

^[S-014] ISO/IEC 27001:2022 — Information security management systems — Requirements

• Autor/Herausgeber: ISO / IEC
• Datum: 2022
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Anforderungen an ein Informationssicherheits-Managementsystem.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/27001](https://www.iso.org/standard/27001)

^[S-009] The NIST Cybersecurity Framework (CSF) 2.0

• Autor/Herausgeber: NIST
• Datum: 26.02.2024
• Dokumenttyp: Behördenrahmenwerk
• Status: Final
• Relevanz: Govern, Identify, Protect, Detect, Respond und Recover als Cyber-Risikofunktionen.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)

KI-Sicherheit

^[S-034] MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems

• Autor/Herausgeber: MITRE
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offene Wissensbasis
• Status: Living Knowledge Base
• Relevanz: Taktiken und Techniken gegen KI-fähige Systeme.
• Refresh-Priorität: hoch
• Direkte URL: [https://atlas.mitre.org/](https://atlas.mitre.org/)

^[S-093] NIST AI 100-2e2025: Adversarial Machine Learning - A Taxonomy and Terminology of Attacks and Mitigations

• Autor/Herausgeber: NIST
• Datum: 03.2025
• Dokumenttyp: Behördenstandard / Taxonomie
• Status: Final Publication
• Relevanz: Angriffe einschließlich Prompt Injection, Daten- und Modellangriffen.
• Refresh-Priorität: hoch
• Direkte URL: [https://doi.org/10.6028/NIST.AI.100-2e2025](https://doi.org/10.6028/NIST.AI.100-2e2025)

^[S-092] NIST AI 600-1: Artificial Intelligence Risk Management Framework - Generative Artificial Intelligence Profile

• Autor/Herausgeber: NIST
• Datum: 26.07.2024
• Dokumenttyp: Behördenstandard / Risikoprofil
• Status: Final Publication
• Relevanz: Risiken und Maßnahmen für generative KI.
• Refresh-Priorität: mittel
• Direkte URL: [https://doi.org/10.6028/NIST.AI.600-1](https://doi.org/10.6028/NIST.AI.600-1)

^[S-094] Request for Information About Securing AI Agent Systems

• Autor/Herausgeber: NIST / CAISI
• Datum: 01.2026
• Dokumenttyp: Behördenveröffentlichung
• Status: RFI / laufende Standardisierungsarbeit
• Relevanz: Aktuelle Sicherheitsfragen agentischer Systeme.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems](https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems)

^[S-033] OWASP GenAI LLM Top 10 2026

• Autor/Herausgeber: OWASP GenAI Security Project
• Datum: 03.08.2026
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Aktuelle Risikokategorien für generative KI-Anwendungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/)

Observability und Security

^[S-031] Logging Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Security-Leitlinie
• Status: Living Documentation
• Relevanz: Sicherheitsrelevante Protokollierung ohne unnötige Geheimnis- oder Personendaten.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)

Secure AI Development

^[S-008] SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models

• Autor/Herausgeber: NIST
• Datum: 26.07.2024
• Dokumenttyp: Behördenstandard / Community Profile
• Status: Final
• Relevanz: Ergänzt SSDF 1.1 um Praktiken für KI-Modelle und KI-Systeme.
• Refresh-Priorität: hoch
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/218/a/final](https://csrc.nist.gov/pubs/sp/800/218/a/final)

Secure SDLC

^[S-041] Product Security Bad Practices

• Autor/Herausgeber: CISA
• Datum: 17.01.2025
• Dokumenttyp: Behördenleitlinie
• Status: Final
• Relevanz: Klar benannte Praktiken, die bei kritischer Software vermieden werden sollen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.cisa.gov/resources-tools/resources/product-security-bad-practices](https://www.cisa.gov/resources-tools/resources/product-security-bad-practices)

^[S-040] Secure by Design

• Autor/Herausgeber: CISA
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Behördenleitlinie
• Status: Living Guidance
• Relevanz: Herstellerverantwortung und sichere Standardeinstellungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.cisa.gov/resources-tools/resources/secure-by-design](https://www.cisa.gov/resources-tools/resources/secure-by-design)

^[S-007] SP 800-218 — Secure Software Development Framework (SSDF) Version 1.1

• Autor/Herausgeber: NIST
• Datum: 03.02.2022
• Dokumenttyp: Behördenstandard
• Status: Final
• Relevanz: Sicherheitspraktiken, die in unterschiedliche SDLC-Modelle integriert werden können.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/218/final](https://csrc.nist.gov/pubs/sp/800/218/final)

Security Testing

^[S-011] SP 800-115 — Technical Guide to Information Security Testing and Assessment

• Autor/Herausgeber: NIST
• Datum: 09.2008
• Dokumenttyp: Behördenleitfaden
• Status: Final; methodische Grundlage
• Relevanz: Planung und Durchführung technischer Sicherheitsprüfungen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/115/final](https://csrc.nist.gov/pubs/sp/800/115/final)

^[S-026] Application Security Verification Standard 5.0.0

• Autor/Herausgeber: OWASP
• Datum: 30.05.2025
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Hauptversion
• Relevanz: Prüfbare Sicherheitsanforderungen für Webanwendungen und Services.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/www-project-application-security-verification-standard/](https://owasp.org/www-project-application-security-verification-standard/)

Vulnerability Management

^[S-063] Known Exploited Vulnerabilities Catalog

• Autor/Herausgeber: CISA
• Datum: Living Catalog; geprüft 08.08.2026
• Dokumenttyp: Behördenkatalog
• Status: Kontinuierlich aktualisiert
• Relevanz: Priorisierung tatsächlich ausgenutzter Schwachstellen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.cisa.gov/known-exploited-vulnerabilities-catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)

Websicherheit: APIs

^[S-038] GraphQL Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Risiken von Introspection, Query-Tiefe, Autorisierung und Ressourcenverbrauch.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html)

^[S-037] REST Security Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Authentisierung, Autorisierung, Eingaben, Statuscodes und Transport für REST APIs.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html)

Websicherheit: Eingaben

^[S-035] Input Validation Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Serverseitige Syntax- und Semantikvalidierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)

Websicherheit: Integrationen

^[S-076] Validating webhook deliveries

• Autor/Herausgeber: GitHub
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Signaturprüfung eingehender Webhooks.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries](https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries)

Websicherheit: SSRF

^[S-036] Server-Side Request Forgery Prevention Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Kontrollen gegen serverseitige unautorisierte Netzwerkzugriffe.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)

J. Vorfälle und Post-Mortems

Fälle: Integrationen

^[S-202] Security alert: stolen OAuth user tokens

• Autor/Herausgeber: GitHub
• Datum: 15.04.2022
• Dokumenttyp: Offizieller Incidentbericht
• Status: Historischer Vorfall
• Relevanz: Gestohlene OAuth-Tokens von Integrationsanbietern wurden zum Zugriff auf private Repositories genutzt.
• Refresh-Priorität: niedrig
• Direkte URL: [https://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/](https://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/)

^[S-203] npm security update: OAuth tokens

• Autor/Herausgeber: GitHub
• Datum: 26.05.2022
• Dokumenttyp: Offizieller Incidentbericht
• Status: Historischer Vorfall
• Relevanz: Kettenwirkung gestohlener OAuth-Tokens bis zu Repository- und Cloud-Credentials.
• Refresh-Priorität: niedrig
• Direkte URL: [https://github.blog/news-insights/company-news/npm-security-update-oauth-tokens/](https://github.blog/news-insights/company-news/npm-security-update-oauth-tokens/)

^[S-206] Data Extortion via Salesforce Connected Apps

• Autor/Herausgeber: Google Threat Intelligence Group
• Datum: 04.06.2025
• Dokumenttyp: Primäre Threat-Intelligence-Analyse
• Status: Dokumentierte Angriffskampagne
• Relevanz: Vishing und bösartige Connected Apps als Integrations- und Autorisierungsrisiko.
• Refresh-Priorität: hoch
• Direkte URL: [https://cloud.google.com/blog/topics/threat-intelligence/voice-phishing-data-extortion](https://cloud.google.com/blog/topics/threat-intelligence/voice-phishing-data-extortion)

^[S-207] Data theft via compromised Salesloft Drift OAuth tokens

• Autor/Herausgeber: Google Threat Intelligence Group
• Datum: 26.08.2025
• Dokumenttyp: Primäre Threat-Intelligence-Analyse
• Status: Dokumentierte Kampagne
• Relevanz: Kompromittierte Drittanbieter-OAuth-Tokens ermöglichten Zugriff auf angebundene Salesforce-Instanzen.
• Refresh-Priorität: hoch
• Direkte URL: [https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift](https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift)

Incident Response

^[S-052] Incident Response

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Incident Command, Kommunikation, Mitigation und Übungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/incident-response/](https://sre.google/workbook/incident-response/)

^[S-010] SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management

• Autor/Herausgeber: NIST
• Datum: 03.04.2025
• Dokumenttyp: Behördenstandard / Community Profile
• Status: Final
• Relevanz: Incident Response als Teil des laufenden Cyber-Risikomanagements.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/61/r3/final](https://csrc.nist.gov/pubs/sp/800/61/r3/final)

Post-Mortems

^[S-080] Post-incident review: April 2022 outage

• Autor/Herausgeber: Atlassian Engineering
• Datum: 04.05.2022
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Fehlerhafte Skriptausführung, Löschung von Kundensites und langwierige Wiederherstellung.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.atlassian.com/engineering/post-incident-review-april-2022-outage](https://www.atlassian.com/engineering/post-incident-review-april-2022-outage)

^[S-079] Details of the Cloudflare outage on July 2, 2019

• Autor/Herausgeber: Cloudflare
• Datum: 02.07.2019
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Katastrophales Regex-Backtracking, globale Schnellverteilung und fehlender Performance-Gate.
• Refresh-Priorität: niedrig
• Direkte URL: [https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/](https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/)

^[S-081] Executive Summary: Root Cause Analysis — Channel File 291

• Autor/Herausgeber: CrowdStrike
• Datum: 06.08.2024
• Dokumenttyp: Unternehmens-Root-Cause-Analyse
• Status: Primärbericht des Herstellers
• Relevanz: Fehlerhafte Content-Konfiguration, unzureichende Validierung und weltweite Ausrollung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.crowdstrike.com/wp-content/uploads/2024/08/Executive-Summary_Root-Cause-Analysis_Channel-File-291.pdf](https://www.crowdstrike.com/wp-content/uploads/2024/08/Executive-Summary_Root-Cause-Analysis_Channel-File-291.pdf)

^[S-078] Postmortem of database outage of January 31

• Autor/Herausgeber: GitLab
• Datum: 10.02.2017
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Datenlöschung, unzureichend funktionsfähige Backups und Wiederherstellungsprobleme.
• Refresh-Priorität: niedrig
• Direkte URL: [https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)

K. Zuverlässigkeit, Observability und Betrieb

Backup und Notfallbetrieb

^[S-013] BSI-Standard 200-4 — Business Continuity Management

• Autor/Herausgeber: Bundesamt für Sicherheit in der Informationstechnik
• Datum: 14.06.2023
• Dokumenttyp: Behördenstandard
• Status: Final
• Relevanz: Praxisrahmen zum Aufbau eines BCMS.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_4.html](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_4.html)

^[S-012] SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems

• Autor/Herausgeber: NIST
• Datum: 11.11.2010
• Dokumenttyp: Behördenleitfaden
• Status: Final; älter, aber weiterhin referenziert
• Relevanz: Business Impact Analysis, Wiederanlauf, Übungen und Pflege von Notfallplänen.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)

Backup und Restore

^[S-061] Continuous Archiving and Point-in-Time Recovery

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: WAL-Archivierung und Wiederherstellung auf einen früheren Zeitpunkt.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/continuous-archiving.html](https://www.postgresql.org/docs/current/continuous-archiving.html)

^[S-060] PostgreSQL 18 Documentation — Backup and Restore

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: SQL-Dumps, Dateisystem-Backups und kontinuierliche Archivierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/backup.html](https://www.postgresql.org/docs/current/backup.html)

^[S-062] SQL Dump

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Logische Exporte und Wiederherstellung, auch über Versionsgrenzen hinweg.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/backup-dump.html](https://www.postgresql.org/docs/current/backup-dump.html)

Betrieb und Wartung

^[S-053] Eliminating Toil

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Reduktion manueller, wiederholbarer Betriebsarbeit.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/eliminating-toil/](https://sre.google/workbook/eliminating-toil/)

CI und Qualitätsgates

^[S-016] About status checks

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Automatisierte Prüfergebnisse als Merge-Bedingung.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/pull-requests/reference/status-checks](https://docs.github.com/en/pull-requests/reference/status-checks)

CI/CD-Sicherheit

^[S-019] OpenID Connect in GitHub Actions

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Kurzlebige föderierte Cloud-Anmeldung statt dauerhaft gespeicherter Zugangsschlüssel.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/actions/concepts/security/openid-connect](https://docs.github.com/en/actions/concepts/security/openid-connect)

^[S-017] Secure use reference — GitHub Actions

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Sicherheitskontrollen für CI/CD-Workflows und Umgebungsfreigaben.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/actions/reference/security/secure-use](https://docs.github.com/en/actions/reference/security/secure-use)

Deployment

^[S-018] Managing environments for deployment

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Deployment-Schutzregeln und getrennte Umgebungssecrets.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/actions/deployment/targeting-different-environments/using-environments-for-deployment](https://docs.github.com/actions/deployment/targeting-different-environments/using-environments-for-deployment)

Observability

^[S-058] Context propagation

• Autor/Herausgeber: OpenTelemetry
• Datum: 14.01.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Korrelation verteilter Telemetriesignale über Prozess- und Netzgrenzen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/context-propagation/](https://opentelemetry.io/docs/concepts/context-propagation/)

^[S-057] Logs

• Autor/Herausgeber: OpenTelemetry
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Log-API, Bridges und Korrelation mit Traces.
• Refresh-Priorität: hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/logs/](https://opentelemetry.io/docs/concepts/signals/logs/)

^[S-056] Metrics

• Autor/Herausgeber: OpenTelemetry
• Datum: 02.07.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Laufzeitmessungen und zugeordnete Metadaten.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/metrics/](https://opentelemetry.io/docs/concepts/signals/metrics/)

^[S-054] Signals

• Autor/Herausgeber: OpenTelemetry
• Datum: 10.03.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Traces, Metrics, Logs, Baggage und Profiles als Telemetriesignale.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/](https://opentelemetry.io/docs/concepts/signals/)

^[S-055] Traces

• Autor/Herausgeber: OpenTelemetry
• Datum: 14.01.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: End-to-End-Sicht auf verteilte Requests.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/traces/](https://opentelemetry.io/docs/concepts/signals/traces/)

Recht und Produktbetrieb

^[S-042] Verordnung (EU) 2024/2847 — Cyber Resilience Act

• Autor/Herausgeber: Europäische Union
• Datum: 23.10.2024; ABl. 20.11.2024
• Dokumenttyp: EU-Verordnung
• Status: In Kraft; gestaffelte Anwendung
• Relevanz: Horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)

Reliability

^[S-044] Making retries safe with idempotent APIs

• Autor/Herausgeber: Amazon Web Services
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizieller Engineering-Fachbeitrag
• Status: Living Documentation
• Relevanz: Idempotenzschlüssel und sichere Wiederholbarkeit zustandsändernder Operationen.
• Refresh-Priorität: hoch
• Direkte URL: [https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

^[S-043] Timeouts, retries, and backoff with jitter

• Autor/Herausgeber: Amazon Web Services
• Datum: 12.06.2026
• Dokumenttyp: Offizieller Engineering-Fachbeitrag
• Status: Aktualisierte Fassung
• Relevanz: Timeouts, begrenzte Wiederholungen, Backoff, Jitter und Retry-Amplifikation.
• Refresh-Priorität: hoch
• Direkte URL: [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)

^[S-045] Idempotent requests

• Autor/Herausgeber: Stripe
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Konkrete API-Praxis für Idempotenzschlüssel.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.stripe.com/api/idempotent_requests](https://docs.stripe.com/api/idempotent_requests)

Site Reliability Engineering

^[S-050] Alerting on SLOs

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Burn-Rate-basierte Alarmierung statt rein technischer Schwellenwerte.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/alerting-on-slos/](https://sre.google/workbook/alerting-on-slos/)

^[S-048] Canarying Releases

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Risikoreduktion durch schrittweise Releases und SLO-basierte Bewertung.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/canarying-releases/](https://sre.google/workbook/canarying-releases/)

^[S-049] Implementing SLOs

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Definition, Messung und Nutzung von Service Level Objectives.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/implementing-slos/](https://sre.google/workbook/implementing-slos/)

^[S-051] On-Call

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Betriebsbereitschaft, Eskalation und Balance zwischen Änderung und Stabilität.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/on-call/](https://sre.google/workbook/on-call/)

^[S-047] SRE Engagement Model / Production Readiness Review

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Produktionsreife, Übergabe und gemeinsame Betriebsverantwortung.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/engagement-model/](https://sre.google/workbook/engagement-model/)

^[S-046] The Site Reliability Workbook

• Autor/Herausgeber: Google
• Datum: 2018
• Dokumenttyp: Offizielles Fachbuch
• Status: Online-Ausgabe
• Relevanz: Praxisrahmen für SLOs, Releases, On-Call, Incident Response und Zuverlässigkeitsarbeit.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/index/](https://sre.google/workbook/index/)

Software-Lieferkette

^[S-020] Using artifact attestations to establish provenance for builds

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Provenienz- und Attestierungsfunktionen für Build-Artefakte.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds)

Wartung und Abhängigkeiten

^[S-064] Dependabot security updates

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Automatisierte Vorschläge für verwundbare Abhängigkeiten.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates](https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)

^[S-065] Renovate Documentation

• Autor/Herausgeber: Mend Renovate
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Automatisierte, konfigurierbare Abhängigkeitsaktualisierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.renovatebot.com/](https://docs.renovatebot.com/)

L. Software Engineering, Anforderungen und Dokumentation

Anforderungen

^[S-002] ISO/IEC/IEEE 29148:2018 — Requirements engineering

• Autor/Herausgeber: ISO / IEC / IEEE
• Datum: 2018; Nachfolgedokument in Entwicklung, geprüft 08.08.2026
• Dokumenttyp: Internationaler Standard
• Status: Gültige Ausgabe am Stichtag
• Relevanz: Anforderungen, deren Eigenschaften und Requirements-Prozesse.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.iso.org/standard/72089.html](https://www.iso.org/standard/72089.html)

Dokumentation

^[S-004] ISO/IEC/IEEE 26514:2022 — Design and development of information for users

• Autor/Herausgeber: ISO / IEC / IEEE
• Datum: 2022
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Nutzerdokumentation als geplanter Bestandteil eines Produkts.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/77451.html](https://www.iso.org/standard/77451.html)

Governance und Risiko

^[S-003] ISO/IEC/IEEE 16085:2021 — Life cycle processes — Risk management

• Autor/Herausgeber: ISO / IEC / IEEE
• Datum: 2021
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Risikomanagement über den System- und Softwarelebenszyklus.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/74371.html](https://www.iso.org/standard/74371.html)

Lebenszyklus und Qualität

^[S-005] Guide to the Software Engineering Body of Knowledge — SWEBOK Guide V4.0

• Autor/Herausgeber: IEEE Computer Society
• Datum: 10.2024
• Dokumenttyp: Fachstandard / Body of Knowledge
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Systematische Wissensgebiete professioneller Softwareentwicklung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.computer.org/education/bodies-of-knowledge/software-engineering](https://www.computer.org/education/bodies-of-knowledge/software-engineering)

^[S-001] ISO/IEC 25010:2023 — Product quality model

• Autor/Herausgeber: ISO / IEC
• Datum: 2023
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Produktqualitätsmodell mit neun Qualitätsmerkmalen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/78176.html](https://www.iso.org/standard/78176.html)

Versionierung

^[S-006] Semantic Versioning 2.0.0

• Autor/Herausgeber: Semantic Versioning
• Datum: 2013
• Dokumenttyp: Offene Spezifikation
• Status: Version 2.0.0
• Relevanz: Maschinen- und menschenlesbare Regeln für kompatible und inkompatible Versionsänderungen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://semver.org/](https://semver.org/)

Versionsverwaltung und Review

^[S-015] About protected branches

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Schutzregeln, Reviews und Statusprüfungen für zentrale Branches.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)

Schnell veraltend — Refresh-Plan

REFRESH-HINWEIS: Vor Buchsatz, Veröffentlichung und jeder größeren Folgeauflage sind insbesondere MCP- und A2A-Spezifikationen, OAuth-Entwürfe, Modellanbieter-APIs, SaaS-Limits, Integrations-Lifecycles, Security Advisories, AI-Act-/CRA-Umsetzung und Drittlandtransferstände erneut zu prüfen. ^{[S-117; S-210; S-140; S-161; S-190; S-063; S-067; S-042; S-070]}

Empfohlene Prüffrequenz

Qualitätssicherung, Grenzen und Schlussbefund

Strukturprüfungen

Inhaltliche Grenzen

• Das Dossier ersetzt keine individuelle Rechts-, Datenschutz-, Vertrags-, Vergabe-, Steuer- oder IT-Sicherheitsberatung.
• OAuth 2.1 war am 8. August 2026 ein Internet-Draft; seine spätere RFC-Fassung kann abweichen. ^[S-140]
• MCP- und A2A-Spezifikationen sind nicht identisch mit der tatsächlichen Unterstützung eines konkreten Hosts, Servers oder SDKs. ^{[S-117; S-210]}
• Anbieter-APIs, Preise, Limits, Scopes, Retention und Datenverwendung können tenant-, region-, tarif- und zeitabhängig sein. ^{[S-190; S-162]}
• „Genau einmal“, „Echtzeit“ und „vollständig synchron“ sind nur innerhalb präzise definierter Systemgrenzen belastbar. ^{[S-171; S-044]}
• Ein dokumentierter Sicherheitsfall belegt eine konkrete Fehlerklasse, nicht automatisch dieselbe Verwundbarkeit jeder anderen Implementierung. ^{[S-010; S-003]}
• Die konkrete Zulässigkeit personenbezogener oder geschäftskritischer Daten bleibt von Zweck, Rolle, Vertrag, Zugriff, Transfer und Aufbewahrung abhängig. ^{[S-066; S-068; S-069]}

Schlussbefund

Schlussbefund: Vernetzte KI wird nicht dadurch professionell, dass möglichst viele Systeme, Agenten und Tools miteinander sprechen. Professionell wird sie, wenn jede Verbindung eine klare fachliche Grenze, minimale Identität und Berechtigung, einen prüfbaren Datenvertrag, begrenzte KI-Autorität, sichere Seiteneffekte, nachweisbare Qualität und einen geübten Fehler- und Exitpfad besitzt. ^{[S-002; S-074; S-107; S-044; S-049; S-004]}

REDAKTIONELLE SYNTHESE: Für die Buchreihe ist deshalb die belastbare Botschaft: APIs, MCP und Agentenprotokolle erweitern die möglichen Automatisierungen erheblich. Sie beseitigen jedoch weder klassische Softwarearchitektur noch Datenverantwortung, Security, Betrieb und menschliche Entscheidungskompetenz. In vielen Vorgängen ist die beste KI-Integration eine kleine KI-Komponente in einem überwiegend deterministischen, beobachtbaren Prozess. ^{[S-021; S-100; S-213; S-008; S-046]}