Phalanx evaluieren
Verfolgen Sie die Aktion bis zu ihrem Ergebnis.
Um ein Ausführungskontrollsystem zu beurteilen, verfolgen Sie eine Aktion vollständig: was der Agent vorschlug, welche Autorität er hatte, was das Gateway entschied und was tatsächlich geschah. Phalanx zeichnet jede Phase auf, damit die Grenze geprüft und nicht nur beschrieben werden kann.
Fünf Fragen für eine aussagekräftige Evaluierung.
| Frage | Was zu prüfen ist |
|---|---|
| Wer hat die Aufgabe autorisiert? | Authentifizierter Akteur, Aufgabenumfang, erlaubte Aktionen und von der Kundenanwendung bereitgestellte Grenzen. |
| Welche Aktion wurde vorgeschlagen? | Genaues Tool, Zielobjekt, Zieladresse, Argumente und relevanter Systemzustand. |
| Warum wurde sie fortgesetzt oder gestoppt? | Die aufgezeichnete PERMIT-, HOLD- oder BLOCK-Entscheidung und die geltende Richtlinie oder ungeklärte Bedingung. |
| Konnte sie anders ausgeführt werden? | Trennung der Zugangsdaten und die Frage, ob ein anderer Weg dieselbe Aktion ohne Phalanx ausführen kann. |
| Was geschah danach? | Konnektorergebnis, Verifizierungsergebnis und jede Ungewissheit oder teilweise Fertigstellung, wie im Beleg aufgezeichnet. |
Prüfen Sie nützliche Arbeit und die Bedingungen, die sie stoppen sollten.
Eine nützliche Evaluierung umfasst gewöhnliche autorisierte Aktionen und deren Grenzen. Dies sind Evaluierungsfragen, keine veröffentlichten Erfolgsquoten.
| Szenario | Erforderliche Beobachtung |
|---|---|
| Eine erlaubte Aktion mit gültigem Zustand | Sie kann über den geschützten Weg ausgeführt werden; ihr Ergebnis wird aufgezeichnet. |
| Eine Aktion außerhalb der Ressourcen- oder Zielgrenzen der Aufgabe | Sie erhält keine Ausführungserlaubnis. |
| Eine Aktions- oder gemeinsame Workflow-Grenze wurde aufgebraucht | Die aufgezeichnete Nutzung bleibt Teil der Entscheidung für spätere Aufrufe. Beteiligte Tools in einem konfigurierten gemeinsamen Workflow greifen auf dasselbe Aufgabenbudget zu. |
| Eine Genehmigung ist erforderlich | Die Aktion bleibt angehalten bis zur erforderlichen autorisierten Klärung und erneuten Bewertung. |
| Der erforderliche eingebundene Zustand fehlt oder ist nicht verfügbar | Die Aktion wird gemäß ihrem eingebundenen Vertrag gesperrt, ohne stillen Rückfall auf eine permissive Alternative. |
| Der Zustand ändert sich vor der Ausführung | Die erforderlichen Prüfungen zur Ausführungszeit erkennen die relevante Änderung und wenden den Vertrag an. |
| Eine Erlaubnis oder Operation wird wiederholt | Der Test unterscheidet abgelehnte Wiederverwendung einer Erlaubnis, Konnektoridempotenz und den Umgang mit ungewissen Ergebnissen. |
| Ein externes System meldet eine Zeitüberschreitung | Das Ergebnis wird anhand der Verifizierungsevidenz als bekannt oder ungewiss aufgezeichnet; eine Zeitüberschreitung wird nicht als Erfolg gemeldet. |
| Im Gespräch wird ein anderer Kunde genannt | Phalanx verwendet die von Ihrer Anwendung signierte Identität. Eine im Chat eingegebene Kunden-ID kann die betroffene Ressource nicht ändern. |
Was wir vor der Veröffentlichung von Phalanx 1.9 getestet haben.
Produktionsrelease 1.9.0 wurde am 28. September 2026 für Linux/Docker und Render nach vier Release-Prüfungen freigegeben: spezifizieren, implementieren, signierte Artefakte qualifizieren und den exakt akzeptierten Build ausliefern.
| Test | Ergebnis |
|---|---|
| Quellcode- und Sicherheitstests | 2.169 bestandene Fälle sowie Schemaprüfungen und SDK-Build und Tests |
| Grenztests auf dem installierten Release | 32 Fälle zu Belegketten, dauerhafter Aktivierung und Workflow-Operationen, ungewisser Konnektorausführung sowie Sicherung und Wiederherstellung |
| Upgrade und Rollback | Upgrade aus erhaltenem 1.5.1-Zustand und Rollback auf das passende frühere Image, mit unveränderten Schlüsseln und Beleghistorie |
| Zustandsprobe mit mehreren Tools | 17 Integrationen in einem gemeinsamen Workflow mit 212 vorhandenen Belegen und unveränderten Schlüsseln |
| Belegverifizierung in großem Umfang | Älteste, mittlere und neueste Belege in einer Kette mit 99.990 Belegen und einer Million authentifizierter Ereignisse innerhalb des 120-Sekunden-Verifizierungsfensters geprüft, bei 0,5 CPU und 512 MB |
| Produktionsauslieferung | Kunden-CLI aktualisiert und aus der Produktion heruntergeladen; Meridian-Demo vor Ort aktualisiert, alle 17 Integrationen reaktiviert und ein an einen Beleg gebundener geschützter Lesezugriff über ihren Chatbot bereitgestellt |
Dies sind Ergebnisse der Release-Entwicklung, keine Angriffsblockierquote oder Erfolgsquote für jede Bereitstellung. Fehlerfälle wurden in isolierten Tests des installierten Releases eingebracht, nicht gegen die öffentliche Demo ausgeführt. Jede Kundenbereitstellung wird auf ihren eigenen Routen qualifiziert.
Halten Sie das Ergebnis mit dem erzeugenden System verbunden.
Ein aussagekräftiges Ergebnis nennt Phalanx-Release, geschützten Workflow, Konnektor, Autoritäts- und Richtlinienkonfiguration, Testbedingungen und beobachtetes Ergebnis. Die Kundenqualifizierung prüft auch Infrastruktur und Routen, die die Grenze durchsetzbar machen.
Meridian, die öffentliche Demo, ist ein synthetisches Unternehmen, das Invarra betreibt. Ihre Einführung nennt die aktiven Phalanx-Kontrollen. Eine Kundenevaluierung bestimmt die Abdeckung für den tatsächlich bereitgestellten Workflow.
Frühere Forschung.
Bevor Phalanx zu einem Ausführungsgateway wurde, prüfte es geschriebene Chats auf Jailbreaks und Prompt-Injection. Diese Ergebnisse betreffen die frühere Runtime und andere Testverträge. Sie bleiben als historische Aufzeichnung erhalten und sind keine Leistungswerte für Phalanx 1.9.
Bestimmen Sie, wie Erfolg in Ihrer Umgebung aussehen muss.
Beginnen Sie mit einer Aktion, die funktionieren soll, einer Grenze, die halten muss, und einem Ergebnis, das Sie verifizieren müssen. Wir richten die Evaluierung an diesen drei Punkten aus.