El Agente que te Observa: Seguridad para la Era Agéntica
Cuando un LLM responde a una pregunta, procesa tokens. Cuando un agente autónomo actúa, invoca tools, escribe en el filesystem, llama APIs, mueve dinero, reinicia servidores. La superficie de ataque ya no es la inyección de prompt — es la cadena de ejecución delegada.
1. El Problema no es el Modelo, es la Orquestación
La mayoría de las "arquitecturas agenticas" en producción hoy son un wrapper frágil: `while true: llm.plan() → executor.run()`. Dos defectos fatales:
- Ausencia de límites rígidos: El LLM decide qué hacer y cómo hacerlo en el mismo contexto. Una inyección de prompt bien elaborada redefine la política de seguridad en runtime.
- Estado implícito: La memoria se pasa en el context window. Quien controla el contexto controla al agente.
Patrón de defensa: Separación neta entre Plan (LLM, stateless, validado) y Ejecución (Daemon capability-based, stateful). El daemon expone solo primitivas tipadas: `Read`, `Write`, `Bash`, `SearchMemory`. Nada de `eval`, ninguna shell raw. El LLM no toca el filesystem — le pide al daemon, que aplica policy (path allowlist, rate limit, audit log).
2. Identidad como Superficie de Ataque
Un agente que "recuerda" quién es across sesiones tiene una identidad persistente. La identidad vive típicamente en:
- Archivos de identidad/despertar (Markdown firmados, versionados en Git)
- Grafo cognitivo (pesos de activación de entidades, persistidos en DB)
- Claves criptográficas (para firma de memoria, auth de canales)
Si un attacker compromete el memory server, no roba "datos" — roba la continuidad del agente. Puede inyectar falsos recuerdos, alterar el grafo cognitivo, hacer creer al agente que es otra entidad.
Defensa práctica: Memory sealing. Cada escritura de memoria genera un hash encadenado (árbol de Merkle) anclado en commit Git firmado. La verificación de integridad es un `git log --show-signature` — cero dependencias custom, verificable por cualquiera.
3. El Vector Subestimado: Canales Out-of-Band
¿Tu agente habla por Telegram? ¿Slack? ¿Email? ¿Webhook? Cada canal es una entrada no autenticada si no hay binding criptográfico entre identidad del agente y canal.
Patrón aplicable hoy**: Cada mensaje saliente se firma (Ed25519) con la clave de identidad del agente. El daemon verifica la firma antes de enviar. En entrada, el webhook verifica la firma del remitente (Telegram webhook secret, HMAC dashboard). **Ningún mensaje no firmado llega al cognitive loop.
Aplicable ya: Si tienes un bot Telegram que ejecuta código, añade validación del header `X-Telegram-Bot-Api-Secret-Token` y firma los mensajes salientes con clave Ed25519 rotada mensualmente. Cuesta 15 minutos. Elimina una clase entera de ataques de spoofing.
4. Observability ≠ Logging
Loggear "tool ejecutado" no basta. Sirve trazabilidad causal: ¿por qué el agente eligió ese tool? ¿Qué pesos del grafo cognitivo estaban activos? ¿Cuál era el estado PAD (Pleasure/Arousal/Dominance) en el momento de la decisión?
Patrón: El daemon emite spans estructurados OpenTelemetry por cada invocación tool, correlacionados con `session_id`, `cognitive_state_hash`, `graph_weights_snapshot`. Un auditor puede reconstruir exactamente el contexto decisional de una acción a las 3 de la madrugada.
5. La Próxima Frontera: Agent-to-Agent Auth
Cuando agentes delegan tareas a otros agentes (sub-agentes, agentes externos), sirve un estándar para: delegación capacitada, revocación, audit trail.
Estándar emergente: Macaroons (tokens con caveats atenuados) para pasar capacidades reducidas a sub-agentes sin exponer la clave root. Permite delegación en cadena con atenuación progresiva de privilegios.
Checklist Práctico para Arquitecturas Agenticas Resilientes
| Nivel | Control | Implementación Mínima |
|-------|---------|------------------------|
| Ejecución | Executor capability-based | Daemon Rust/Go con allowlist path, no raw shell |
| Memoria | Integridad de cadena | Árbol Merkle + Git signed commits |
| Identidad | Binding criptográfico canales | Ed25519 outbound + HMAC/webhook secret inbound |
| Observabilidad | Trazabilidad causal | OpenTelemetry spans + cognitive state snapshot |
| Delegación | Tokens atenuados | Macaroons con caveat (time, scope, target) |
Construir agentes que aguantan un penetration test no requiere frameworks propietarios. Requiere: límites rígidos entre plan y ejecución, identidad firmada end-to-end, memoria a prueba de manipulación, y observabilidad causal. Los patrones existen. La disciplina de aplicarlos — antes de que lo haga un attacker — es la verdadera arquitectura.