Die Kontextschicht, die niemand gebaut hat
Die meisten Gespräche über Agenten sind Gespräche über Modelle. Welches denkt am besten, welches ist am günstigsten, auf welches standardisiert man. Das ist der naheliegende Ort zum Hinschauen, weil das Modell der Teil ist, der neu wirkt.
Nur entscheidet das Modell selten darüber, ob ein Agent in Ihrem Unternehmen nützlich ist. Ein Agent ist nur so gut wie der Kontext, den er erreicht, und Ihr Kontext lebt nicht im Modell. Er lebt über Ihre Menschen, Prozesse und Systeme verteilt: das CRM, das Kernsystem, das Dokumentenarchiv, die Ticket-Queue, der Mensch, der die eine Ausnahme kennt, auf die es ankommt. Die meisten Organisationen haben die Schicht nie gebaut, über die ein Agent diesen Kontext sicher erreicht. Also sieht der Agent entweder zu wenig, um nützlich zu sein, oder er wird mit breiten, stehenden Credentials verdrahtet, die kein Sicherheitsgremium je freigeben würde.
Diese fehlende Schicht ist der stille Grund, warum die meisten Projekte stecken bleiben. Es ist kein Modellproblem. Es ist ein Interoperabilitäts- und Identitätsproblem, und es ist unglamourös genug, dass fast niemand es einplant, bis er dagegen läuft.
Diese Schicht ist keine Integrationsinstallation
Der verlockende Zug ist, das einem Integrationsteam zu geben und es Installation zu nennen. Widerstehen Sie, denn jede Entwurfsentscheidung in dieser Schicht ist eine Sicherheitsentscheidung, und sie als Installation zu behandeln ist die Art, wie Sicherheitslücken von Leuten eingebaut werden, die nie danach gefragt wurden.
Die Kontextschicht hat drei Teile, und an jedem trennen sich eine ernsthafte und eine hoffnungsvolle Architektur.
Teil eins: typisierte Capabilities, kein Haufen API-Schlüssel
Ein Agent muss aus Ihren Systemen der Wahrheit lesen und in sie schreiben. Der bequeme Weg dafür ist ein Bündel API-Schlüssel und breiter Zugriff. Der richtige Weg sind explizite, typisierte Capabilities.
Denken Sie an jede Capability als schmale, benannte Tür: read_dossier, request_document, post_decision_for_review. Der Agent erhält die konkreten Türen, die er für eine konkrete Aufgabe braucht, und sonst nichts. Jede Tür wird protokolliert.
Das ist kein kosmetischer Unterschied. Es ändert den Satz, den Ihr Sicherheitsgremium bewerten muss. "Der Agent kann unsere Systeme berühren" ist nicht prüfbar, und niemand sollte das unterschreiben. "Der Agent kann diese sieben benannten Aktionen ausführen, jede protokolliert" ist ein Control, das ein Gremium freigeben kann. Typisierte Capabilities machen aus einer offenen Integration eine begrenzte, prüfbare Fläche.
Teil zwei: nicht-menschliche Identität, kurzlebig und least privilege
Ein Agent ist keine Person, und er darf nie die Credentials einer Person ausleihen.
Das ist die häufigste Art, wie Projekte im Sicherheitsgremium scheitern, denn der schnelle Weg, den Agenten unter dem persönlichen Token einer Entwicklerin mit stehendem Produktionszugriff laufen zu lassen, ist genau der Befund, der das Projekt stoppt. Dieses Token ist ein Generalschlüssel. Es ist nicht eingegrenzt, es läuft nicht schnell ab, und es unterscheidet die Aktionen des Agenten nicht von denen der Entwicklerin.
In einer korrekten Architektur läuft jeder Agent unter seiner eigenen nicht-menschlichen Identität, mit kurzlebigen Least-Privilege-Credentials und einer expliziten Egress-Allow-List. Die Folge lohnt die klare Formulierung: Ein gestohlenes Agenten-Credential ist fast nichts wert. Es gibt kein statisches Geheimnis zu stehlen, und die Identität kann nur die wenigen Dinge tun, für die sie zugeschnitten wurde, zu den wenigen Zielen, die sie erreichen darf. Der eine Entwurf besteht die Freigabe. Der andere ist der Befund, der das Mandat beendet.
Identität macht den Audit-Trail auch erst aussagekräftig. Wenn jede Aktion die eigene Identität des Agenten und seine zugeschnittenen Capabilities trägt, hat "wer hat das getan?" eine präzise Antwort, und die Aufzeichnung, die Ihre Prüfer ansehen, rekonstruiert tatsächlich, was passiert ist.
Teil drei: die Taint-Grenze, an der unzuverlässige Daten nicht zu Privileg werden
Das ist der Teil, der eine ernsthafte von einer hoffnungsvollen Architektur trennt, und er verdient Sorgfalt, denn er ist der häufigste Weg, auf dem Agenten in Produktion kompromittiert werden.
Ein Agent liest Inhalte, die er nicht verfasst hat: eine Kunden-E-Mail, einen gescannten Vertrag, ein PDF von einem Dritten. Dieser Inhalt ist nicht vertrauenswürdig. Enthält ein vergiftetes Dokument Text, der wie eine Anweisung klingt, und behandelt der Agent ihn als solche, hat das Dokument gerade einen Agenten entführt, der Zugriff auf Ihre Kernsysteme hat. Das ist indirekte Prompt Injection, und kein Prompt, Filter oder Konfigurationsschalter hält sie zuverlässig auf.
Die strukturelle Antwort ist eine Taint-Grenze: unzuverlässige Daten werden nie zu ausführbarem Privileg. In der Praxis wird sie durchgesetzt, indem man die Rollen des Agenten trennt, das Muster namens CaMeL, ein Dual-LLM-Entwurf. Ein privilegierter Planer entscheidet, was zu tun ist, und ruft die typisierten Werkzeuge auf, liest aber nie direkt rohe unzuverlässige Inhalte. Ein isolierter Reader liest diese Inhalte, kann aber keine Werkzeuge aufrufen und nicht handeln. Er gibt eine Referenz zurück, keine Anweisung. Bei jeder Mehrdeutigkeit schlägt das System geschlossen fehl.
Es gibt einen ehrlichen Preis. Die Rollentrennung kostet ungefähr ein paar Punkte Nutzen. Das ist der Handel: ein bescheidener Genauigkeitspreis für eine strukturelle Garantie, dass ein Dokument keinen in Ihre Kernsysteme verdrahteten Agenten übernehmen kann. In regulierter Arbeit ist das keine knappe Entscheidung.
Keine einzelne Schicht soll allein halten. Die Taint-Grenze sitzt in Defense-in-Depth: Spotlighting zur Verkleinerung der Angriffsfläche, CaMeL-Isolation, Detection-Guardrails und ein Policy-Entscheidungspunkt über allem. Spotlighting verringert die Angriffsfläche. Es beseitigt sie nicht, und genau deshalb ist es nie die einzige Schicht.
Warum diese Schicht auf Ihren echten Prozessen gebaut gehört
Sie können diese Schicht nicht von der Stange kaufen, weil sie von Ihren Systemen, Ihren Identitäten und Ihren Datengrenzen geformt wird. Sie muss auf Ihren echten Prozessen gebaut werden, forward-deployed, an der tatsächlichen Arbeit, nicht an einem Referenzdiagramm.
Deshalb ist es auch die Schicht, die still über alles Nachgelagerte entscheidet. Das beste Modell der Welt, geroutet über das portabelste Gateway, governt von der strengsten Autonomieleiter, nützt nichts, wenn der Agent den Kontext, den er zum Handeln braucht, nicht sicher erreichen kann. Umgekehrt erreichen Agenten, sobald die Kontextschicht existiert, nur, was sie dürfen, handeln unter eigenen Least-Privilege-Identitäten und können nie dazu gebracht werden, unzuverlässige Daten als Anweisung zu behandeln, mit einer vollständigen Spur, die Ihre Prüfer ansehen können. Alles andere in einer agentischen Architektur setzt voraus, dass diese Schicht bereits existiert.
Die Umdeutung lautet also nicht "welches Modell sollen unsere Agenten nutzen?". Sie lautet: was ist für jedes System, das unsere Agenten erreichen müssen, die typisierte Capability, welche Identität hält der Agent, und wo verläuft die Grenze zwischen den Inhalten, die er liest, und den Aktionen, die er ausführen kann? Können Sie das nicht pro System beantworten, spielt die Modellwahl noch keine Rolle. Die Schicht darunter ist nicht gebaut.
Wenn Sie die Kontextschicht für einen Prozess mit hohem Einsatz kartieren wollen, buchen Sie einen Termin.