Ihre Anwendung und Ihr Agent
Denkt nach, wählt Tools und schlägt Aktionen vor. Ihre Anwendung liefert den authentifizierten Benutzer, die Ressource und die Aufgabe. Der Agent besitzt keine Zugangsdaten für eine geschützte Aktion.
Phalanx
Wie Phalanx Agentenaktionen steuert
Phalanx ist ein Gateway, das Sie in Ihrer eigenen Infrastruktur zwischen Ihren KI-Agenten und den Systemen betreiben, die sie verändern. Hier erfahren Sie, was es prüft, wie jede Entscheidung bei der Ausführung durchgesetzt wird, was es aufzeichnet und was Ihre Architektur benötigt.
Vom Vorschlag zum aufgezeichneten Ergebnis
Drei Komponenten bleiben getrennt, sodass die Komponente, die eine Aktion vorschlägt, niemals diejenige ist, die sie ausführen kann.
Phalanx
Prüft Autorität und Vertrag, führt Budgets, bewertet Evidenz, erteilt einmal verwendbare Erlaubnisse und zeichnet den Ausführungszustand auf. Es läuft als eigener Dienst; Ihre Geschäftslogik wird nicht hineinkopiert.
Geschützter Konnektor
Besitzt die Geschäftszugangsdaten, prüft die Bedingungen der Erlaubnis erneut, führt die Operation aus und meldet das Ergebnis zur Verifizierung. Es kann Ihre bestehende API oder ein kleiner isolierter Dienst sein.
Fünf Schritte, jedes Mal
Vorschlagen.
Der Agent ruft ein Tool auf. Der SDK-Adapter sendet den Vorschlag an Phalanx, zusammen mit dem Benutzer und der Aufgabe, die Ihre Anwendung authentifiziert hat.
Entscheiden.
Phalanx bewertet die Aktion anhand ihres Vertrags, des aktuellen Zustands, der erforderlichen Evidenz und der verbleibenden Grenzen und antwortet mit PERMIT, HOLD oder BLOCK.
Erlauben.
Eine erlaubte Aktion erhält eine einmal verwendbare Erlaubnis, die an genau diese Operation gebunden ist.
Ausführen.
Der geschützte Konnektor prüft die Bedingungen erneut und führt die Operation mit seinen eigenen Zugangsdaten aus.
Verifizieren und aufzeichnen.
Phalanx zeichnet das verifizierte Ergebnis auf oder markiert es als ungewiss und verknüpft es mit der Entscheidung.
Sie definieren den Vertrag. Phalanx setzt ihn durch.
Ein Vertrag beschreibt eine Aktion genau: was sie betrifft, wer sie auslösen darf, wohin sie gehen darf, von welchem Zustand sie abhängt und welche Grenzen gelten. Verträge sind versionierte Dateien, die Sie prüfen und anschließend ausdrücklich aktivieren. Die Bereitstellung eines Vertrags aktiviert ihn nicht.
Ein Vertrag kann festlegen
- Das Tool, seine Wirkungsklasse und die betroffene Ressource
- Den erforderlichen authentifizierten Akteur
- Das genaue Konnektorziel: Schema, Host, Port, Methode und Pfad
- Eine Referenz auf die Zugangsdaten, niemals das Geheimnis selbst
- Die erlaubten Anfrage- und Antwortfelder und das Ergebnisschema
- Zustandsabhängigkeiten und Revisionsprüfungen
- Wann die Aktion PERMIT, HOLD oder BLOCK erhält und was einen HOLD auflöst
- Anzahlgrenzen, Wertgrenzen in exakten Währungseinheiten, Evidenzaktualität und Aufgabenlaufzeit
- Wie das Ergebnis verifiziert wird und ob die Aktion rückgängig gemacht werden kann
Sechs Aktionsarten
| Wirkungsklasse | Was sie steuert |
|---|---|
| READ | Kontoinformationen oder ein begrenztes Abfrageergebnis abrufen |
| WRITE | Einen deklarierten Datensatz oder eine Ressource ändern |
| EGRESS | Eine Nachricht oder Informationen an ein genehmigtes Ziel senden |
| ACCOUNT_MUTATION | Kunden- oder Kontozustand ändern |
| FINANCIAL | Eine von Ihnen deklarierte Geldoperation in exakten Währungseinheiten |
| EXPORT_SHARE | Deklarierte Informationen exportieren oder teilen |
Dies sind Aktionskategorien, kein Katalog vorgefertigter Integrationen. Jede geschützte Aktion benötigt einen Konnektor zur ausführenden API.
Drei Entscheidungen. Jede hat eine bestimmte Bedeutung.
| Entscheidung | Was sie bedeutet | Was geschieht |
|---|---|---|
| PERMIT | Die Aktion erfüllt jede Bedingung ihres Vertrags. | Eine einmal verwendbare Erlaubnis lässt den Konnektor genau diese Aktion ausführen. Ausführung und Verifizierung werden getrennt aufgezeichnet. |
| HOLD | Eine Genehmigung, eine Tatsache oder ein Beleg benötigt noch eine autorisierte Klärung. | Nichts wird ausgeführt. Ein autorisierter Betreiber prüft und löst den HOLD auf, und Phalanx prüft die Bedingungen erneut. |
| BLOCK | Die Aktion liegt außerhalb der Autorität der Aufgabe oder Ihrer Regeln. | Es wird keine Erlaubnis erteilt. Der Konnektor erhält die Anfrage nicht. |
HOLD ist ein echter Workflow-Zustand, kein Prompt zur Selbstgenehmigung des Chatbots. Weder der Agent noch der Aufrufer, der die Aktion vorgeschlagen hat, kann ihn auflösen.
Ihre Anwendung entscheidet, wie die jeweilige Entscheidung Ihren Benutzern angezeigt wird. Phalanx liefert maschinenlesbare Ergebnisse, Kennungen und Belegreferenzen; die Formulierung bestimmen Sie.
Ein guter Plan ist keine Erlaubnis.
Eine Erlaubnis ist an eine Aktion gebunden: die signierte Konfiguration, die Ressource, die genaue Operation und den zugrunde liegenden Zustand. Sie funktioniert einmal. Der Konnektor prüft diese Bedingungen unmittelbar vor der Verwendung der Zugangsdaten erneut.
Konnektorrouten sind in der Konfiguration festgelegt. Der Agent kann über seine Argumente keine neue URL, keinen Header, keine Zugangsdaten, kein Protokoll und keine Wiederholungsrichtlinie vorgeben.
Ist eine Route unbekannt, deaktiviert, unpassend, veraltet oder mehrdeutig, stoppt die Aktion. Sind Phalanx oder eine Evidenzquelle nicht verfügbar, gibt es keinen Rückfall auf einen direkten Executor.
Kontrollieren Sie, was der Agent sehen kann, nicht nur, was er ändern kann.
Sensible Lesezugriffe laufen durch dasselbe Gateway. Geschützte Daten werden erst freigegeben, nachdem der erlaubte Lesezugriff ausgeführt wurde und sein Ergebnis dem deklarierten Schema entspricht. Ein angehaltener, blockierter oder fehlgeschlagener Lesezugriff liefert keine geschützten Daten. Begrenzte Listen- und Suchabfragen mit deklarierten Filtern und einer festen Route werden ebenfalls unterstützt.
Eine Aufgabe, ein Budget, über alle beteiligten Tools hinweg.
Ohne gemeinsames Budget setzt jedes Tool seine eigene Grenze durch. Ein Agent, der eine Aufgabe auf drei Tools verteilt, erhält dann drei Kontingente. In einem konfigurierten gemeinsamen Workflow greifen beteiligte Tools auf ein Aufgabenbudget zu. Phalanx zeichnet die Nutzung im gesamten Workflow auf und berücksichtigt den Rest bei jeder späteren Aktion.
Ein Workflow kann begrenzen
- Die Gesamtzahl der Aktionen
- Die Zahl der Aktionen je Integration
- Geld in einer exakten Währung und Einheit
- Die Menge offengelegter Informationen
- Die Laufzeit der Aufgabe, gebunden an einen Benutzer und eine Sitzung
Budgets sind dauerhaft, daher setzen Wiederholungen und Neustarts die aufgezeichnete Nutzung nicht zurück. Ein Workflow gruppiert 2 bis 32 Integrationen und wird ausdrücklich aktiviert. Nicht gruppierte Tools behalten ihre unabhängigen Grenzen.
Lassen Sie Ihre eigenen Daten bestimmen, wie viel der Agent tun darf.
Das Aufgabenmaximum ist eine Obergrenze, kein Anspruch. Mit Evidence Bridge kann ein Vertrag ein maßgebliches Feld Ihres Systems verlangen, etwa einen dokumentierten Anspruch des Kunden, das den vom Agenten vorgeschlagenen Wert stützt. Dynamic Autonomy begrenzt die Autorität des Agenten anschließend auf das, was diese Evidenz trägt, niemals über Ihr festgelegtes Maximum hinaus.
Fehlende, veraltete, ungültige oder widersprüchliche Evidenz erweitert die Autorität niemals. Die Prüfungen sind deterministisch: Zahlen aus Ihrem System werden nach Ihren deklarierten Regeln verglichen. Es ist kein Modell beteiligt.
Geht eine Antwort verloren, rät Phalanx nicht.
Hat ein Konnektor eine Operation angenommen, deren Antwort aber nie ankam, wird die Aktion als UNCERTAIN markiert. Phalanx sendet sie nicht blind erneut. Zuerst wird das Ergebnis anhand der stabilen Operationsidentität abgeglichen. Ein erneuter Versuch derselben Operation wird als dieselbe Operation erkannt; eine Aktion mit anderen Argumenten wird neu bewertet.
Was „genau einmal“ bedeuten kann, hängt vom System am anderen Ende ab. Manche unterstützen Idempotenzschlüssel, manche sind transaktional, manche erlauben nur eine Zustellung höchstens einmal. Der Vertrag legt fest, was gilt, und Phalanx setzt es durch. Es verspricht kein Genau-einmal-Verhalten für ein System, das es nicht leisten kann.
Nachweise, die Sie verifizieren können, nicht nur lesbare Logs.
Jeder Beleg verknüpft eine Entscheidung mit ihrer Aufgabe, der Aktion, dem Ausführungsversuch und dem verifizierten Ergebnis. Belege sind signiert und bilden eine authentifizierte, geordnete Kette. Fehlende oder veränderte Nachweise sind dadurch erkennbar.
Die Verifizierung zeigt, was falsch ist, nicht nur, dass etwas falsch ist: ein fehlender Beleg, eine unvollständige oder beschädigte Kette oder eine nicht ausführbare Verifizierung.
| Status | Bedeutung |
|---|---|
| PERMITTED | Autorisiert. Abschluss noch nicht verifiziert. |
| EXECUTED | Die Wirkung wurde gemäß dem Konnektorvertrag verifiziert. |
| HELD | Wartet auf autorisierte Klärung. Nichts wurde ausgeführt. |
| BLOCKED | Außerhalb der Autorität. Nichts wurde ausgeführt. |
| UNCERTAIN | Die vorhandene Evidenz kann nicht feststellen, was geschehen ist. Ein Abgleich ist erforderlich. |
Belege sind manipulationsnachweisende Evidenz über den kontrollierten Ausführungspfad. Sie sind keine Compliance-Zertifizierung und beweisen keine Tatsachen außerhalb dieses Pfads.
Läuft in Ihrer Infrastruktur, neben den Zugangsdaten, die es schützt.
Üblich sind ein Phalanx-Dienst und persistenter Speicher. Fügen Sie ein geschütztes Backend nur hinzu, wenn Ihr Agentenprozess heute Geschäftszugangsdaten besitzt; das ist eine Grenze, nicht ein Dienst je Tool. Autorisierungsentscheidungen fallen in Ihrer Bereitstellung. Invarras Kontrollebene verwaltet Ihre Identität, Lizenz und signierten Releases.
| In 1.9 qualifiziert | |
|---|---|
| Selbst verwaltet | Linux (amd64) mit Docker oder Docker Compose |
| Auf Render verwaltet | Ein privater Render-Dienst in Ihrem Konto mit einem schreibenden Prozess und persistentem Datenträger |
| Verwaltung | Die signierte Phalanx-CLI auf Linux (amd64) |
| Ihre Anwendung | HTTP/JSON oder das TypeScript-SDK |
| Speicher | Persistenter Speicher in Ihrem Besitz |
Zwei Fragen entscheiden, ob Phalanx eine Aktion schützen kann.
Kann die Aktion durch das Phalanx-Gateway, das SDK oder seinen Tool-Dispatch-Adapter geleitet werden?
Können ihre tatsächlichen Zugangsdaten hinter einem geschützten Konnektor liegen, während jeder gleichwertige direkte Weg entfernt wird?
Bei zweimal ja kann sie geschützt werden. Bei einem nein muss sich zuerst die Architektur ändern. Ihr Modellanbieter und Ihre Cloud entscheiden es nicht; der Ausführungsweg entscheidet.
Für Betrieb, Aktualisierung und Wiederherstellung gebaut.
Verwaltung über CLI und API
Eine signierte CLI und eine authentifizierte Admin-API decken Einbindung, Vertragsprüfung und Aktivierung, HOLD-Auflösung, Verwaltung von Zugangsdaten und Aufrufern sowie Belegverifizierung ab.
Bereit bedeutet bereit
Bereitschaft bedeutet geladene, nutzbare Autorität, nicht nur einen laufenden Container. Eine ungültige oder teilweise geladene Konfiguration blockiert geschützte Aktionen bis zur Behebung.
Verschlüsselte Sicherung und verifizierte Wiederherstellung
Vollständige Zustandssicherungen werden für einen Schlüssel verschlüsselt, den nur Sie besitzen. Wiederherstellungen werden anhand von Identität und Historie geprüft; unsichere veraltete Snapshots werden abgelehnt.
Aktualisierungen, die die Historie erhalten
Aktualisierungen erhalten Schlüssel, Belege, Budgets und ungeklärte Operationen. Ein Rollback stellt den passenden Zustand und das passende signierte Image gemeinsam wieder her.
Die Wiederherstellung stellt Phalanx’ eigenen Zustand wieder her. Sie kann bereits abgeschlossene Aktionen in externen Systemen nicht rückgängig machen.
Was Sie erhalten und was Phalanx nicht tut.
In Release 1.9 enthalten
- Signiertes Runtime-Image für Linux (amd64)
- Signierte Kunden-CLI zur Verwaltung
- TypeScript-SDK @invarra/phalanx mit Vorschlagsclients und Tool-Dispatch-Adaptern
- Versionierte JSON-Schemas für Integrationen, Vorschläge, Workflows, Evidenz und Ergebnisse
- Beispielkonfigurationen als Ausgangspunkte, niemals als Standardgenehmigungen
- Bereitstellungsmaterial für Linux/Docker und Render
- Integrations-, Bereitstellungs- und Wiederherstellungsdokumentation, eine Software-Stückliste und Hinweise zu Drittanbietern
Wofür Phalanx nicht gedacht ist
- Beurteilen, ob die Sätze Ihres Chatbots wahr sind. Phalanx steuert Aktionen.
- Richtlinien lernen. Entscheidungen folgen Ihren deklarierten Regeln auf Grundlage deklarierter Tatsachen.
- Eine Aktion schützen, die der Agent noch anders ausführen kann. Andere Zugangsdaten und direkte Routen müssen geschlossen werden.
- Sich in eine Anwendung einklinken, deren Tool-Ausführung Sie nicht ändern können.
- Als von Invarra betriebener Dienst laufen. Sie betreiben ihn.
- Compliance zertifizieren. Nachweise sind Evidenz, keine Zertifizierung.
Die ersten Fragen von Entwicklern
Was unterscheidet dies von einem Guardrail oder einem API-Schlüssel mit begrenztem Umfang?
Diese Kontrollen prüfen, was der Agent sagt oder welche Tools er aufrufen darf. Phalanx entscheidet, ob eine bestimmte Aktion ausgeführt wird, und der Agent besitzt niemals die Zugangsdaten, um ohne Phalanx zu handeln. Die Startseite vergleicht sie direkt. Vergleichen
Funktioniert Phalanx mit meinem Modellanbieter?
Ja. Phalanx steuert die vom Agenten vorgeschlagenen Tool-Aufrufe, nicht das Modell. Sie wählen, betreiben und bezahlen Ihr Modell separat.
Verwendet Phalanx KI für seine Entscheidungen?
Nein. Entscheidungen sind deterministisch: Ihre Verträge werden auf deklarierten Zustand und deklarierte Evidenz angewendet. Die Runtime verwendet CPUs und benötigt weder ein Phalanx-trainiertes Modell noch eine GPU.
Welche Integrationen werden unterstützt?
HTTP/JSON-Konnektoren zu Ihren eigenen APIs, das TypeScript-SDK und generische Tool-Dispatch-Adapter. Phalanx liefert keine anbieterspezifischen Konnektoren; Sie richten einen Konnektor auf die API, die die Aktion ausführt.
Funktioniert es mit MCP?
Der unterstützte Integrationspfad in 1.9 ist HTTP/JSON und das TypeScript-SDK. Beschreiben Sie uns Ihr MCP-Setup; wir nennen einen MCP-Adapter erst unterstützt, wenn er qualifiziert wurde.
Was passiert, wenn Phalanx nicht verfügbar ist?
Geschützte Aktionen stoppen. Es gibt keinen Rückfall auf einen direkten Weg am Gateway vorbei.
Gibt es eine Oberfläche zum Schreiben von Verträgen?
Die Oberfläche Phalanx contracts befindet sich im Invarra-Kundenportal. Geführte Formulare werden das Erstellen, Bearbeiten, Validieren und Versionieren von Aktionsverträgen, Grenzen für gemeinsame Workflows und unterstützten Evidenzeinstellungen ermöglichen. Sie werden eine verständliche Zusammenfassung prüfen, genehmigen und eine schemakonforme Konfiguration herunterladen können.
Wie wird Phalanx lizenziert?
Ihre Lizenz legt Release-Kanal, Umgebungen und Zahl der Bereitstellungen fest. Kontaktieren Sie uns für Preise.
Bringen Sie eine Aktion mit. Wir zeigen, wie Phalanx sie steuern würde.
Sagen Sie uns, was der Agent tun soll, welches System er betrifft und welche Grenze wichtig ist. Wir sagen Ihnen klar, ob Ihre Architektur passt und was eine Evaluierung nachweisen sollte.