Mapa de la lección
Lección 19 publicada. Mapa, ejemplo, EX055.
flowchart TD
N0["Resultados de aprendizaje"]
N1["19.1 Identidades para los agentes"]
N2["19.2 Hashes y manifiestos"]
N3["19.3 Firmas y procedencia"]
N4["19.4 Cifrado"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX055"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["19.1 Identidades para los agentes"]
N2["19.2 Hashes y manifiestos"]
N3["19.3 Firmas y procedencia"]
N4["19.4 Cifrado"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX055"]
[Resultados de aprendizaje]
|
v
[19.1 Identidades para los agentes]
|
v
[19.2 Hashes y manifiestos]
|
v
[19.3 Firmas y procedencia]
|
v
[19.4 Cifrado]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX055]
Resultados de aprendizaje
Usted será capaz de (1) diseñar la identidad y el acceso para usuarios, servicios y agentes de IA; (2) aplicar hashes, firmas y cifrado a los artefactos de IA; (3) verificar la integridad de modelos y conjuntos de datos con manifiestos; y (4) explicar la procedencia y la firma en la cadena de suministro de la IA.
19.1 Identidades para los agentes
Toda acción debe poder atribuirse. Un agente de IA debe actuar en nombre de un usuario, con permisos delegados y de alcance limitado (por ejemplo, tokens OAuth restringidos a ámbitos concretos), y no con una cuenta de servicio poderosa. Las credenciales de corta duración limitan el daño si se filtran; nunca coloque credenciales en los prompts. La delegación significa que el agente nunca puede hacer más de lo que podría hacer el usuario, y los registros muestran a ambos: el usuario en cuyo nombre se ejecutó la acción y el agente que la propuso. Una cuenta de servicio compartida borra esa distinción, de modo que, tras un incidente, nadie puede saber qué conversación causó qué acción. Los tokens que duran minutos en lugar de meses hacen además que una credencial copiada de un registro sea inútil para cuando alguien intente usarla.
19.2 Hashes y manifiestos
Un hash criptográfico como SHA-256 asigna a un archivo un resumen de tamaño fijo; cualquier cambio, aunque sea de un solo bit, produce un resumen distinto. Un manifiesto enumera el resumen esperado de cada artefacto (pesos, tokenizador, configuración). El laboratorio detecta tanto un cambio de un bit en los pesos como una línea añadida a la configuración.
"""Lab H: integrity of model artefacts with SHA-256 manifests (stdlib only).
Creates synthetic 'artefact' bytes, records a manifest, then detects a
one-byte tampering and a swapped file. No real models are involved."""
import hashlib, json
files = {"model.bin": bytes(range(256)) * 40, "tokenizer.json": b'{"vocab": ["a", "b"]}',
"config.yaml": b"layers: 4\nheads: 8\n"}
manifest = {n: hashlib.sha256(b).hexdigest() for n, b in files.items()}
print(json.dumps({k: v[:16] for k, v in manifest.items()}, indent=1))
received = dict(files)
tampered = bytearray(received["model.bin"]); tampered[5000] ^= 1
received["model.bin"] = bytes(tampered)
received["config.yaml"] = b"layers: 4\nheads: 8\ntrust_remote_code: true\n"
for n, b in sorted(received.items()):
ok = hashlib.sha256(b).hexdigest() == manifest[n]
print(f"{n:15s} {'OK' if ok else 'MISMATCH'}")
Salida esperada:
{
"model.bin": "e96760a87768717b",
"tokenizer.json": "f63d2ddabc61f2d9",
"config.yaml": "e5bbb570ca0fcb87"
}
config.yaml MISMATCH
model.bin MISMATCH
tokenizer.json OK
La salida muestra por qué cada archivo necesita su propia entrada: el tokenizador no se tocó y supera la comprobación, mientras que dos cambios distintos en dos archivos se detectan cada uno de forma independiente. Un solo bit invertido en el desplazamiento 5000 basta para cambiar por completo el resumen del archivo de pesos.
19.3 Firmas y procedencia
Un hash prueba que un archivo coincide con un manifiesto; una firma digital sobre el manifiesto prueba quién lo produjo. Firmar los artefactos del modelo y registrar su procedencia (qué datos, código y canalización los produjeron) permite a los consumidores verificar su origen. Esto aborda OWASP LLM03 (cadena de suministro) y los riesgos de puertas traseras en modelos de terceros (Gu et al., arXiv:1708.06733). Las firmas trasladan la cuestión de la confianza a la clave de firma: quién la tiene, cómo se protege y cómo sabe un consumidor qué clave esperar. La procedencia añade un contexto que una firma por sí sola no puede dar, como la versión del conjunto de datos usada, de modo que un consumidor puede juzgar si el modelo es adecuado para su uso y no solo si es auténtico.
19.4 Cifrado
Cifre los datos de entrenamiento y los pesos en reposo y todo el tráfico en tránsito (TLS). El cifrado protege la confidencialidad frente al robo del almacenamiento y la interceptación, pero no frente a una consulta de apariencia legítima que extraiga información del modelo. Las claves deben gestionarse por separado de los datos que protegen; un archivo de pesos cifrado guardado junto a su clave no protege nada. El cifrado tampoco altera el comportamiento del propio modelo. Un usuario con acceso ordinario de consulta puede seguir extrayendo datos de entrenamiento o reconstruir un modelo a través de sus respuestas, así que el cifrado se combina con límites de consultas y controles de las salidas. Los ingenieros registran qué amenazas aborda cada control de cifrado y cuáles no aborda explícitamente.
19.5 Ejemplo resuelto (caso sintético de NRS)
NRS recibe las actualizaciones del modelo de TrackEye de un proveedor de modelos de visión. Sam exigió un manifiesto firmado con resúmenes SHA-256 de cada archivo, verificado en el ordenador del tren de inspección antes de la carga. En una prueba, una configuración modificada que habilitaba la carga remota de código fue rechazada, en coincidencia con el config.yaml MISMATCH del laboratorio. Verificar en el tren y no en el depósito importa porque los archivos podrían alterarse en cualquier punto entre el proveedor y el dispositivo. Primero se comprueba la firma del manifiesto; los hashes de los archivos solo se consideran fiables una vez demostrado que la firma procede de la clave esperada del proveedor.
19.6 Errores y límites
- Agentes que usan cuentas de servicio de administración compartidas.
- Hashes obtenidos del mismo lugar que los archivos (un atacante puede cambiar ambos).
- Suponer que el cifrado impide las filtraciones a nivel del modelo.
Las cuentas de administración compartidas hacen que cada acción de un agente sea tan poderosa como la tarea más poderosa que necesite cualquier agente. Un hash descargado del mismo servidor que el archivo solo prueba que el servidor es coherente consigo mismo, así que el resumen esperado debe llegar por un canal separado y confiable, como un manifiesto firmado. El cifrado protege los datos en reposo y en tránsito, pero un modelo que responde a consultas aún puede revelar lo que aprendió.
Ejercicios — capítulo 19
- EX055 — Lectura del laboratorio. ¿Qué archivos fallan en el laboratorio H y por qué supera la comprobación
tokenizer.json? Rúbrica: 3 = model.bin (bit invertido) y config.yaml (línea añadida); el tokenizador no cambió; 2 = parcial; 1 = vago; 0 = incorrecto. - EX056 — Hashes de la misma fuente. ¿Por qué es débil un manifiesto descargado del mismo servidor que el modelo, y qué lo corrige? Rúbrica: 3 = un atacante que controla el servidor cambia ambos; manifiesto firmado con clave fijada; 2 = parcial; 1 = vago; 0 = incorrecto.
- EX057 — Delegación. Diseñe la credencial de la herramienta de órdenes de trabajo de Wrench. Rúbrica: 3 = delegada por usuario, limitada a crear borradores, de corta duración, registrada; 2 = tres; 1 = una; 0 = nada.
Síntesis del capítulo
La identidad hace que las acciones de los agentes sean atribuibles y acotadas; los hashes, las firmas y la procedencia hacen verificables los artefactos de IA. Juntos anclan la confianza en la cadena de suministro de la IA.
Siga estudiando — capítulo 19 de 50
← Capítulo 18 (borrador) · Índice de capítulos del curso · Capítulo 20 (borrador) →