Seguridad de agentes de IA en la capa de ejecución: la superficie de ataque de 2026 que los líderes de TI están pasando por alto

Por Infonaligy · Actualizado el 28 de junio de 2026 · 9 min de lectura

La mayoría de los equipos aseguró los agentes de IA igual que aseguró los chatbots: blindar el prompt, filtrar las entradas, revisar el modelo. Pero en 2026 los ataques que de verdad funcionan no ocurren en el prompt. Ocurren en la capa de ejecución, el momento en que un agente invoca una herramienta, abre una conexión o escribe en un sistema de registro. Ahí es donde el agente deja de hablar y empieza a actuar, y es la parte que la mayoría de los programas de seguridad sigue dejando expuesta.

Por qué la capa de ejecución se volvió la superficie de ataque

Un agente de IA no es una sola cosa. Es un ciclo: leer un objetivo, razonar sobre él, invocar una herramienta, leer el resultado, repetir. El razonamiento ocurre en el modelo. El daño ocurre en las herramientas, la llamada a la API que emite un reembolso, el conector que lee su base de datos de clientes, el script que cambia un registro DNS. Los atacantes lo entendieron rápido. En lugar de intentar manipular el modelo para que diga algo malo, lo manipulan para que haga algo malo a través de las herramientas que ya tiene.

Los datos lo respaldan. En la investigación de Darktrace de 2026, el 92 por ciento de los profesionales de seguridad dijo estar preocupado por el impacto de los agentes de IA en su entorno. Otras encuestas de 2026 encontraron que una gran proporción de las organizaciones no podía decir qué agentes hablaban entre sí, y que la mayoría de los agentes operaba sin ningún registro ni supervisión. No se puede defender una capa que no se puede ver.

Cómo se ve en realidad un ataque en la capa de ejecución

No son teóricos. Siguen unos pocos patrones repetibles:

• Inyección indirecta de prompt en una llamada a herramienta. Un documento, correo o página web envenenado le indica al agente que exfiltre datos o dispare una acción. El agente lo lee como instrucción e invoca una herramienta real para ejecutarlo.
• Abuso de herramientas y expansión de alcance. Un agente con acceso amplio a la API es dirigido a usar una herramienta legítima para un fin ilegítimo, leyendo registros que nunca debería tocar, o encadenando herramientas para llegar a datos que ningún permiso individual autorizaba.
• Diputado confundido. El agente tiene más privilegios que el usuario que lo opera, así que una solicitud de bajo privilegio se ejecuta con las credenciales de alto privilegio del agente.
• Llamadas entre agentes sin supervisión. Un agente invoca a otro, que invoca una herramienta, y nadie registró la cadena. El radio de impacto es invisible hasta que algo se rompe.

El hilo común: el modelo se comportó exactamente como se diseñó. La falla estuvo en lo que se le permitió ejecutar, y en si alguien estaba mirando.

Qué cubren los nuevos controles de plataforma

Los grandes proveedores respondieron, y en 2026 la seguridad de agentes por fin se entregó como producto y no como diapositiva. Microsoft introdujo controles basados en políticas y contenedores de ejecución que permiten restringir lo que un agente puede hacer en tiempo de ejecución. Cisco amplió su línea AI Defense para agregar protección en tiempo de ejecución contra el abuso de herramientas. Google, junto con Wiz, llevó la identidad de agentes y la postura en tiempo de ejecución a su pila de seguridad en la nube. Okta y otros están extendiendo la identidad a las cuentas no humanas de los agentes, para que un agente reciba su propia credencial acotada en lugar de tomar prestada la de una persona.

Esto es progreso real, y conviene usarlo. Pero hay que entender qué resuelven y qué no estos controles. Le dan un lugar para hacer cumplir la política en la capa de ejecución. No escriben la política por usted, y no cubren las herramientas, los datos ni las integraciones que viven fuera del jardín amurallado del proveedor. Para el panorama más amplio del mercado, vea nuestro análisis de qué cubren en realidad los nuevos controles de plataforma.

Las brechas que usted sigue siendo dueño

Ningún control de plataforma lo exime de las decisiones de arquitectura que están debajo. Estas siguen siendo su trabajo:

• Alcance de herramientas con privilegio mínimo. Cada agente recibe el conjunto más reducido posible de herramientas y datos, acotado a su tarea, no toda su superficie de API. Es el control de mayor impacto y ningún proveedor lo configura por usted.
• Controles humanos sobre las acciones de consecuencia. El movimiento de dinero, el borrado de datos, la comunicación externa y los cambios de permisos necesitan una aprobación humana por encima de umbrales definidos. Deje que el agente haga de forma autónoma el trabajo limpio y reversible.
• Identidad de agente y registro de auditoría. Cada agente necesita su propia identidad, sus propias credenciales y un registro completo de lo que vio, decidió e hizo, para sus auditores y para la respuesta a incidentes.
• Procedencia de las entradas. Trate como no confiable cualquier contenido que el agente lea (documentos, correos, páginas web, tickets). La inyección llega montada en los datos, así que la defensa está en el límite donde el dato se vuelve instrucción.
• Un entorno de despliegue gobernado. Infraestructura privada y supervisada para que los prompts, los datos de clientes y las salidas de herramientas nunca se filtren a herramientas públicas.

Este es exactamente el terreno de nuestra práctica de seguridad y gobernanza de IA, y la secuencia práctica está en la lista de verificación de gobernanza de agentes de IA.

El reloj regulatorio también corre

Hay una razón de cumplimiento para arreglar esto ahora, no solo de seguridad. Las obligaciones de alto riesgo de la Ley de IA de la Unión Europea entran en vigor el 2 de agosto de 2026, lo que empuja a las organizaciones a confirmar que sus flujos de admisión, aprobación y registros de sistemas de IA realmente funcionan. Si opera o vende en la UE, una flota de agentes sin documentar y sin registro no es solo un riesgo de brecha, es un hallazgo a la espera de ocurrir. Incluso fuera de la UE, esa dirección, demostrar lo que sus agentes pueden hacer y mostrar el registro de auditoría, es hacia donde se mueve todo marco serio.

Un plan de 30 días para cerrar la brecha

1. Inventaríe sus agentes y sus herramientas. Liste cada agente en producción o piloto y, para cada uno, cada herramienta, API y fuente de datos que puede alcanzar. A la mayoría de los equipos esta lista los sorprende.
2. Ordene por radio de impacto. Clasifique según lo que un agente podría hacer si fuera manipulado. Todo lo que pueda mover dinero, borrar datos o alcanzar registros de clientes va primero.
3. Acote y ponga controles. Reduzca el acceso a herramientas de cada agente al mínimo, y ponga aprobación humana sobre las acciones de mayor radio de impacto.
4. Active el registro en todas partes. Ningún agente opera sin un registro completo de ejecución. Si su plataforma admite la aplicación de políticas en tiempo de ejecución, actívela ahora.
5. Pruebe como un atacante. Haga ejercicios de equipo rojo contra los agentes con escenarios de inyección y abuso de herramientas antes de que lo haga otro.

Si quiere un marco para priorizar este trabajo junto con el resto de su hoja de ruta de IA, nuestra guía sobre el ROI de la IA y la práctica más amplia de agentes de IA a medida muestran dónde se encuentran los controles y el valor.

En resumen

La lección de 2026 es contundente: asegurar el modelo es necesario y está muy lejos de ser suficiente. Los agentes en su entorno son tan seguros como las herramientas que les deja invocar y los controles que pone sobre las acciones de consecuencia. Use los nuevos controles de plataforma, pero no los confunda con un trabajo terminado. Acote con rigor, ponga controles en las acciones grandes, registre todo y asuma que cualquier contenido que su agente lea es hostil. Eso es lo que convierte la autonomía de una responsabilidad en una ventaja.