El sector de la inteligencia artificial vive un amplio debate sobre los mecanismos de gobernanza y evaluación de modelos avanzados antes de su despliegue. Sin embargo, estas grandes discusiones a menudo ignoran el código real que decide si a un agente de IA se le permite ejecutar acciones sensibles, como enviar correos electrónicos, modificar claves de cifrado, fusionar ramas de software o transferir fondos. Esas decisiones no las toman los grandes laboratorios ni los textos regulatorios, sino funciones de programación simples que devuelven un valor verdadero o falso.
Las pruebas de estrés realizadas en un protocolo de código abierto para verificar las acciones de los agentes, llamado "PIC", demostraron que los problemas no surgen necesariamente de fallos en el cifrado, sino de la aceptación por parte del protocolo de formatos múltiples que son aparentemente correctos pero susceptibles de interpretaciones divergentes. Por ejemplo, el esquema estructural podría aceptar códigos hash con letras mayúsculas o minúsculas, mientras que el intérprete los procesa de maneras que conducen a resultados distintos entre un sistema y otro sin violar las especificaciones estándar declaradas.
Límites de los esquemas JSON en la validación de datos
Los esquemas JSON desempeñan un papel fundamental pero limitado en la validación de la estructura de datos; se aseguran de que los campos requeridos existan, que sus tipos de valor sean correctos y que se ajusten a las reglas generales. Sin embargo, el esquema es incapaz de imponer reglas relacionales complejas, como garantizar que una referencia específica a pruebas apunte a un único elemento dentro de una matriz de fuentes sin duplicación o ambigüedad.
Las diferencias en la implementación de operaciones de búsqueda o coincidencia de identificadores entre diferentes lenguajes de programación conducen a lo que se conoce como disparidad de analizadores, un tipo antiguo de vulnerabilidad de seguridad que apareció anteriormente en protocolos como HTTP y JWT, donde dos componentes leen las mismas entradas de dos maneras diferentes. En los protocolos de agentes modernos, estos matices conducen a la aceptación de acciones en un servicio determinado mientras otro servicio las rechaza, a pesar de utilizar la misma política y especificaciones.
Impacto de las operaciones de normalización en la seguridad del protocolo
Los desarrolladores suelen tender a normalizar las entradas para evitar el rechazo de datos recuperables, como eliminar espacios adicionales, convertir letras a minúsculas o corregir rellenos Base64. No obstante, estas prácticas representan un peligro real en los límites de la autenticación. Por ejemplo, si el intérprete normaliza el nombre de una herramienta o elimina espacios antes de compararlo con una lista de permitidos, el sistema podría ejecutar una acción que la parte firmante no aprobó, o manipular los permisos de ejecución sin el conocimiento de los desarrolladores.
Además, depender de los campos que el propio agente envía para confirmar la fiabilidad de su fuente abre la puerta al problema del diputado confuso en formato digital. La confianza debe derivarse exclusivamente dentro de los límites de la aplicación de la ley y la verificación, mediante la comprobación de firmas digitales y su correspondencia con claves cifradas en las que el operador confía directamente, independientemente de las afirmaciones contenidas en la carga útil de la solicitud.
Estructura de tres capas y vectores de coincidencia de ejecución
Para evitar estas vulnerabilidades, se requiere una arquitectura que separe claramente tres capas consecutivas:
- Validación de esquema: para rechazar estructuras corruptas y representaciones que no se ajustan a la red.
- Validación semántica: para resolver referencias, verificar asociaciones y derivar la confianza real.
- Evaluación de políticas: para tomar la decisión final sobre permitir o bloquear la ejecución de la acción.
No basta con las notas de documentación; se requieren herramientas de prueba de coincidencia de ejecución claras que incluyan entradas precisas, resultados esperados y códigos de error estables para manejar casos ambiguos. Estos vectores garantizan la unificación del comportamiento en todas las implementaciones y evitan que la seguridad dependa de configuraciones predeterminadas divergentes en los diferentes puentes de software.