Capítulo 18 — Arquitectura de seguridad
Mapa de la lección
Lección 18 publicada. Mapa, ejemplo, EX052.
flowchart TD
N0["Resultados de aprendizaje"]
N1["18.1 Principios"]
N2["18.2 Fronteras de confianza"]
N3["18.3 Una arquitectura de referencia para agentes"]
N4["18.4 Registros de decisiones de arquitectura"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX052"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["18.1 Principios"]
N2["18.2 Fronteras de confianza"]
N3["18.3 Una arquitectura de referencia para agentes"]
N4["18.4 Registros de decisiones de arquitectura"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX052"]
[Resultados de aprendizaje]
|
v
[18.1 Principios]
|
v
[18.2 Fronteras de confianza]
|
v
[18.3 Una arquitectura de referencia para agentes]
|
v
[18.4 Registros de decisiones de arquitectura]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX052]
Resultados de aprendizaje
Usted será capaz de (1) aplicar los principios de arquitectura (mínimo privilegio, separación de funciones, mediación completa, valores predeterminados a prueba de fallos, defensa en profundidad) a los sistemas de IA; (2) definir fronteras de confianza para modelos, datos y herramientas; (3) diseñar una arquitectura de referencia para un agente basado en LLM; y (4) documentar las decisiones de arquitectura con sus amenazas y su riesgo residual.
18.1 Principios
Los principios clásicos de Saltzer y Schroeder siguen vigentes. Mínimo privilegio: el modelo y sus herramientas reciben solo los permisos necesarios. Mediación completa: un punto de política comprueba cada acción, todas las veces. Valores predeterminados a prueba de fallos: denegar salvo que se permita explícitamente. Separación de funciones: el componente que propone una acción no es el que la aprueba. Economía del mecanismo: mantener la política lo bastante pequeña para poder revisarla. Estos principios son anteriores al aprendizaje automático, lo cual es útil: dan a los revisores una lista de comprobación que no depende de cómo se comporte el modelo. Un modelo puede ser manipulado, pero un punto de política que comprueba cada acción se sigue aplicando sea lo que sea lo que se haya persuadido al modelo para proponer.
18.2 Fronteras de confianza
Una frontera de confianza es el punto en que los datos o el control pasan entre partes con distinto nivel de confianza. En las aplicaciones basadas en LLM, la frontera crítica pasa por dentro del prompt: instrucciones del sistema (confiables), entrada del usuario (parcialmente confiable), contenido recuperado o devuelto por herramientas (no confiable). Como el modelo no puede imponer esta frontera de forma fiable, la arquitectura debe imponer las consecuencias fuera del modelo. El modelo ve los tres tipos de texto como una única secuencia de tokens. Los delimitadores y las instrucciones le ayudan a separarlos, pero un boletín escrito con cuidado aún puede leerse como una instrucción. Imponer las consecuencias fuera significa que el servicio de política, las credenciales de las herramientas y la aprobación humana deciden lo que realmente ocurre, de modo que la confusión del modelo sobre de quién es el texto que lee no puede causar daño por sí sola.
18.3 Una arquitectura de referencia para agentes
Componentes: (1) un servicio de ingesta que etiqueta la procedencia; (2) el modelo, que propone acciones; (3) un punto de decisión de política que comprueba cada propuesta frente a la identidad, el alcance y las reglas; (4) adaptadores de herramientas con credenciales estrechas; (5) aprobación humana para las acciones de alto impacto; (6) registro y monitorización. La investigación sobre consultas estructuradas (Chen et al., arXiv:2402.06363) mejora la separación que hace el propio modelo entre instrucciones y datos, pero no sustituye al punto de política externo. OWASP LLM06 (agencia excesiva) advierte contra el exceso de funcionalidad, de permisos y de autonomía. Cada componente corresponde a un principio: el punto de política aporta la mediación completa, las credenciales estrechas el mínimo privilegio, y la aprobación humana separa la propuesta de la aprobación.
18.4 Registros de decisiones de arquitectura
Registre cada decisión importante: contexto, opciones consideradas, decisión, consecuencias, amenazas abordadas y riesgo residual. Así, los revisores y los futuros ingenieros pueden ver por qué existe un control. Sin un registro, un control que parece incómodo puede eliminarlo alguien que no conoce el ataque que evita. Los registros son breves, normalmente de una página, y se guardan con el código para que cambien mediante la misma revisión. Cuando cambian las condiciones, como una herramienta nueva o una amenaza nueva, el registro se revisa y otro nuevo lo sustituye, conservando la historia. El riesgo residual es el campo que más a menudo se deja en blanco y el que más necesitan los revisores.
18.5 Ejemplo resuelto (caso sintético de NRS)
Sam redactó el ADR-007: «Creación de órdenes de trabajo en Wrench». Opciones: (a) el modelo llama directamente a la API; (b) el modelo propone, la política comprueba y el técnico confirma; (c) sin herramienta: el modelo redacta un texto que el técnico copia. Decisión: (b). Consecuencias: un clic más para los técnicos; las instrucciones inyectadas no pueden crear órdenes sin una persona. Riesgo residual: los técnicos pueden aprobar sin leer, lo que se mitiga mostrando el documento de origen de cualquier texto que parezca una instrucción.
La opción (c) era la más segura, pero renunciaba a la ventaja de las órdenes estructuradas, mientras que la opción (a) ponía un modelo no confiable al mando directo de un sistema privilegiado. El registro muestra por qué (b) se sitúa entre ambas.
18.6 Errores y límites
- Confiar en que el modelo imponga las fronteras de su prompt.
- Herramientas con credenciales amplias «por comodidad».
- Decisiones sin riesgo residual registrado.
Una frontera impuesta solo mediante instrucciones en el prompt aguanta hasta que una entrada ingeniosa la rompe. Las credenciales amplias convierten una sola llamada manipulada en acceso a todo lo que alcanza la credencial. Las decisiones registradas sin riesgo residual dan la impresión de que un problema está resuelto cuando solo se ha reducido. La revisión de arquitectura de Sam pregunta, para cada diseño: dónde se impone la frontera en el código, qué puede hacer la credencial de cada herramienta y qué riesgo queda.
Ejercicios — capítulo 18
- EX052 — Principios. Aplique tres principios a la cadena de alertas de TrackEye. Rúbrica: 3 = tres principios aplicados de forma concreta; 2 = dos; 1 = solo nombrados; 0 = nada.
- EX053 — Frontera. ¿Dónde está la frontera de confianza dentro del prompt de Wrench, y por qué el modelo no puede imponerla de forma fiable? Rúbrica: 3 = entre sistema/usuario y el contenido recuperado; una única secuencia de tokens, comportamiento estadístico; 2 = parcial; 1 = vago; 0 = incorrecto.
- EX054 — ADR. Redacte un ADR breve para añadir una herramienta de correo electrónico a Wrench. Rúbrica: 3 = contexto, opciones, decisión, consecuencias, riesgo residual; 2 = cuatro; 1 = dos; 0 = nada.
Síntesis del capítulo
La arquitectura es donde la seguridad de la IA se vuelve exigible: las fronteras de confianza, un punto de política externo, las herramientas con mínimo privilegio y las decisiones documentadas convierten la incertidumbre del modelo en un riesgo acotado.
Siga estudiando — capítulo 18 de 50
← Capítulo 17 (borrador) · Índice de capítulos del curso · Capítulo 19 (borrador) →