Permission-aware und data-residency-aware: den Zugriff von KI-Agenten auf Ihre EA regeln

Zwei Kontrolldimensionen, nicht eine

Wenn ein KI-Agent Ihre Enterprise Architecture liest, gibt es zwei verschiedene Fragen zu beantworten, und sie sind leicht zu vermengen. Die erste ist eine Frage der Berechtigung: von allem im Repository, was darf dieser bestimmte Nutzer sehen? Die zweite ist eine Frage der Geografie und Verwahrung: woher auch immer die Antwort kommt, wohin dürfen diese Daten physisch gehen?

Der größte Teil des Marktgesprächs dreht sich um die erste Dimension. Sie ist die einfachere, über die man nachdenken kann, weil sie sich auf Zugriffskontrolle abbilden lässt, die wir bereits verstehen. Die zweite Dimension ist die, die die regulierte Finanzwelt nicht überspringen kann — und die, die etablierte Anbieter tendenziell unterversorgen. Beide richtig zu machen, ist das, was eine Demo von etwas trennt, das ein CISO oder ein CSSF-gewandtes Team tatsächlich abzeichnen wird.

Permission-aware: nur was der anfragende Nutzer sehen darf

Permission-aware Zugriff bedeutet, dass der Agent nur zurückgibt, was der anfragende Nutzer sehen darf, begrenzt nach Rolle, nach Objekt und nach Sensibilität. Der Agent handelt im Auftrag einer Person; die Identität und Berechtigungen dieser Person müssen sich bis zur Antwort durchpropagieren. Ein Architekt im Zahlungsverkehr sollte nicht über einen Chatbot Objekte zutage fördern, die er in der Anwendung selbst nie öffnen könnte.

Das ist eine echte und wichtige Kontrolle, und es ist fair, denen Anerkennung zu zollen, die sie hervorheben. Ardoq etwa betont permission-aware Zugriff, damit der Agent die bestehenden Berechtigungen jedes Nutzers respektiert. Wir stimmen zu, dass es notwendig ist. Unser Argument ist nicht, dass permission-aware falsch wäre — es ist, dass es für sich allein für einen regulierten Kontext unvollständig ist.

• Begrenzung nach Rolle: der Agent erbt die Berechtigungen des anfragenden Nutzers, nie eine Obermenge
• Begrenzung nach Objekt: Zugriff pro Objekt, nicht Alles-oder-nichts-Zugriff auf das Repository
• Begrenzung nach Sensibilität: Objekte klassifizieren, sodass kritische anders behandelt werden
• Identität propagieren: der Nutzer hinter dem Agenten ist, wen das Tor bewertet

Warum permission-aware allein für die regulierte Finanzwelt unzureichend ist

Stellen Sie sich eine perfekt permission-korrekte Antwort vor. Der Nutzer ist zu jedem Objekt darin berechtigt; nichts ist über eine Berechtigungsgrenze hinweg durchgesickert. Stellen Sie nun die zweite Frage: ist, um diese Antwort zu erzeugen, der Prompt — Ihre Abhängigkeitskarte, Ihr Inventar kritischer Funktionen — zu einem US-gehosteten Modell gereist? Wenn ja, können Sie vollständig permission-aware sein und trotzdem eine DORA-, CSSF- oder DSGVO-Exposition geschaffen haben, denn das Problem war nie, wer gefragt hat. Es war, wohin die Daten gingen.

Eine EA-Karte kommt einem vollständigen Bauplan der Organisation nahe: Systeminventar, kritische Abhängigkeiten, veraltete Komponenten, bekannte Schwachstellen, sensible Datenflüsse. Zu begrenzen, wer sie lesen kann, ändert nichts daran, dass, sobald eine Antwort berechnet ist, der zugrunde liegende Kontext Ihre Jurisdiktion verlassen haben kann. Permission-Kontrolle regelt Sichtbarkeit; sie regelt nicht Residenz. Diese Lücke ist die fehlende Dimension.

Ein praktisches Kontrollmodell: von der Klassifizierung zur Protokollierung

Ein funktionierendes Modell setzt zwei Tore in Reihe zwischen den Agenten und das Repository und protokolliert über beide. Beginnen Sie mit Klassifizierung, dann Default-Deny der gefährlichsten Objekte, dann Egress-Kontrolle. Die Reihenfolge zählt: entscheiden Sie, was gesehen werden darf, bevor Sie entscheiden, wohin es gehen darf, und zeichnen Sie beide Entscheidungen auf.

Default-Deny bei Objekten kritischer Funktionen ist die bewusst konservative Haltung. Für die Systeme, die eine kritische oder wichtige Funktion stützen, ist die sichere Voreinstellung, zurückzuhalten, es sei denn, eine Anfrage ist ausdrücklich erlaubt — das Gegenteil einer permissiven Karte, in der alles erreichbar ist, bis es eingeschränkt wird. Redaction behandelt die Posten, die überhaupt nie hinausgehen sollten: bekannte Schwachstellen, Sicherheitsmaßnahmen und ähnliches Material, das in einem externen Prompt nichts zu suchen hat, selbst für einen berechtigten Nutzer.

• Jedes Objekt nach Sensibilität klassifizieren, kritische-Funktions-Systeme markieren
• Default-Deny bei Objekten kritischer Funktionen: zurückhalten, sofern nicht ausdrücklich erlaubt
• Posten redigieren, die nie hinausgehen dürfen (bekannte Schwachstellen, Sicherheitsmaßnahmen)
• Egress-Kontrolle anwenden, bevor irgendein Prompt oder eine Antwort eine Grenze überschreitet
• Protokollieren, wer was gefragt hat, was zurückgegeben wurde und wohin es ging

Data-residency-aware: regeln, wohin die Daten gehen

Das Residenz-Tor regelt die Geografie und Verwahrung jedes Prompts, jeder Antwort und jedes Embeddings. Die praktischen Hebel sind Deployment-Entscheidungen: ein EU-gehostetes Modell, ein On-Premise-Deployment unter Ihrer eigenen Kontrolle oder ein europäisches LLM, bei dem die Inferenz selbst in der Jurisdiktion bleibt. Embeddings verdienen ausdrückliche Aufmerksamkeit — Ihre Architektur zu vektorisieren kann still ein Derivat sensiblen Inhalts an einem Ort persistieren, den Sie nicht beabsichtigt hatten.

Konkret ist in der EU-regulierten Finanzwelt die Frage, die ein CISO stellt, selten allein „kann der Agent das sehen?“; sie lautet „wenn er das sieht, wo findet die Berechnung statt und wo ruhen die Artefakte?“. Eine residency-aware Schicht macht diese Antwort zu einer konfigurierten, auditierbaren Eigenschaft statt zu einem Zufall dessen, welches Modell am billigsten aufzurufen war. Das ist der Teil des Bildes, den die meisten Plattformen heute dem Kunden überlassen.

• EU-gehostete Inferenz, On-Premise-Deployment oder eine Option für ein europäisches LLM
• Egress-Kontrolle auf Prompts und Antworten, nicht nur auf gespeicherte Daten
• Embeddings als residenztragend behandeln: sie persistieren ein Derivat des Inhalts
• Residenz zu einer konfigurierten, auditierbaren Eigenschaft machen, nicht zu einer impliziten Voreinstellung

Der data-residency-aware MCP: wohin wir gehen

Verbinden Sie die beiden Tore und Sie erhalten, was wir einen data-residency-aware MCP nennen: eine Context-Schicht, die nicht nur regelt, wer die Architektur abfragt, sondern wohin die Daten physisch gehen, wenn er es tut. Um in puncto Claim-Disziplin klar zu sein: das ist unsere Überzeugung und unsere Roadmap, der Ansatz, auf den wir hinarbeiten — kein ausgeliefertes Produkt. Wir werden nicht schreiben, dass es existiert, wenn es das nicht tut.

Wofür wir heute einstehen können, ist das Fundament, das er braucht: EU-Region- oder On-Premise-Hosting unter Ihrer Kontrolle, natives Französisch und Englisch, ein vernetztes EA-Modell, das um DORA/CSSF-Dokumentationsbedarf herum gebaut ist, und ein kostenloses EA-Reifegrad-Assessment, um zu sehen, wo Ihre Praxis steht. Und ein ehrlicher Vorbehalt durchgängig: dieses Kontrollmodell ist eine Dokumentations- und Risiko-Framing-Hilfe, keine rechtliche Konformität. Es hilft Ihnen, einem Auditor zu zeigen, wie der KI-Zugriff auf Ihre Architektur geregelt ist; das Konformitätsurteil bleibt Ihnen überlassen.