Hay dos formas de pensar en la seguridad de aplicaciones web en 2026. La primera: reglas estáticas. Una lista de patrones conocidos, firewall que los bloquea, humanos que actualizan la lista cuando aparecen amenazas nuevas. Funciona, pero es reactivo y no escala bien.
La segunda: agentes IA autónomos. Software que corre dentro de tu aplicación, observa el tráfico y los cambios, razona sobre contexto, decide acciones, ejecuta respuestas, aprende de los resultados. No es futurismo — es la arquitectura que empresas como CrowdStrike, Palo Alto Networks, y SentinelOne están empujando desde hace 2-3 años. Conan lo trae al stack de aplicaciones web (WordPress, Laravel, Node, Next).
Este artículo es para directores técnicos, arquitectos de seguridad y CISOs evaluando si invertir en esta capacidad. Explica qué es un agente IA de seguridad, cómo se estructura la arquitectura multi-agente, los 4 niveles de autonomía configurables, y los riesgos reales (incluidos los que no salen en las keynotes de marketing).
Lo que vas a aprender
- Qué distingue a un "agente IA" de una "regla con ML" (no es lo mismo).
- Arquitectura multi-agente: agente local + motor central + meta-agente coordinador.
- 4 niveles de autonomía: observa / propone / actúa con notificación / autónomo pleno.
- Trade-offs reales: velocidad vs auditabilidad, costo vs cobertura, autonomía vs control.
- Cuándo agentes IA son la respuesta correcta y cuándo son overkill para tu caso.
La distinción que importa: agente vs regla con ML
Hay mucho marketing de "IA en seguridad" que en realidad es "reglas estáticas con un modelo ML de scoring". Útil, pero no es agente IA. La diferencia estructural:
Regla con ML: pipeline rígido. Input (request, evento, archivo) → modelo ML scores threat level → si supera umbral → acción predefinida. El modelo decide el scoring, pero las acciones son hardcoded.
Agente IA: pipeline flexible. Input → modelo razona sobre contexto (no solo clasifica) → genera plan de acción multi-paso → ejecuta → observa resultado → ajusta. El modelo decide qué hacer, no solo cuánto "peligro" hay.
Ejemplo concreto:
- Regla con ML: detecta archivo modificado en
functions.php. Modelo asigna score 0.89 de "sospechoso". Umbral es 0.8. Acción: enviar alerta. - Agente IA: detecta archivo modificado. Analiza el código nuevo vs el viejo. Razona: "la modificación agrega
register_activation_hookcon una función llamadawp_handle_upload_overrideque escribe archivos PHP a/uploads/. Esto es patrón de webshell dropper. Mi plan: 1) Hacer snapshot del archivo actual para rollback. 2) Revertir al archivo anterior usando backup local. 3) Bloquear cualquier request a/uploads/*.phpvia WAF regla temporal. 4) Notificar al admin con contexto completo." Ejecuta el plan. Observa que tras revertir, un bot externo sigue intentando trigger el webshell. Ajusta: "el atacante ya conoce el backdoor, posiblemente tiene otro vector. Extender búsqueda a otros archivos modificados en el último mes."
La diferencia no es cosmética. El agente toma decisiones complejas y encadenadas que una regla estática no puede expresar.
Arquitectura multi-agente de Conan
Conan no es un agente monolítico. Es una jerarquía de agentes especializados coordinados por un meta-agente.
Capa 1: Agentes locales
Uno por cada aplicación que proteges. Corre dentro de tu stack:
- Agente WordPress: plugin PHP. Intercepta hooks clave de WordPress (auth, file operations, admin actions). Analiza código modificado. Reporta a motor central.
- Agente Laravel: middleware PHP. Intercepta requests antes de tus controladores. Analiza queries a DB antes de ejecutar. Reporta a motor central.
- Agente Node.js: library npm. Wrap de middleware Express/Koa/Fastify. Analiza prompts a LLMs (si tu app usa IA), validación de JWTs, queries a DB.
- Agente Next.js: middleware y edge functions. Combina aspectos del agente Node con consideraciones específicas de renderizado.
Los agentes locales son livianos: menos de 100MB RAM, menos del 5% CPU overhead. Su trabajo es observar, instrumentar, y reportar. La inferencia pesada (análisis de código con LLM grande) NO corre localmente.
Capa 2: Motor central de inferencia
Servidores Drokio (o on-premise en el caso de Diesel) corriendo los modelos de IA:
- Drokio Colmillo (motor primario de análisis de código, auto-hosteado en la infraestructura de Drokio) — es el motor que más entendemos y al que más ajustamos prompts y knowledge base.
- Modelos de threat classification para categorizar patrones (no es LLM, es clasificador ML optimizado para speed).
- Modelo de atribución para correlacionar eventos entre sitios y detectar campañas.
Los agentes locales envían datos al motor central vía HTTPS (o mTLS si es Diesel), reciben veredictos, ejecutan.
Capa 3: Meta-agente Maestro
Esto es lo que diferencia a Conan de agentes IA individuales. Maestro corre por encima de los agentes específicos de cada aplicación y:
- Correlaciona eventos: si tres sitios distintos del mismo cliente reciben patrones de ataque similares, Maestro los relaciona como campaña.
- Orquesta respuestas: cuando un agente individual recomienda una acción, Maestro valida el contexto amplio antes de ejecutar. Si bloquear una IP en sitio A va a bloquear a clientes legítimos en sitio B (por ejemplo, proveedor legítimo compartiendo IP), Maestro vetoes.
- Mantiene memoria institucional: aprende de las decisiones humanas de override. Si el admin revierte una acción del agente X veces, Maestro ajusta la política para ese cliente.
- Decide escalado humano: cuando la confianza de los agentes baja (patrón ambiguo, contexto incompleto), Maestro decide que el caso necesita humano y lo rutea.
La analogía útil: los agentes individuales son como perros guardianes entrenados para tareas específicas (uno para el portón, otro para el patio, otro para la casa). Maestro es el humano que entiende el perímetro completo y decide a quién escuchar cuando varios ladran a la vez.
4 niveles de autonomía
Una preocupación real: ¿qué pasa si el agente IA se equivoca? ¿Bloqueó a un cliente legítimo? ¿Revirtió una actualización que era correcta?
Conan resuelve esto con niveles configurables de autonomía. El cliente elige cuánto poder le da al sistema:
Nivel 1: Observa
El agente observa todo, analiza, pero no actúa. Solo genera alertas con recomendación. El admin humano decide cada acción.
Cuándo usarlo: primeros 30 días después de integrar Conan. Evaluación de si el agente IA es preciso suficiente para tu caso. Entornos donde cualquier acción automática es riesgosa (compliance estricto, trading financiero en tiempo real).
Nivel 2: Propone
El agente genera plan de acción. Lo comunica al admin. Espera confirmación humana para ejecutar. Si el admin confirma, ejecuta. Si no confirma en X tiempo, la propuesta expira.
Cuándo usarlo: operación normal de empresas medianas con equipos técnicos durante horas hábiles. La latencia humana (minutos a horas) está bien para respuestas no críticas.
Nivel 3: Actúa con notificación
El agente ejecuta la acción y notifica al admin post-hoc. El admin puede revertir si el agente se equivocó. Este es el modo "default" para muchos incidentes: respuesta automática en segundos, transparencia total.
Cuándo usarlo: operación 24/7 donde esperar confirmación humana aumenta riesgo. Ataques automatizados donde la velocidad importa más que la perfección. Equipos confiados en la precisión del agente después de período de adaptación.
Nivel 4: Autónomo pleno
El agente ejecuta. No notifica en tiempo real. Reporta en resúmenes periódicos (diario, semanal) con decisiones agregadas. Solo se escala humano cuando la confianza baja de un umbral.
Cuándo usarlo: raras veces. Principalmente en honeypots, entornos aislados de investigación, o infraestructura con equipos de seguridad altamente maduros que confían en la automatización total después de años de uso.
La recomendación práctica: empezá en Nivel 2, subí a Nivel 3 después de 60-90 días de confianza, quedate ahí para siempre. Nivel 4 es sexy en marketing pero rara vez óptimo en producción.
Conan con 4 niveles de autonomía configurables
Agentes IA con meta-agente coordinador sobre stack WordPress. De observar a autónomo, vos decidís el nivel.
Trade-offs honestos
Velocidad vs auditabilidad
Los agentes IA toman decisiones en milisegundos a segundos. Esa velocidad es la ventaja. El trade-off: cada decisión es menos deliberada que una decisión humana. Para regulación estricta (banca, salud), puede haber requerimientos de auditabilidad que requieren revisar cada acción autónoma.
Mitigación: log completo de cada decisión del agente, con input, razonamiento, acción y outcome. Reviewable después del hecho. Pero es post-mortem, no pre-autorización.
Costo vs cobertura
Correr agentes IA en cada sitio cliente tiene costo. No solo la licencia — costo de inferencia de modelos, infraestructura, soporte. Conan está pensado para empresas medianas hacia arriba. Para PyMEs es overkill.
Mitigación: Drako es la versión accesible ($9/mes) que usa análisis con IA pero sin agentes autónomos runtime. Cairo es el punto intermedio ($59-149/mes). Conan es $500+/mes. Escalás según lo que necesitás.
Autonomía vs control
Más autonomía = más velocidad, menos control humano. Menos autonomía = más control, más latencia en respuestas. No hay respuesta universal; depende del risk appetite de tu organización.
Mitigación: los 4 niveles. Ajustar según confianza histórica. Diferentes niveles para diferentes tipos de eventos (ej: nivel 4 para brute force bloqueos, nivel 2 para cambios de archivo, nivel 3 para patrones de exfiltración).
Dependencia del vendor
Si Conan se cae (servidor Drokio offline), ¿qué pasa con tu aplicación? La respuesta honesta: los agentes locales tienen modo "mínimo" con reglas pre-calculadas que cachean y operan offline. Pero las capacidades avanzadas (análisis de código nuevo, coordinación multi-agente) requieren conectividad.
Mitigación para misión crítica: Diesel permite deployment on-premise del motor IA, eliminando la dependencia externa. Para la mayoría, el trade-off de usar servicio cloud es aceptable si tiene SLA robusto.
Cuándo agentes IA son overkill
No siempre son la respuesta correcta. Contextos donde conviene más una solución simple:
- Sitio personal o blog: plugin de seguridad estándar (Drako) alcanza. Agentes IA es overkill.
- Equipos sin SOC 24/7: si no hay capacidad humana de responder a escalados, poner agentes IA autónomos crea ruido sin acción.
- Presupuesto ajustado: Conan ($500+/mes) no tiene sentido si no podés cubrirlo cómodamente. Mejor invertir en fundamentals básicos (hardening, monitoreo, backups).
- Regulación que prohíbe automatización: algunos contextos regulados (defensa, gobierno) requieren que toda acción de seguridad sea autorizada por humano. Ahí Conan en Nivel 1-2 funciona; Nivel 3-4 no.
Cuándo son la respuesta correcta
- Operación 24/7 con volumen de tráfico: cuando no podés tener humanos revisando cada evento en tiempo real.
- Operación WordPress en escala: cuando administrás muchos sitios WordPress y un sistema unificado con agentes coordinados simplifica la operación. Drokio hoy es WordPress-only — para stacks multi-framework reales (Laravel, Node, Next) necesitás otro vendor o complementar.
- Necesidad de virtual patching automático: cuando las ventanas de vulnerabilidad son críticas para tu negocio.
- Equipos maduros que quieren liberar tier 1: SOCs que quieren que los humanos suban al tier 2-3 y la IA maneje tier 1.
- Integración con SIEM/SOC existente: cuando ya tenés stack de observabilidad y querés enriquecer con eventos clasificados por IA.
Cierre
Los agentes IA de seguridad no son un futuro lejano — son presente, desplegados en producción por empresas desde 2023. Lo que cambió en 2025-2026 es que los modelos de lenguaje llegaron a nivel suficiente para razonamiento contextual, y las arquitecturas multi-agente maduraron al punto de poder orquestar sin caos.
Para CTOs y CISOs evaluando: la pregunta no es si agentes IA van a ser el default de defensa web (lo van a ser, en 3-5 años todo el stack estará así). La pregunta es si tu organización lo integra ahora (early adopter, ventaja competitiva) o espera otros 2-3 años (más maduro, menos riesgo, más competencia).
Conan está diseñado para ese early-to-mid adopter que quiere la capacidad pero no quiere construirlo desde cero.
Preguntas frecuentes
¿Un agente IA puede equivocarse y bloquear usuarios legítimos?
Sí, puede. Por eso Conan ofrece 4 niveles de autonomía configurables: observa (nivel 1), propone (2), actúa con notificación (3), autónomo pleno (4). Las empresas típicamente empiezan en nivel 2, suben a 3 después de 30-60 días de confianza, y muy pocas llegan a nivel 4 (solo cuando hay equipo de seguridad 24/7 que puede intervenir si algo se va de control).
¿Los agentes IA reemplazan al equipo de SOC?
No. Los agentes automatizan el tier 1 (triage, bloqueos simples, respuestas a patrones conocidos). El equipo humano sube al tier 2-3 (investigación de incidentes complejos, decisiones estratégicas, casos donde la IA tiene baja confianza). El resultado es un SOC más eficiente — cada humano maneja más sitios gracias a la automatización de lo rutinario.
¿Qué pasa si el modelo de IA tiene un bug o halluciation?
Todo lo que hace el agente IA queda auditado con log completo. Si detectamos un bug (o lo detectás vos), podés revertir acciones, ajustar el nivel de autonomía, o deshabilitar temporalmente. La arquitectura asume que la IA puede equivocarse — por eso hay niveles, shadow modes, y la capacidad humana de override.
¿Conan funciona offline o requiere conectividad constante al motor IA?
Para análisis en runtime, sí requiere conectividad al motor IA (ahí corren los modelos). Los agentes locales tienen cache de reglas pre-calculadas y pueden operar en 'modo mínimo' si pierden conexión (reglas estáticas derivadas de análisis previos). Para clientes enterprise que requieren operación 100% offline (infraestructura crítica, gobiernos), Diesel ofrece despliegue on-premise con motor IA local.
¿Cuánto CPU/memoria consume un agente IA en mi aplicación?
El agente local (WordPress plugin, Laravel middleware, Node library) es liviano: menos de 100MB de RAM, menos del 5% de CPU en tráfico normal. La inferencia pesada (análisis de código con LLM) corre en el motor remoto, no en tu aplicación. Ese es el diseño: lo costoso se offloaded, lo local es solo telemetría e intercepción.
¿Puede un atacante envenenar el modelo de IA con requests diseñados?
Es una preocupación válida en sistemas que se re-entrenan online con data de producción. Conan NO re-entrena en línea con data de clientes — usamos una cadena de motores auto-hosteados (Drokio Colmillo y su cadena de respaldo) con prompts y knowledge base propios, y los pesos se mantienen inmutables entre releases. Si detectamos adversarial inputs intentando envenenar, los eventos se loguean pero no modifican el modelo. Diseño seguro por default.