Kontext

Kontext liefert Security- und Plattformteams eine Kontrollschicht für KI-Agenten, die im Unternehmen schon Werkzeuge bedienen, Dateien anfassen und mit Unternehmenszugängen handeln. Statt nur zu fragen, ob eine Identität grundsätzlich berechtigt ist, prüft Kontext die konkrete nächste Aktion: Welcher Agent, welche Sitzung, welches Werkzeug, welche Ressource, welcher Auftrag – und darf das jetzt passieren?

Angesprochen sind Organisationen, die Coding-Assistenten, Arbeitsplatz-Agenten, MCP-Server, interne Copilots oder selbst gebaute Agenten an echte Daten und produktionnahe Systeme legen. Nutzerinnen und Nutzer sitzen in Security, Plattform, KI-Engineering, Compliance und Developer Experience. Kontext ersetzt IAM, OAuth oder SSO nicht. Diese Systeme klären Login und grobe Rechte. Kontext beantwortet die Frage, die dort offen bleibt.

Klassische Zugriffskontrolle geht von einem Menschen aus, der nacheinander klickt. Ein Agent authentifiziert sich einmal und handelt danach selbstständig über viele Systeme. Er kann gültige Zugangsdaten und ein freigegebenes Werkzeug nutzen und trotzdem etwas tun, das niemand für den aktuellen Auftrag vorgesehen hat – Quellcode an einen externen Dienst schicken, eine andere Infrastruktur anfassen, denselben Zugang für eine andere Aufgabe verbrauchen. Kontext setzt genau an dieser Grenze an, bevor der Tool-Call, der API-Aufruf oder der Dateizugriff ausgeführt wird.

Die Software läuft in der Umgebung des Agenten. Policies bewerten Aktionen an Kontrollpunkten vor der Ausführung und erlauben oder verweigern sie. Risikoerkennung markiert Vorgänge zur Untersuchung, ändert Allow und Deny aber nicht. Eine Kostenansicht zeigt Token und API-Äquivalente hinter den Modellaufrufen, ebenfalls getrennt von der Policy-Entscheidung. Teams starten im Beobachtungsmodus: Sie sehen, was eine Regel blockieren würde, ohne den Agenten zu unterbrechen. Wenn die Treffer stimmen, wird dieselbe Policy durchgesetzt. Jede Entscheidung bleibt als nachvollziehbarer Trace: wer, welcher Agent, welches Werkzeug, warum erlaubt oder verweigert.

Kontext deckt Coding-Assistenten wie Claude Code, Codex und Claude Cowork, Arbeitsplatz-Agenten und eigene Agenten auf Endpunkten und in Cloud-Umgebungen ab. Der Einstieg kann lokal sein: Installation über Homebrew auf dem Mac, persönlicher API-Schlüssel, ein nur lesender Testlauf. Standard ist der lokale Entscheidungspfad; eine verwaltete Schicht kommt dazu, wenn geteilte Traces, Organisationsregeln und zentrale Prüfung gebraucht werden.

Für MCP-Aufrufe ergänzt Kontext die gemeinsame Werkzeugschnittstelle um eine Policy-Schicht. Geprüft werden Werkzeug, Argumente, Nutzerkontext, Geltungsbereich der Zugangsdaten und Zielressource. Ein Agent, der einen Fehler im Code beheben soll, darf ein Repository lesen. Denselben Zugang für den Export nach außen oder für einen anderen Auftrag zu nutzen, ist eine andere Entscheidung.

Das Preismodell beginnt kostenfrei mit 5.000 Transaktionen im Monat. Das Team-Paket liegt bei 500 US-Dollar monatlich für 100.000 Transaktionen, danach ein US-Dollar je 1.000. Enterprise wird individuell vereinbart. Kontext sitzt in München. Jens Ernstberger und Michel Osswald führen das Unternehmen; Ernstberger ist Mitgründer und CEO.

Kontext hängt Entdeckung, Zugriffskarte, Policy, Risiko und Kosten aneinander. Auf verbundenen Endpunkten und in Cloud-Umgebungen werden Coding-Assistenten, Arbeitsplatz-Agenten und eigene Agenten sichtbar, inklusive der Werkzeuge, Systeme und Daten, die sie erreichen können.

An der Aktionsgrenze prüft Kontext den geplanten Schritt, bevor er läuft: Akteur, Sitzung, Werkzeug, Ressource, Parameter, Policy. Das Ergebnis ist Allow oder Deny. Im Beobachtungsmodus wird nur protokolliert, was eine Regel tun würde. Im Durchsetzungsmodus blockiert dieselbe Regel unterstützte Aufrufe. Risiko-Flags und Kostenpreise ändern die Entscheidung nicht.

Für MCP-Werkzeuge bewertet Kontext Name, Argumente, Nutzerkontext, Credential-Scope und Ziel, bevor der Call weitergeht, zur Prüfung vorgelegt oder abgelehnt wird. Traces halten fest, was versucht, erlaubt oder verweigert wurde und warum. Lokal startet der Pfad auf dem Entwicklerrechner; geteilte Traces und Organisationsregeln kommen als verwaltete Schicht dazu.

Immer mehr Unternehmen lassen Agenten nicht nur Texte erzeugen, sondern Software bedienen, Dateien lesen und mit echten Zugangsdaten handeln. Klassische IAM-Modelle beantworten, ob eine Identität grundsätzlich zugreifen darf. Sie beantworten nicht, ob die konkrete Aktion zum aktuellen Auftrag passt.

Kontext positioniert sich als Runtime-Autorisierung für genau diese Lücke – für Security-, Plattform- und KI-Teams, die Agenten in Produktion legen und dafür Beobachtung, Durchsetzung und prüfbare Spuren brauchen. Der Markt sind Organisationen mit Coding-Agenten, MCP-Servern, Browser-Agenten, internen Copilots und autonomen Workflows, nicht der Endnutzer-Chatbot.

Die Plattform setzt neben bestehende Identitätssysteme und verkauft sich über Selbstbedienung (kostenfrei und Team) sowie Enterprise-Rollouts.