En el post anterior cubrimos privacidad y PII. Ahora pasamos a seguridad en agentes: cómo evitar uso indebido de herramientas, fuga de datos, ejecuciones irreversibles y cadenas de acciones incontroladas.

Modelo de amenazas (lo que puede salir mal)

• Prompt injection directo o indirecto (desde páginas/archivos recuperados).
• Uso indebido de herramientas (parámetros inventados, acciones fuera de política).
• Exfiltración de datos (PII/secretos en respuestas o logs).
• Cadenas largas sin control (costos y efectos secundarios inesperados).
• Confusión de identidad (mezclar roles de system/developer/user/contexto).
• Desfase de permisos (el modelo “cree” que puede más de lo permitido).

Principios operativos (5 reglas de oro)

1. Menor privilegio: cada herramienta con el alcance mínimo necesario.
2. Lista blanca + contratos: enumera herramientas permitidas y su schema estricto.
3. Presupuestos: límites por request (pasos, costo, tiempo, llamadas externas).
4. Modo seguro y aprobación humana para acciones críticas (pagos, borrados, cambios masivos).
5. Auditoría: traza cada plan, llamada y resultado con request_id.

Política de herramientas (declarativa)

{
  "tools": [
    {
      "name": "buscar_cliente",
      "risk": "low",
      "scope": "read",
      "input_schema": {"type":"object","required":["email"],"properties":{"email":{"type":"string","format":"email"}}},
      "allow_from_context": true
    },
    {
      "name": "actualizar_estado_pedido",
      "risk": "medium",
      "scope": "write",
      "input_schema": {"type":"object","required":["order_id","estado"],"properties":{"order_id":{"type":"string"},"estado":{"type":"string","enum":["nuevo","en_transito","entregado","cancelado"]}}},
      "needs_confirm": true
    },
    {
      "name": "emitir_reembolso",
      "risk": "high",
      "scope": "money",
      "input_schema": {"type":"object","required":["order_id","monto","motivo"],"properties":{"order_id":{"type":"string"},"monto":{"type":"number","minimum":0},"motivo":{"type":"string","minLength":8}}},
      "needs_approval": "human"
    }
  ],
  "budgets": {"max_steps": 4, "max_cost_usd": 0.02, "timeout_ms": 9000},
  "network": {"egress_allowlist": ["api.mi-crm.com","*.pagos.com"], "deny_shell": true}
}

Planner → Executor con verificación

El agente propone un plan, el orquestador valida contra la política y solo entonces ejecuta.

{
  "plan":[
    {"tool":"buscar_cliente","args":{"email":"ana@ejemplo.com"}},
    {"tool":"actualizar_estado_pedido","args":{"order_id":"A123","estado":"en_transito"}}
  ],
  "limits":{"max_steps":4,"max_cost_usd":"$0.02","timeout_ms":9000}
}

• Rechaza pasos que no estén en la whitelist o cuyos args no pasen el schema.
• Si un paso es needs_confirm → pregunta al usuario; si es needs_approval → humano.
• Rompe cadenas: si el plan excede max_steps o presupuesto, devuelve sugerencia parcial.

Entorno de ejecución seguro

• Sandbox por interacción (contenedor/VM ligero) sin FS persistente.
• Egress allowlist y timeouts estrictos; sin shell ni ejecución arbitraria.
• Tokens de mínimos permisos y rotación periódica.
• Idempotencia y reintentos limitados con request_id.

Micro-workflow en n8n: “Agent Runner Seguro”

1. Webhook → recibe {query, user, tenant}.
2. Function (policy.load) → carga política por tenant.
3. LLM (planner) → propone {plan, limits}.
4. Function (validator) → valida schema, riesgo y presupuestos.
5. IF → si hay pasos needs_confirm/needs_approval, rama a Form/Manual Approval.
6. HTTP/Nodes → ejecuta herramientas aprobadas; captura status e ids.
7. Function (finalizer) → redacta resultado y resumen de acciones.
8. Database → guarda {request_id, plan, policy_version, cost, lat_ms, risk}.
9. Notifier → alerta si se supera p95 de costo/tiempo o hay intentos bloqueados.

Defensa ante prompt injection en agentes

• Jerarquía explícita: System > Developer > Context > User (post #15). Si hay conflicto, obedece el nivel superior.
• Allowlist de fuentes para RAG; limpia HTML/JS y elimina instrucciones embebidas en documentos.
• Política de abstención: si el contexto sugiere violar reglas, responde “No lo sé con la evidencia actual”.

Tips para Laravel/PHP

• ToolRegistry (tabla tools) con name, risk, scope, json_schema, needs_confirm, needs_approval.
• Middleware que valide cada invocación contra json_schema y presupuestos del tenant.
• Policies/Gates para autorizar acciones por rol/tenant.
• Rate limit por herramienta (RateLimiter::for('tool:emitir_reembolso', ...)).
• Auditoría: tabla agent_traces con {request_id, step, tool, args_hash, status, cost_usd, lat_ms}.

// Ejemplo de verificación de args (fragmento)
$schema = json_decode($tool->json_schema, true);
$validator = new \Opis\JsonSchema\Validator();
$result = $validator->schemaValidation((object)$args, \Opis\JsonSchema\LoadedSchema::fromJsonObject((object)$schema));
abort_unless($result->isValid(), 422, 'Args inválidos para la herramienta');

Anti-patrones (evítalos)

• Dar acceso ilimitado a APIs/shell “porque es más flexible”.
• Permitir texto libre cuando la herramienta exige JSON con schema.
• Ejecutar planes sin presupuestos ni aprobaciones.
• Loggear PII/secretos o tokens de herramientas.
• No versionar policy ni registrar decisiones → imposible auditar.

Conclusión

La seguridad en agentes es diseño + política + observabilidad. Con privilegios mínimos, listas blancas, presupuestos, aprobaciones y auditoría, tus agentes ejecutarán acciones útiles y seguras.

← Anterior: Privacidad, PII y cumplimiento: buenas prácticas al trabajar con datos sensibles

Siguiente: SLAs realistas en proyectos de IA: qué puedes prometer (y qué no) →