Context Layer: KI-Agenten sicher an Firmendaten

Stell dir vor, ein KI-Agent soll im Team die Frage beantworten "Welche Kunden sind im letzten Quartal abgesprungen und warum?". Dafür braucht er Zugriff auf eure Datenbank, das CRM, vielleicht die Support-Tickets. Die Versuchung ist groß, ihm einfach einen Service-Account mit breiten Rechten zu geben, damit er an alles kommt. Genau das ist das Problem: Was der Agent kann, kann dann auch jeder, der den Agenten kapert. Und niemand kann hinterher sagen, worauf er eigentlich zugegriffen hat.

Innerhalb von drei Wochen im Juni 2026 haben vier der größten Datenplattformen unabhängig voneinander dieselbe Antwort auf dieses Problem vorgestellt. AWS, Microsoft, Snowflake und Databricks bauen alle eine neue Schicht zwischen Agent und Firmendaten. In der Branche heißt sie inzwischen "Context Layer". Der jüngste Einstieg kam vom AWS Summit in New York Mitte Juni. Das ist ein guter Anlass, sich anzuschauen, was da eigentlich passiert, denn das Prinzip dahinter betrifft jedes Team, das Agenten an echte Daten lässt, egal auf welcher Plattform.

Das Problem: Agenten sind kontextblind und ohne Governance gefährlich

Ein Sprachmodell weiß nicht, was eure Tabelle cust_q4_v2 bedeutet, ob "Umsatz" netto oder brutto ist und welche zwei Tabellen man joinen muss, um eine Kundenhistorie zu bekommen. Es rät. Das ist die eine Hälfte des Problems: fehlender Geschäftskontext.

Die andere Hälfte ist Sicherheit. Ein Agent, der handeln kann, ist ein Angriffsziel. Eine manipulierte E-Mail oder ein präpariertes Dokument kann ihn umlenken, und dann nutzt er seine legitimen Zugriffsrechte gegen euch. Diese Risiken sind kein Randthema mehr, die OWASP Top 10 für Agentic AI listen sie mit realen CVEs auf. Je mehr ein Agent darf, desto größer der Schaden, wenn er gekapert wird.

Die Plattformanbieter haben verstanden, dass sich beide Probleme nur zusammen lösen lassen. Ein Agent soll genug verstehen, um nützlich zu sein, aber nur so viel sehen dürfen, wie die Person dahinter ohnehin sehen darf. Und alles, was er tut, muss nachvollziehbar bleiben.

Die gemeinsame Antwort: zwei Schichten in einer

Der Context Layer kombiniert zwei Dinge, die vorher getrennt waren:

flowchart TB
  A["KI-Agent"] --> B{"Context Layer"}
  B --> C["Wissensschicht<br/>Was bedeuten die Daten?"]
  B --> D["Zugriffsschicht<br/>Was darf dieser Agent sehen?"]
  C --> E["Semantik, Knowledge Graph,<br/>Ontologie"]
  D --> F["Identität, Policies,<br/>Audit-Log"]
  F --> G["Nur erlaubte Daten,<br/>jeder Zugriff protokolliert"]
  class B decision
  class G success

Die Wissensschicht gibt dem Agenten Bedeutung. Statt roher Tabellen bekommt er ein Modell der Geschäftsbegriffe, der Beziehungen und der richtigen Wege durch die Daten. Die Zugriffsschicht sorgt dafür, dass der Agent nur sieht, wozu seine Identität berechtigt ist, und dass jeder Zugriff im Protokoll landet.

Der gemeinsame Stecker zwischen Agent und Context Layer ist bei allen vier Anbietern das Model Context Protocol (MCP). Der Context Layer ist also nicht der Konkurrent zu MCP, sondern das, was die Anbieter darauf aufsetzen.

Wer was gebaut hat

Vier Anbieter, dasselbe Muster, unterschiedliche Namen:

Auffällig ist, wie ähnlich die Bausteine sind. Microsoft fasst das in drei Ebenen (Daten, Memory, Inference). Snowflake betont, dass die Semantik im Governance-Modul lebt und zur Abfragezeit durchgesetzt wird, statt irgendwohin kopiert zu werden. Databricks erlaubt mit kontextuellen Policies, einem Agenten je nach Nutzer, Modell oder sogar Inhalt der Anfrage etwas zu erlauben, zu verbieten oder eine Freigabe zu verlangen. Alle vier sprechen MCP, und alle vier verkaufen Auditierbarkeit als Kernfeature.

AWS im Detail, weil es der Auslöser war

AWS hat auf dem Summit zwei Dienste vorgestellt, die das Muster gut zeigen.

AWS Context baut automatisch einen Knowledge Graph über bestehende Datenquellen (Glue Data Catalog, SageMaker, Lake Formation) und lässt Agenten per agentischer Suche darauf zugreifen. Der entscheidende Punkt für Governance: Jede Abfrage erbt die IAM- und Lake-Formation-Rechte der aufrufenden Identität. Ein Agent sieht also genau das, was die Person dahinter sehen darf, nicht mehr. Weil der Zugriff über die Identität läuft, ist jede Interaktion auditierbar. Zwei Details fallen auf: Der Graph lernt mit, er merkt sich, welche Quellen und Join-Pfade zu korrekten Ergebnissen führen, und rankt sie nach Nutzung. Und die Metadaten werden offen im Apache-Iceberg-Format auf S3 abgelegt, also auch außerhalb der AWS-Tools abfragbar. Der Dienst war zum Summit als "coming soon" markiert.

AWS Continuum mit dem Security Agent ist die Sicherheitsseite. Der Agent macht Threat Modeling nach der STRIDE-Methodik, priorisiert gefundene Schwachstellen nach Geschäftsrelevanz und validiert sie in simulierten Umgebungen, um zu zeigen, ob sie wirklich ausnutzbar sind. Statt einer Liste von tausend theoretischen Findings bekommt das Team also die wenigen, die tatsächlich gefährlich sind. Für die Coding-Praxis am interessantesten: Es gibt ein Plugin für Claude Code und eine Kiro-Integration, sodass Code-Review, Threat-Modeling und Fixes direkt in der IDE laufen. On-Demand-Pentesting ist allgemein verfügbar, Code-Review und Threat-Modeling waren in der Preview, dazu eine zweimonatige kostenlose Testphase.

Das Prinzip hinter dem Marketing

Egal welcher Anbieter, drei Ideen tauchen überall auf. Sie sind die eigentliche Lektion, auch für Teams, die auf keiner dieser Plattformen sitzen.

Der Agent erbt die Rechte des Nutzers, statt eigene zu bekommen. Kein god-mode Service-Account, der an alles kommt. Der Agent handelt im Namen einer Identität und ist auf deren Berechtigungen beschränkt. Das begrenzt den Schaden, wenn er gekapert wird, auf das, was diese eine Person ohnehin anrichten könnte.

Policies werden zur Laufzeit durchgesetzt, nicht beim Einrichten. Ob ein Agent gerade eine Datei ändern, Code pushen oder auf sensible Daten zugreifen darf, entscheidet sich im Moment der Aktion, abhängig von Nutzer, Tool und teils sogar Inhalt der Anfrage. Statische Rollen reichen für autonome Agenten nicht mehr.

Jeder Zugriff ist nachvollziehbar. Auditierbarkeit ist kein nettes Extra, sondern die Voraussetzung dafür, dass man einem autonomen System überhaupt vertrauen kann. Wenn etwas schiefgeht, muss man rekonstruieren können, was der Agent wann mit welcher Berechtigung getan hat.

Was das für DACH-Teams und die DSGVO heißt

Die drei Prinzipien decken sich erstaunlich gut mit dem, was die DSGVO ohnehin verlangt. Identitätsgebundener Zugriff ist gelebte Datenminimierung, der Agent sieht nur, was nötig ist. Lückenlose Audit-Logs sind die technische Seite der Rechenschaftspflicht aus Artikel 5. Wer Agenten auf personenbezogene Daten lässt, kommt um beides nicht herum, und der Context Layer macht es zum Standardweg statt zur Bastellösung.

Zwei Haken bleiben. Erstens sind drei der vier Anbieter US-Clouds, und einiges ist noch Preview oder gar nicht verfügbar. Wer Datensouveränität ernst nimmt, sollte diese Dienste mit demselben kritischen Blick prüfen wie jeden anderen US-Cloud-Baustein. Die Fragen dafür liefert unser Artikel zur digitalen Souveränität für KI-Teams. Zweitens ist ein governierter Zugriff kein Freibrief. Prompt Injection und Goal Hijacking funktionieren auch dann noch, der Context Layer begrenzt nur den Radius des Schadens.

Für kleinere Teams ohne Enterprise-Plattform gilt dasselbe Prinzip im Kleinen: Gebt Agenten eigene, eng geschnittene Identitäten statt geteilter Vollzugriffe, protokolliert ihre Zugriffe, und setzt auf MCP als Anbindung, damit ihr Tools und Berechtigungen an einer Stelle kontrolliert. Wer ganz in eigener Hand bleiben will, kombiniert das mit lokal gehosteten Modellen.

Fazit

Dass vier Anbieter in drei Wochen dasselbe bauen, ist selten Zufall. Der Context Layer ist die Antwort der Branche auf eine Frage, die jedes Team früher oder später stellt: Wie lasse ich einen Agenten an echte Daten, ohne die Kontrolle zu verlieren? Die Produktnamen werden sich ändern, das Prinzip nicht. Identitätsgebundener Zugriff, Policies zur Laufzeit und lückenlose Audit-Logs sind das, was bleibt. Wer Agenten produktiv einsetzt, sollte diese drei Punkte zur Pflicht machen, ganz gleich, welche Plattform am Ende auf der Rechnung steht.