Una auditoría que puede defender ante un regulador.
Un archivo de registro que cualquier persona con acceso de escritura puede editar silenciosamente no es evidencia. Es un registro de lo que el sistema decidió registrar. SectorFlow One trata el registro de auditoría como la parte de la plataforma con mayor probabilidad de ser examinada bajo juramento, por lo que cada entrada está tanto firmada como encadenada. Cada evento lleva un HMAC calculado sobre su contenido, lo que establece la atribución: la entrada fue producida por un proceso que poseía la clave de firma, no insertada a posteriori por alguien con credenciales de base de datos.
La firma responde al quién; el encadenamiento por hash responde al si se ha eliminado algo. Cada entrada incluye el hash de la entrada anterior, de modo que el registro forma una cadena en la que cada eslabón depende de todos los anteriores. Eliminar o modificar un evento histórico rompe el hash de cada entrada posterior, y la ruptura es detectable recalculando la cadena — no es necesario confiar en que nadie haya tocado la tabla, puede probarlo. Las claves de firma rotan automáticamente, y la propia rotación queda registrada en la cadena, por lo que una clave comprometida tiene un radio de impacto acotado y no ilimitado.
En tiempo de ejecución esto es invisible hasta que lo necesita. Un agente realiza una acción; la acción, sus entradas, la identidad que la autorizó y el modelo que la produjo quedan registrados en la cadena como un eslabón firmado. Cuando un auditor le pida demostrar que el registro está completo y sin modificaciones, ejecute la verificación y muestre los cálculos. Esa es una conversación sustancialmente distinta a «creemos que los registros son exactos».
Los flujos de aprobación como primitiva de primer nivel, no como notificación de Slack.
El patrón habitual de «supervisión humana» consiste en publicar un mensaje en un canal y dejar que el agente continúe. Eso no es una barrera de aprobación. Es una notificación sin ningún mecanismo de cumplimiento: la acción generalmente ya se ha ejecutado, nadie es responsable de la decisión y no hay constancia de quién aprobó qué ni si tenía autoridad para hacerlo. Un mensaje de Slack es la abstracción equivocada porque vive fuera del sistema que gestiona el permiso y el registro de auditoría.
En SectorFlow One, la aprobación con supervisión humana es un nodo dentro del propio flujo de trabajo de Studio. Cuando la ejecución alcanza un nodo HITL, se detiene — la acción privilegiada no se ejecuta — y espera la decisión de alguien que la plataforma reconoce como autorizado para tomarla. La aprobación, la identidad del aprobador, el payload que se le mostró y el resultado quedan registrados en la misma cadena de auditoría firmada que el resto. La barrera la impone el entorno de ejecución, no una convención que el equipo acuerda seguir.
Quién puede aprobar está regulado por un modelo de permisos de cuatro niveles que separa el derecho a desarrollar un agente, el derecho a aprobar sus acciones y el derecho a desplegarlo en producción. Son responsabilidades distintas, y condensarlas en un único rol de «administrador» es la manera en que los cambios no revisados llegan a los sistemas en producción. Mantenerlas separadas significa que un ingeniero puede crear un flujo de trabajo sin poder omitir sus pasos de alto riesgo, y que un aprobador puede validar una acción sin poder reescribir silenciosamente el agente que la produjo.
Permisos de herramientas acotados por agente y por acción.
Un modelo capaz con acceso a todas las herramientas es una responsabilidad sin límites. El riesgo no es que el agente sea malicioso; es que su espacio de acciones es mayor que su función. SectorFlow One reduce ese espacio con un contexto de agente que lleva un límite de permisos explícito — el conjunto de herramientas y acciones que un agente concreto tiene autorización para invocar. Un agente creado para leer tickets y redactar respuestas no puede acceder a una herramienta que elimina registros, porque esa herramienta nunca estuvo dentro de su límite, independientemente de lo que una instrucción en su ventana de contexto le indique que haga.
El límite se verifica en el momento de la invocación, no se asume en el momento del diseño. Antes de que se ejecute una llamada a herramienta, el GuardrailChecker la evalúa frente a los permisos del agente y la política vigente. Una llamada que queda fuera del límite es rechazada y registrada, en lugar de intentarse y corregirse después.
El comportamiento predeterminado importa tanto como la regla. El ReflectionAgent, que revisa las acciones propuestas antes de que se ejecuten, falla de forma cerrada: si no puede determinar que una acción es segura y está permitida, la acción no continúa. Los sistemas que fallan de forma abierta tratan la ambigüedad como permiso y descubren el coste en producción. Los sistemas que fallan de forma cerrada tratan la ambigüedad como motivo para detenerse y preguntar. Para un agente que actúa sobre sistemas reales, ese comportamiento predeterminado marca la diferencia entre un rechazo contenido y un incidente.
Aislamiento multiinquilino integrado en la capa de datos.
El aislamiento aplicado únicamente en el código de aplicación está a una cláusula WHERE olvidada de una fuga de datos entre inquilinos. SectorFlow One desplaza el límite hasta la seguridad a nivel de fila de PostgreSQL en las tablas con ámbito de inquilino, de modo que la propia base de datos rechaza devolver filas de otro inquilino. El inquilino activo se transporta en un GUC — un valor de configuración de sesión establecido por conexión — y las políticas RLS comparan el inquilino de cada fila con él.
Las políticas usan tanto una cláusula USING como una cláusula WITH CHECK, que es la parte que es fácil implementar incorrectamente. USING filtra qué filas puede leer o actualizar una consulta; WITH CHECK valida qué filas puede escribir una consulta. Sin esta última, un inquilino podría leer únicamente sus propios datos pero insertar o actualizar filas marcadas con el id de inquilino de otro. Aplicar ambas cierra la ruta de lectura y la de escritura. Las tablas también usan FORCE ROW LEVEL SECURITY, por lo que las políticas se aplican incluso al propietario de la tabla — la conexión privilegiada bajo la que se ejecutan sus migraciones y trabajos en segundo plano no obtiene una exención silenciosa.
Esto es mucho más difícil de añadir a posteriori que de diseñar desde el principio. Agregar RLS a un esquema que ha sido consultado sin él durante un año implica auditar cada consulta existente para detectar las suposiciones que realizó sobre la visibilidad, y cada una que se pase por alto es una brecha latente. Diseñar la multitenencia en la capa de datos desde el inicio significa que la garantía se mantiene incluso cuando el código de aplicación tiene un error — que, con el tiempo, lo tendrá.
Defensa en profundidad contra la inyección de prompts — más allá del filtrado de entrada.
La mayoría de las medidas de mitigación de la inyección de prompts se detienen en la entrada: analizan el texto entrante en busca de patrones de ataque conocidos y confían en que el filtro sea completo. Nunca lo es. Los payloads de inyección llegan a través de documentos recuperados, salidas de herramientas y contenido descendente que el usuario nunca escribió, y el espacio de formulaciones es ilimitado. El filtrado de entrada vale la pena hacerlo, pero tratarlo como la defensa completa es el error. SectorFlow One superpone controles para que vencer uno no signifique vencer al sistema.
La sanitización de entrada es la primera capa y la más débil, por lo que no se le pide que soporte toda la carga. El límite de permisos de herramientas es la capa que más importa: incluso si una instrucción inyectada consigue indicarle al agente que elimine un registro o extraiga datos, la herramienta necesaria para hacerlo no está dentro del límite del agente, y el GuardrailChecker rechaza la llamada. El ataque llega al modelo pero no puede llegar al sistema, porque la autoridad nunca fue delegada al texto de la ventana de contexto.
La validación de salida es la tercera capa: la acción propuesta por el agente se comprueba antes de ejecutarse, por lo que una respuesta moldeada por una inyección exitosa aún debe superar la misma barrera que cualquier otra acción. La cuarta capa es el propio registro de auditoría. Dado que cada acción está firmada y encadenada, el comportamiento anómalo — una serie repentina de llamadas a herramientas rechazadas, un agente que intenta acceder a capacidades que nunca antes había usado — es revisable a posteriori e imposible de borrar del registro. La defensa en profundidad asume que cualquier capa individual puede fallar, y garantiza que el fallo esté contenido y sea visible.