Opinión impopular: la mayoría de los flujos de n8n no se rompen por la IA. Se rompen por cuatro decisiones de plomería a su alrededor — y esas mismas cuatro decisiones definen qué puede hacer un atacante si alguna vez logra entrar.

Esto no es una publicación para sembrar miedo. Es una publicación de infraestructura. La seguridad, bien hecha, no es una lista de chequeo separada que se pega después — es un efecto secundario de construir bien las partes aburridas desde la primera vez. Así se ve eso en la práctica, y por qué cada hábito contiene el daño, no solo lo previene.

  1. No construyas un mega-flujo. Divide los flujos largos en flujos más pequeños y aislados, en vez de una sola automatización que intenta hacer todo desde el disparador hasta la acción final. Cada pieza se mantiene pequeña, los secretos de cada pieza quedan limitados a lo que realmente necesita — y si alguna vez comprometen un paso, quien entró no puede moverse hacia el resto de la cadena, porque el resto de la cadena nunca fue alcanzable desde donde aterrizó.
  2. No conectes nodos de herramientas directamente a nada que tenga una credencial. Ponlos detrás de un servidor MCP en vez de cablear las llaves de API directamente en el lienzo. La autenticación vive en la capa del MCP, no en el propio JSON del flujo — así que una exportación filtrada, un lienzo compartido, o un traspaso descuidado nunca entrega las llaves reales junto con eso.
  3. No le des al modelo entradas mezcladas sin procesar. Chat, correo, un formulario, una llamada a una API — cada uno llega en una forma distinta. Normalízalos todos a un solo esquema antes de que algo llegue al nodo de IA. Ese paso de normalización también es el filtro: ahí es donde rechazas o pones en cuarentena cualquier cosa que no encaje en la forma esperada, en vez de pasarle a un modelo lo que sea que haya llegado y dejar que haga su mejor esfuerzo por interpretar basura como intención.
  4. No confíes en el camino feliz. Agrega un Error Trigger, un reintento ante fallos con un límite sensato, y una rama de respaldo que realmente alerte a un humano. Las fallas silenciosas son tanto la forma en que un atacante se mueve sin ser detectado como la forma en que la solicitud de un cliente real desaparece en silencio — la alerta es lo que convierte un “nos dimos cuenta tres días después” en un “lo notamos a las 3 de la mañana”.

Ninguno de estos cuatro es exótico. Son las partes aburridas de construir automatización de la forma correcta. Las partes interesantes — el razonamiento de la IA, el prompt ingenioso — normalmente ya funcionan para cuando alguien pide ayuda. Es la plomería la que decide si todo el sistema sobrevive al contacto con producción, y con cualquiera que no debería estar ahí.