Harvey zeigt, wie die Connector Library Tool-Aufrufe von Agenten an Berechtigungen bindet

Von der Katalogkachel zu Tools in der Hand des Agenten

In Harveys Konzept aktiviert ein Admin einen Connector, ein Nutzer verbindet sich einmalig, und die Dienste, auf die sich die Kanzlei ohnehin stützt, lassen sich direkt in Harvey nutzen. Ein Connector ist ein Objekt auf Anbieterebene: eine Kachel im Katalog mit einer Berechtigung und einem Admin-Schalter. Dahinter stehen ein oder mehrere Member, die jeweils einen Teil der Integration liefern. Ein Member ist entweder eine native Integration oder ein MCP-Connector, also ein vom Anbieter betriebener Server, den Harvey über das Model Context Protocol aufruft.

Alles, was einen Connector definiert, steht in einer zentralen Registry im Code, darunter seine Fähigkeiten, seine Berechtigung und ein für den Agenten geschriebener Routing-Hinweis. Das mache das Onboarding günstig, so Harvey, und seit dem Start des Early Access seien nach und nach neue Connectors in den Katalog gekommen.

Arbeitet ein Nutzer mit dem Agenten, sendet der Client den ausgewählten Connector und die Tools mit der Anfrage mit. Das Backend löst diese Auswahl pro Turn einmal in native oder MCP-Member samt Tool-Konfigurationen auf und weist unbekannte Connector-Typen und Tool-Schlüssel ab. Erlaubte Aufrufe gehen mit den eigenen Zugangsdaten der jeweiligen Verbindung hinaus. Bei Quellen mit personenbezogenen Daten ist das stets die Freigabe des anfragenden Nutzers, sodass das Quellsystem nur das zurückgibt, was dieser Nutzer nach seinen eigenen Zugriffskontrollen sehen darf. Von nativen Membern abgerufene Dokumente erscheinen mit Inline-Zitaten, während die Ausgabe von MCP-Membern als Klartext in den Modellkontext gelangt.

Sicherheitsprüfung und Laufzeitrichtlinie für MCP-Tools

Harveys Sicherheitsteam prüft jeden Connector vor dem Start auf Bedrohungen wie Prompt Injection, Missbrauch von Schreibrechten, kompromittierte Zugangsdaten, mandantenübergreifende Datenlecks und Lieferkettenrisiken. Native Member sind von Harvey geschriebene Wrapper um die API eines Anbieters, daher umfasst die Prüfung, welche APIs aufgerufen und welche Scopes angefordert werden.

MCP-Member durchlaufen eine zusätzliche Zulassungsstufe, weil der Anbieter den Server betreibt. Der Anbieter reicht seine vollständige Tool-Liste und den Funktionsumfang, Angaben zu Hosting und Authentifizierung, Regionen der Datenverarbeitung sowie Testzugänge ein. Das Sicherheitsteam prüft die Tools anschließend einzeln, genehmigt jedes und weist ihm eine Risikostufe zu. Laut Harvey ist diese Freigabe eine harte Hürde, bevor die technische Integration beginnt. Die Entscheidungen liegen in einer Registry, die mit dem Code ausgeliefert wird.

Zur Laufzeit prüft eine eigens entwickelte MCP-Policy-Engine jeden Aufruf. Sie stellt sicher, dass das Tool noch auf der Liste der genehmigten Tools steht, dass die bei der Prüfung vergebene Risiko- und Fähigkeitsannotation vorhanden ist (fehlt sie, wird der Aufruf konsequent abgelehnt) und dass die Einstellungen von Workspace und Nutzer den Aufruf erlauben. Die Regeln sind in Rego geschrieben, der Policy-Sprache von Open Policy Agent, wobei der Interpreter im selben Prozess eingebettet ist. Die Eingabe ist bewusst datenblind: Nur die Identität des Tools, seine Risikostufe, Fähigkeits-Flags und die Namen früherer MCP-Aufrufe im Lauf erreichen die Regeln, niemals Nutzerargumente oder Freitext. Ein Fehler bei der Regelauswertung führt zur Ablehnung (Fail Closed).

• Harvey hinterlegt bei der Prüfung einen Fingerprint der Beschreibung und des Eingabeschemas jedes genehmigten Tools und vergleicht ihn bei jeder Discovery. Eine Änderung oder ein Verschwinden löst einen Alarm im Team aus.
• Tool-Ergebnisse durchlaufen eine Bereinigung, einschließlich der Erkennung verwechselbarer Zeichen aus gemischten Schriftsystemen.
• Tool-Argumente, Ergebnisinhalte, Server-URLs und Nutzerkennungen tauchen nie in Health-Events und Metriken auf.

Auch Kunden erhalten Kontrollen. Ein Workspace-Admin kann einen Connector, einen Member oder ein einzelnes MCP-Tool deaktivieren oder aktivieren, und Nutzer können die Einstellungen weiter verschärfen. Die Tools, die das Modell sieht, sind jene, die der Anbieter bereitstellt, Harvey geprüft hat, Workspace- und Nutzereinstellungen erlauben und die bei vorhandener Auswahl ausdrücklich für die Anfrage gewählt wurden.

Unterschiede zwischen Anbietern in einer Adapterschicht abfangen

Anbieter verhalten sich laut Harvey unterschiedlich, und das führt zu konkreten Fehlern: Ein gültiges Token wird als ungültig verworfen, ein Nutzer soll ohne erkennbaren Grund erneut autorisieren, oder ein Tool-Schema, das der Anbieter als zulässig deklariert, wird vom Modell abgelehnt.

Die MCP-Autorisierungsspezifikation entwickelt sich weiter, und Server unterstützen verschiedene Versionen. Der erwartete Ablauf umfasst die Discovery über Protected-Resource-Metadaten (RFC 9728), Metadaten des Autorisierungsservers (RFC 8414), Dynamic Client Registration (RFC 7591) sowie OAuth 2.1 mit PKCE und Resource Binding (RFC 8707). In der Praxis, so Harvey, senden manche Server nie die 401-Antwort, die die Discovery auslösen sollte, ein Token-Endpunkt liefert ein gültiges Token mit 201 Created zurück, und Server lesen dieselbe Scope-Deklaration unterschiedlich.

Für die Client-Registrierung gibt es drei Wege. Die Spezifikationsversion 2026-07-28 macht CIMD (Client ID Metadata Documents) zum empfohlenen Weg und stuft Dynamic Client Registration als veraltet ein, behält sie aber aus Gründen der Abwärtskompatibilität bei. Einige von Harvey angebundene Server unterstützen nur die dynamische Registrierung, andere funktionieren nur mit einem Client, den Harvey vorab registriert.

Auch der Umgang mit Tokens ist ein Engpass. Mehrere Anbieter stellen Refresh-Tokens zur einmaligen Verwendung aus, während Frontend-Vorabprüfungen, geplante Synchronisierungen, Exportjobs und die Erneuerung im Hintergrund alle gleichzeitig das Token desselben Nutzers wollen können. Die Schicht verarbeitet täglich rund 13 Millionen Lesezugriffe auf Zugangsdaten.

Harveys Adapter folgt dem Verhalten, das ein Server tatsächlich zeigt. Er kann Metadaten direkt ermitteln, wenn keine Challenge gesendet wird, gültige Tokens mit 200 oder 201 akzeptieren und die Scopes anfordern, die ein Server bewirbt. Bedingte Rückschreibvorgänge regeln konkurrierende Token-Updates ohne Sperren. Bei der Discovery werden Tool-Schemas vor der Registrierung beim Agenten normalisiert, und unbekanntes Verhalten löst einen Alarm aus, damit das Team die Integration anpassen kann.

Was das für Kanzleien bedeutet, die Harvey nutzen

Für Kanzleien bedeutet das Design, dass Agenten über die bereits genutzten Tools hinweg arbeiten können, ohne den Kreis derer zu erweitern, die etwas sehen dürfen. Aufrufe laufen unter der eigenen Freigabe des anfragenden Nutzers, die Berechtigungen der Quellsysteme gelten weiterhin, und Admins können Connectors, Member oder einzelne MCP-Tools abschalten. Anbieterspezifische Eigenheiten bei Autorisierung und Schemas werden laut Harvey innerhalb der Adapterschicht abgefangen, sodass der Agent dieser Komplexität nicht ausgesetzt ist.