Am 7. Oktober 2026 stellte Apollo GraphQL GraphOS Agent Services vor – eine Preview des Dienstes zur Verwaltung des Zugriffs von KI-Agenten auf Unternehmens-APIs. Administratoren können einzelne Datenfelder freigeben, maskieren oder sperren. Die Teilnahme wird mit Unterstützung von Apollo eingerichtet.

Was Apollo vorgestellt hat
Nach Angaben des Unternehmens ist Agent Services zwischen dem Agenten und internen Systemen angesiedelt: Der Dienst wandelt Anfragen in API-Aufrufe um, ermöglicht die Nutzung von Anmeldedaten und setzt Einschränkungen durch. Apollo nennt vier Funktionen: das Auffinden von Daten und Tools, Identitätsverwaltung, Zugriffsrichtlinien und Auditing. Diese werden in der offiziellen Ankündigung des Dienstes aufgeführt.
Die über PR Newswire verbreitete Pressemitteilung von Apollo wurde am 7. Oktober um 12:02 Uhr US-Ostküstenzeit veröffentlicht – um 19:02 Uhr Moskauer Zeit. Dies ist der Zeitpunkt der Veröffentlichung der Mitteilung; eine genaue Angabe dazu, wann der Zugang freigeschaltet wurde, gibt es nicht.
Warum der Zugriff von Agenten beschränkt werden sollte
Ein von Apollo angeführtes praktisches Szenario ist der Einsatz eines Agenten durch verschiedene Mitarbeitende. Im Beispiel aus dem Unternehmensblog fragen ein Supportmitarbeiter und ein Finanzanalyst Informationen zu einer strittigen Rechnung ab. Beide erhalten die Rechnung, aber nur der Analyst kann das Kreditlimit des Kunden einsehen. Der Unterschied ergibt sich aus der Klassifizierung des Feldes und der Zugriffsrichtlinie.
Dieser Ansatz ist für Teams nützlich, die Agenten mit Kunden-, Finanz- und anderen internen Diensten verbinden: Berechtigungen lassen sich für bestimmte Daten festlegen und danach ausrichten, wer dem Agenten die Aufgabe erteilt hat. Apollo berichtet außerdem von einem Pilotprojekt bei Intuit. Das reguläre GraphOS wird dort bereits produktiv eingesetzt, während der neue Agent Services noch vorläufig getestet wird. Das Unternehmen verbindet das Pilotprojekt mit der Analyse von Marketingausgaben; in der Ankündigung werden keine quantitativen Einsparungsergebnisse genannt.
Wie die Regeln funktionieren
Laut der Dokumentation zu den Zugriffsregeln legt eine Regel den Benutzer oder die Gruppe, die aufrufende Anwendung, die geschützten Daten und das Ergebnis der Prüfung fest. Felder werden mit Tags klassifiziert; eine Regel kann für ein Tag oder einen Dienst gelten. Es gibt drei mögliche Effekte: den Wert zurückgeben, seinen Inhalt verbergen oder den Zugriff verweigern.
Für eine Zugriffssperre gibt es mehrere Optionen: Das Feld wird vollständig aus der Antwort entfernt, es wird ein Fehler zurückgegeben oder eine zusätzliche Zugriffsanfrage ist möglich. Hat ein Feld mehrere Tags, gilt der strengere Effekt: Eine Sperre hat Vorrang vor einer Maskierung, eine Maskierung vor einer Freigabe.
Ein wichtiger Aspekt der Konfiguration: Apollo weist im Administrationsleitfaden darauf hin, dass der Dienst die Benutzer- oder Gruppenkennung beim Identitätsanbieter derzeit nicht überprüft. Ein Tippfehler führt dazu, dass eine Regel Anfragen stillschweigend nicht mehr zuordnet. Daher sollte die Überprüfung des tatsächlichen Ergebnisses für jede Rolle Bestandteil des Pilotprojekts sein.
Nach der Beschreibung der Apollo-Architektur trifft die Richtlinien-Engine die Zugriffsentscheidung ohne Beteiligung eines Sprachmodells. Dort heißt es auch, dass Felder ohne Klassifizierungstag nicht eingeschränkt sind. Die Dokumentationsübersicht empfiehlt dagegen, Felder des angebundenen Dienstes zu sperren, bevor Berechtigungen erteilt werden. Diese Aussagen erfordern eine Prüfung der konkreten Konfiguration: Das Team sollte den Zugriff auf Felder mit und ohne Tags gesondert testen.
Auditing und Verfügbarkeit
Der Leitfaden zu Monitor beschreibt ein Anfragenprotokoll mit Zeitpunkt, Client, Tool, Operation, betroffenem Dienst und Ergebnis der Regelanwendung. Für eine einzelne Anfrage lässt sich nachvollziehen, welche Regeln gegriffen und welche Felder maskiert oder gesperrt wurden.
Das Auditing hat eine wichtige Grenze: Die Ansicht der Antwort zeigt deren Struktur und die geänderten Felder, aber nicht die Werte, die der ursprüngliche Dienst zurückgegeben hat. Die Prüfung des konkreten Antwortinhalts muss separat geplant werden. Der CSV-Export umfasst die Anfragen, die auf der aktuellen Protokollseite geladen sind.
Die Quellen verwenden unterschiedliche Bezeichnungen für die Zugangsphase. In seinem Blogbeitrag vom 7. Oktober kündigt Apollo eine Public Preview an und bietet eine Warteliste an. Die Dokumentation des Dienstes bezeichnet die Phase als Private Preview und sieht für die Teilnahme die Unterstützung eines Apollo-Mitarbeiters vor. Da auf dieser Seite kein Aktualisierungsdatum angegeben ist, lässt sich die Reihenfolge der unterschiedlichen Formulierungen nicht feststellen.
Derzeit führt der praktische Weg über die Abstimmung eines Pilotprojekts mit Apollo. In den geprüften Materialien sind weder ein Termin für eine stabile Version noch ein Preis für Agent Services angegeben. Vor der Teilnahme sollte das Team die für den Agenten vorgesehenen Felder, die Verantwortlichen für Berechtigungen und Testanfragen für jede Rolle festlegen.