Evaluar Phalanx
Siga la acción hasta su resultado.
Para juzgar un sistema de control de ejecución, siga una acción de principio a fin: qué propuso el agente, qué autoridad tenía, qué decidió la pasarela y qué ocurrió realmente. Phalanx registra cada etapa para que pueda examinarse el límite, no solo describirse.
Cinco preguntas para una evaluación útil.
| Pregunta | Qué inspeccionar |
|---|---|
| ¿Quién autorizó la tarea? | El actor autenticado, el alcance de la tarea, las acciones permitidas y los límites aportados por la aplicación del cliente. |
| ¿Qué acción se propuso? | La herramienta, el objetivo, el destino, los argumentos y el estado relevante del sistema exactos. |
| ¿Por qué continuó o se detuvo? | La decisión PERMIT, HOLD o BLOCK registrada y la política aplicable o condición sin resolver. |
| ¿Podía ejecutarse de otra manera? | El aislamiento de credenciales y si otra ruta puede realizar la misma acción sin Phalanx. |
| ¿Qué ocurrió después? | El resultado del conector, el resultado de la verificación y cualquier incertidumbre o finalización parcial, según lo registrado en el recibo. |
Pruebe el trabajo útil y las condiciones que deben detenerlo.
Una evaluación útil incluye acciones autorizadas habituales y los límites que las rodean. Son preguntas de evaluación, no tasas de éxito publicadas.
| Escenario | Observación requerida |
|---|---|
| Una acción permitida con estado válido | Puede continuar por la ruta protegida y su resultado queda registrado. |
| Una acción fuera del alcance de recursos o destinos de la tarea | No recibe permiso de ejecución. |
| Se ha consumido un límite de acción o de flujo de trabajo compartido | El uso registrado sigue formando parte de la decisión en llamadas posteriores. Las herramientas participantes en un flujo de trabajo compartido configurado utilizan el mismo presupuesto de tarea. |
| Se requiere aprobación | La acción permanece retenida hasta la resolución autorizada requerida y una nueva evaluación. |
| El estado inscrito requerido falta o no está disponible | La acción se detiene de forma segura según su contrato inscrito, sin recurrir silenciosamente a una alternativa permisiva. |
| El estado cambia antes de la ejecución | Las comprobaciones requeridas en el momento de ejecución detectan el cambio relevante y aplican el contrato. |
| Se repite un permiso o una operación | La prueba distingue entre el rechazo de reutilización de un permiso, la idempotencia del conector y la gestión de resultados inciertos. |
| Un sistema externo agota el tiempo de espera | El resultado se registra como conocido o incierto según la evidencia de verificación; un tiempo de espera agotado no se informa como éxito. |
| La conversación nombra a otro cliente | Phalanx usa la identidad que firmó su aplicación. Un identificador de cliente escrito en el chat no puede cambiar qué recurso toca la acción. |
Qué probamos antes de lanzar Phalanx 1.9.
La versión de producción 1.9.0 se aprobó el 28 de septiembre de 2026 para Linux/Docker y Render, tras cuatro controles de lanzamiento: especificar, implementar, cualificar los artefactos firmados y entregar la compilación exacta aceptada.
| Prueba | Resultado |
|---|---|
| Conjunto de pruebas de código y seguridad | 2.169 casos aprobados, además de comprobaciones de esquemas y compilación y pruebas del SDK |
| Pruebas de límites en la versión instalada | 32 casos que cubren cadenas de recibos, activación duradera y operaciones de flujos de trabajo, ejecución incierta de conectores y copia de seguridad y recuperación |
| Actualización y reversión | Actualización desde un estado 1.5.1 conservado y reversión a la imagen anterior correspondiente, con claves e historial de recibos intactos |
| Ensayo de estado con varias herramientas | 17 integraciones en un flujo de trabajo compartido, con 212 recibos existentes y claves sin cambios |
| Verificación de recibos a escala | Recibos más antiguos, intermedios y más recientes verificados en una cadena de 99.990 recibos con un millón de eventos autenticados, dentro de la ventana de verificación de 120 segundos, con 0,5 CPU y 512 MB |
| Entrega en producción | CLI de cliente actualizada y descargada de producción; demo de Meridian actualizada en su entorno con las 17 integraciones reactivadas y una lectura protegida vinculada a un recibo servida a través de su chatbot |
Estos son resultados de ingeniería de lanzamiento, no una tasa de bloqueo de ataques ni de éxito para todos los despliegues. Los fallos se inyectaron en pruebas aisladas de la versión instalada, no contra la demo pública. Cada despliegue de cliente se cualifica en sus propias rutas.
Mantenga el resultado vinculado al sistema que lo produjo.
Un resultado útil identifica la versión de Phalanx, el flujo de trabajo protegido, el conector, la configuración de autoridad y políticas, las condiciones de prueba y el resultado observado. La cualificación del cliente también comprueba la infraestructura y las rutas que hacen aplicable el límite.
Meridian, la demo pública, es una empresa sintética operada por Invarra. Su introducción enumera los controles activos de Phalanx. Una evaluación de cliente establece la cobertura del flujo de trabajo que se despliega realmente.
Investigación anterior.
Antes de convertirse en una pasarela de ejecución, Phalanx examinaba chats escritos para detectar jailbreaks e inyecciones de prompts. Esos resultados corresponden a aquel entorno anterior y a contratos de prueba distintos. Se conservan como registro histórico y no son resultados de rendimiento de Phalanx 1.9.
Defina cómo debe ser el éxito en su entorno.
Empiece con una acción que debe funcionar, un límite que debe mantenerse y un resultado que necesita verificar. Definiremos una evaluación alrededor de esos tres elementos.