Trust Boundaries
Dónde cambian los supuestos de confianza
Una Trust Boundary es una frontera lógica donde cambian los supuestos sobre la procedencia, la autoridad, la integridad o el acceso permitido a datos y operaciones. Puede coincidir con una red o un proceso, pero también existir dentro de una aplicación. Su utilidad es hacer explícito qué se recibe, de quién y bajo qué condiciones se acepta.
El modelado de amenazas de OWASP utiliza flujos y fronteras para examinar el sistema antes de identificar amenazas. Un diagrama permite plantear preguntas; dibujar una línea no aplica un control.
Confianza para una finalidad
Un proveedor puede estar autorizado para entregar un documento sin estar autorizado para cambiar la política de ejecución. Un usuario puede consultar sus compras sin poder consultar las de otra persona. Un servicio interno puede autenticar correctamente y enviar datos que todavía requieren validación.
Por eso conviene preguntar «confiable para qué». La identidad del emisor, la exactitud de la información y su autoridad para ordenar una acción son propiedades diferentes. Una fuente autenticada puede contener un error o transportar contenido originalmente aportado por un tercero.
Las fronteras también tienen dirección. Permitir que una herramienta lea información no implica permitir que la publique. Permitir datos de un tenant hacia un proceso compartido no autoriza su retorno hacia cualquier otro tenant.
Qué cruza la frontera
Una revisión puede describir origen, destino, identidad, datos, operación solicitada y controles esperados. Después debe localizar dónde se comprueban esas condiciones. La validación de forma, la autorización del recurso y la protección de información sensible resuelven preguntas distintas.
Un JSON válido puede identificar un pedido que el caller no tiene derecho a modificar. Una firma puede demostrar procedencia sin demostrar que el contenido es inocuo. TLS puede proteger el transporte sin convertir el payload en una instrucción autorizada.
Los errores aparecen cuando una transformación borra el contexto necesario para decidir. Resumir una petición, delegarla o pasarla por un proxy puede perder el principal original, el tenant o el alcance aprobado. Confused Deputy examina una consecuencia de esa pérdida de autoridad situada.
Ejemplo: un documento dentro de un flujo AI
En Commerce, un asistente consulta un ticket para explicar un error de checkout. El texto del ticket aporta evidencia del problema. Si incluye una instrucción para cambiar credenciales o enviar datos a otro destino, esa frase sigue perteneciendo al material consultado.
El paso peligroso sería promover ese contenido a una orden con la autoridad del usuario o del servicio. Prompt Injection estudia esa interferencia en el contexto del modelo. La API que ejecuta una acción también necesita comprobar identidad y alcance, aunque el modelo describa el pedido como necesario.
La frontera existe entre dato y control, además de las fronteras de red o proceso. Etiquetar el ticket como externo ayuda a mantener su procedencia; no demuestra por sí solo que todo consumidor respete esa distinción.
Ejecución y salida
Agent Sandboxing restringe recursos y consecuencias en ejecución. No decide si un documento es una autoridad legítima. Least Privilege limita qué puede hacer una identidad aunque la decisión que produjo el intento sea incorrecta.
La salida del modelo introduce otra frontera cuando se convierte en HTML, una consulta o argumentos de una herramienta. Cumplir un schema no hace segura cualquier interpretación posterior. El destino debe aplicar sus reglas de uso y autorización; Tool Abuse y Data Leakage describen consecuencias diferentes de cruzarlas incorrectamente.
Revisar las garantías
Una prueba útil intenta una operación permitida y otra fuera del alcance con datos sintéticos. Debe observar el control que aceptó o rechazó, no solamente una explicación favorable del modelo. Cambiar una integración, una identidad o un canal puede requerir revisar nuevamente la frontera.
Las fronteras no eliminan toda confianza. Ayudan a limitarla y a exponer dependencias. Una arquitectura puede tener controles incompletos; documentar esa limitación permite evaluarla sin confundir la intención del diseño con una garantía ya comprobada.
Fuentes y alcance
La definición operativa y el ejemplo son síntesis del Atlas. Este documento no establece un método completo de threat modeling ni una taxonomía de productos de seguridad.