Integration

Wo die Grenze in Ihrem Stack sitzt

Die Governance-Schicht arbeitet extern. Sie müssen das Basismodell nicht ändern, und in den meisten Bereitstellungen auch den Agenten nicht — was sich ändert, ist der Weg, den eine folgenreiche Aktion nehmen muss, bevor sie zur operativen Tatsache wird.

Dies ist keine API-Referenz

Beschrieben wird, wohin der Kontrollpunkt gehört und was er braucht, nicht Endpunkt-Signaturen. Einen eingefrorenen Vertrag für ein System zu veröffentlichen, das nicht in Produktion ist, wäre derselbe Fehler wie ein Audit davon zu veröffentlichen — und ließe jeden auflaufen, der dagegen integriert hat. Die Endpunktreferenz erscheint zur allgemeinen Verfügbarkeit, zusammen mit der Pentest-Zusammenfassung und der Statusseite.

Zusicherungsstatus ansehen

Was jeder Weg leisten muss

Wie die Grenze auch verdrahtet ist: dieselben sechs Schritte müssen erfolgen, bevor eine externe Aktion freigegeben wird. Sie stammen aus dem öffentlichen Referenzmuster unseres White Papers.

  1. 01

    Aktion definieren

    Die vorgeschlagene externe Aktion, ihr Ziel, ihren Umfang und die erwartete Konsequenz als begrenzte Anfrage ausdrücken.

  2. 02

    Prinzipal auflösen

    Feststellen, in wessen Auftrag die Aktion angefordert wird und welche Autorität dieser Prinzipal tatsächlich hat.

  3. 03

    Richtlinie anwenden

    Die Anfrage gegen den für diese Entscheidung gültigen Richtlinien- und Risikozustand prüfen.

  4. 04

    Nachweise verlangen

    Bestätigen, dass verbindliche Freigaben, Fakten, Vorbedingungen und menschliche Bestätigungen vorliegen und aktuell sind.

  5. 05

    Disposition ausstellen

    Eine explizite Freigabe, Zurückhaltung, Eskalation oder Sperre zurückgeben. Schweigen ist keine Erlaubnis.

  6. 06

    Ausführung beschränken

    Das nachgelagerte System nur auf eine autorisierte Disposition hin handeln lassen und die Entscheidungsnachweise aufbewahren.

Die vier Wege unten unterscheiden sich darin, wo diese Sequenz läuft und was sie sehen kann — nicht darin, was sie entscheidet.

Vier Integrationswege

01

Adapter

In der Agent-Laufzeit

Der Adapter umschließt die Tool-Aufruf-Oberfläche des Agenten. Ein vorgeschlagener Aufruf wird zur Disposition eingereicht und nur bei Erlaubnis freigegeben.

Wo es sitzt
Zwischen dem Agent-Framework und den Tools, die es aufrufen kann.
Passend wenn
Sie besitzen den Agent-Code und wollen den kürzesten Weg zu einem gesteuerten Piloten.
Sie liefern
  • Eine Richtliniendomäne für den Anfang
  • Eine Quelle für die dort geforderten Nachweise
  • Eine namentlich benannte menschliche Verantwortung für Eskalationen

Die Vermittlung reicht nur so weit wie die Abdeckung des Adapters. Jedes Tool, das der Agent daran vorbei erreicht, ist ungesteuert — genau das Versagen, dessen Verhinderung diese Schicht dient.

02

Middleware

Im Anfragepfad

Die Grenze läuft als Dienst im Netzpfad, sodass folgenreiche Aufrufe sie passieren, gleich welcher Agent oder welche Sprache sie erzeugt hat.

Wo es sitzt
An einer Dienst- oder Netzgrenze, vor den Systemen, die Konsequenz tragen.
Passend wenn
Mehrere Agenten, mehrere Teams oder Agent-Code, den Sie nicht kontrollieren — auch Anbieter-Agenten.
Sie liefern
  • Routing, das folgenreiche Aufrufe durch die Grenze zwingt
  • Identitätsweitergabe, damit der Prinzipal auflösbar ist
  • Bereitstellungsumgebung und ihre Zusicherungspflichten

Vollständige Vermittlung wird zur Netzeigenschaft. Kann ein Dienst aus Latenzgründen ein System mit Zugangsdaten direkt erreichen, ist diese Route die Lücke.

03

Tool-Broker

Das Modell hält nie die Zugangsdaten

Der Agent bittet einen Broker, eine Operation auszuführen. Der Broker hält Autorität und Zugangsdaten und handelt nur auf eine autorisierte Disposition hin.

Wo es sitzt
Zwischen dem Agenten und jedem System mit Zugangsdaten oder Außenwirkung.
Passend wenn
Wildwuchs bei Zugangsdaten und übermäßige Handlungsvollmacht sind Ihre Hauptrisiken.
Sie liefern
  • Ein Register erlaubter Operationen
  • Kurzlebige, aufgabenbezogene Zugangsdaten, die der Broker ausstellen kann
  • Widerrufspfad und dessen Verantwortliche

Der Broker wird ein hochwertiges Ziel und ein Single Point of Failure. Das verlangt die entsprechende operative Behandlung, nicht nur ein Architekturdiagramm.

04

Hardware-Schnittstellen

In Reihe mit dem Aktor

Governance-Silizium sitzt im Aktuierungspfad selbst. Der Zustand liegt auf dem Die, und zum Entscheidungszeitpunkt ist keine Netzwerkschnittstelle aktiv.

Wo es sitzt
Auf dem Gerät, physisch in Reihe mit dem Ausgang, der die Konsequenz erzeugt.
Passend wenn
Die Konsequenz ist physisch oder irreversibel, oder das Gerät muss offline weiter steuern.
Sie liefern
  • Den physischen und elektrischen Integrationspunkt
  • Einen Bereitstellungsweg für authentifizierten Richtlinienzustand
  • Erwartungen zu Field-of-Use und Volumen

Dies ist ein Patent- und Entwicklungsportfolio, kein lieferbares Bauteil. Der Einsatz erfordert unabhängige Validierung, Sicherheitsengineering, Akkreditierung und operative Freigabe.

Die Wahl zwischen ihnen

AdapterMiddlewareBrokerHardware
Änderungen am Agent-CodeJaNeinTeilweiseNein
SprachunabhängigNeinJaJaJa
Vermittlung garantiert durchAdapter-AbdeckungNetz-RoutingHalten der ZugangsdatenPhysische Reihe
Steuert offlineNeinNeinNeinJa
Hält ZugangsdatenNeinNeinJaNein
Typischer erster PilotJaJaNeinNein

Die meisten ersten Bereitstellungen sind ein Adapter oder Middleware um eine kontrollierte Aktion. Broker und Silizium folgen, sobald sich die Grenze an etwas bewährt hat, das klein genug zum Anhalten ist.

Mit der Grenze beginnen, nicht mit der Verdrahtung

Welcher Weg passt, ist ein Ergebnis des Boundary Assessments, keine Vorgabe dafür. Das Assessment bildet einen Workflow ab, sein Autoritätsmodell, die geforderte Richtlinie und Nachweise sowie die Bedrohungsgrenze — der Integrationsweg fällt daraus ab. Die Verdrahtung zuerst zu wählen erzeugt meist einen gesteuerten Pfad, um den die folgenreichen Aktionen herumrouten können.

Ansehen, wie wir bepreisenWhite Paper lesenFAQ lesen