Los agentes de IA no solo crean riesgos cuando alucinan o producen una respuesta inexacta. Crean riesgos cuando realizan la acción incorrecta.
Una sola instrucción del usuario puede moverse a través de una aplicación, llegar a un entorno de ejecución de agente, invocar una herramienta, activar un servidor MCP y tocar una API descendente. Para cuando la acción ocurre, la solicitud original puede estar a varias capas de distancia del sistema que realmente cambia los datos, envía información o ejecuta un flujo de trabajo.
Ese es el problema al que se enfrentan ahora los equipos de seguridad. Las organizaciones se apresuran a implementar agentes de IA, pero muchas aún carecen de una visión clara de a qué pueden acceder esos agentes, qué herramientas pueden invocar y qué API pueden activar.
La industria de la ciberseguridad también ha centrado demasiada atención únicamente en la capa del modelo. La seguridad de los LLM es importante, pero un sistema agéntico empresarial no es una sola capa. Abarca LLM en la parte superior, servidores MCP en el medio y API y sistemas descendentes en la capa de acción. El riesgo se mueve a través de las tres.
Por eso la seguridad de los agentes de IA no puede detenerse en las instrucciones, los modelos o las barreras de seguridad. Para asegurar este nuevo ecosistema, los equipos de seguridad necesitan comprender cómo funcionan realmente los sistemas agénticos y por qué la visibilidad de las API se ha convertido en el punto de control.
La arquitectura agéntica explicada
Cuando trazamos un mapa de una aplicación agéntica, el riesgo se vuelve mucho más fácil de ver. Un agente no es solo un chatbot con una interfaz mejor. Es un sistema que puede razonar, elegir herramientas y actuar a través de una infraestructura empresarial real.
La entrada
Todo comienza con el usuario final.
Una instrucción del usuario viaja a través de la capa de aplicación, generalmente a través de un sitio web, una interfaz de producto, un proxy o un servicio de backend-for-frontend. Desde allí, llega al entorno de ejecución del agente a través de un punto final dedicado como /api/chat.
En esta etapa, la solicitud puede parecer simple. Un usuario podría pedir al agente que resuma una cuenta, actualice un ticket, extraiga datos de clientes, busque documentación o active un flujo de trabajo. Pero una vez que la solicitud entra en el entorno de ejecución del agente, el sistema comienza a decidir qué debe suceder a continuación.
El cerebro: LLM y gobernanza
Dentro del entorno de ejecución del agente, el orquestador del agente gestiona el flujo de decisiones. Envía solicitudes al LLM para razonamiento y generación. También recibe instrucciones de la instrucción del sistema, aplica políticas y enruta la entrada y salida a través de barreras de seguridad.
Esta capa es importante porque moldea cómo piensa y responde el agente. Puede ayudar a detectar la inyección de instrucciones, bloquear contenido inseguro y aplicar reglas de política básicas.
Pero esta capa no es suficiente por sí sola.
El modelo puede decidir qué debe suceder, pero el riesgo real aparece cuando se permite al agente hacer algo. Ahí es donde la arquitectura pasa del razonamiento a la acción.
La capa de acción: donde el riesgo se vuelve real
Esta es la capa más importante que los equipos de seguridad deben comprender.
Los agentes se vuelven poderosos porque pueden usar herramientas. Pueden consultar bases de datos, buscar en la web, invocar servicios internos, actualizar registros, crear tickets, enviar mensajes o activar flujos de trabajo automatizados.
En la mayoría de los entornos empresariales, estas acciones se realizan a través de tres vías principales.
Kits de herramientas integrados
Los kits de herramientas integrados dan a los agentes acceso a capacidades comunes como consultas a bases de datos, búsqueda web, recuperación de archivos o acciones específicas de la aplicación.
Estas herramientas hacen que los agentes sean útiles, pero también crean nuevas vías hacia datos sensibles y operaciones críticas para el negocio. Si se engaña a un agente para que use una herramienta incorrectamente, el resultado podría no ser una respuesta errónea. Podría ser una acción perjudicial.
Herramientas personalizadas
Las herramientas personalizadas conectan a los agentes directamente con API internas y sistemas empresariales.
Aquí es donde muchas organizaciones subestiman el riesgo. Una herramienta personalizada puede exponer flujos de trabajo de reembolso, registros de clientes, datos de productos, acciones de soporte o funciones de administración internas. Si la herramienta tiene permisos amplios, el agente puede heredar un acceso mucho más amplio del que debería tener el usuario.
Estos no son riesgos teóricos. Investigadores de seguridad ya han demostrado cómo la inyección indirecta de prompts puede manipular sistemas de IA a través de contenido oculto en páginas web, correos electrónicos, documentos u otras entradas externas. El mismo patrón puede aplicarse a las herramientas agénticas: un agente de soporte podría ser inducido a usar indebidamente una API de reembolso o de gestión de cuentas, un agente de investigación podría ser manipulado para exponer datos internos sensibles a través de una herramienta de recuperación excesivamente permisiva, y un agente de flujo de trabajo podría ser guiado para activar un proceso posterior sin suficiente validación.
La cuestión no es solo si el prompt era seguro. La cuestión es si la acción fue autorizada, esperada y visible.
La capa MCP
La capa MCP se está convirtiendo rápidamente en una de las partes más importantes de la pila agéntica.
MCP, o Protocolo de Contexto del Modelo, es una forma emergente para que los agentes de IA se conecten con herramientas, datos y sistemas externos. Proporciona a los agentes una forma más estandarizada de descubrir y llamar herramientas a través de servidores MCP.
En un flujo típico, el tiempo de ejecución del agente utiliza un cliente MCP para comunicarse con un servidor MCP a través de puntos finales como /initialize, /tools/list y /tools/call. El servidor MCP luego ejecuta herramientas específicas, lo que puede activar API posteriores.
Esto crea una potente capa de abstracción. También crea un problema de visibilidad.
Un equipo de seguridad puede ver una llamada a la API al final de la cadena, pero no comprender qué agente la causó, qué herramienta se utilizó, qué servidor MCP la gestionó o qué prompt de usuario inició la acción.
Esa falta de contexto es donde se esconde el riesgo agéntico.
El cuello de botella de la API: Por qué la visibilidad es importante
Una vez que se comprende la arquitectura, un punto queda claro: por muy complejo que sea el razonamiento del agente, sus acciones en el mundo real finalmente se manifiestan como actividad de la API.
El agente puede comunicarse con el LLM, descubrir herramientas a través de MCP, usar funciones personalizadas o depender de conectores integrados; todas estas interacciones también se basan en API. Salt proporciona visibilidad en toda esta capa de comunicación, no solo la llamada final a la API posterior. Esto significa que los equipos de seguridad pueden ver el camino más amplio que toma un agente a medida que razona, selecciona herramientas y actúa a través de los sistemas empresariales.
Esto convierte a la capa de API en el punto de control natural para la seguridad agéntica.
Los equipos de seguridad no solo necesitan saber que se realizó una llamada a una API. Necesitan comprender la cadena completa detrás de esa llamada:
- ¿Qué agente inició la acción?
- ¿Qué usuario o instrucción (prompt) inició el flujo?
- ¿Qué servidor o herramienta MCP estuvo involucrado?
- ¿Qué API descendente se activó?
- ¿Fue el comportamiento normal, riesgoso o malicioso?
Los registros de API tradicionales a menudo no pueden responder a estas preguntas. Muestran el tráfico, pero no siempre el contexto agéntico que lo respalda. Por eso, la visibilidad de las API debe evolucionar para la era agéntica.
El objetivo principal de Salt Security es proteger el ciclo de vida completo de estos sistemas con visibilidad completa, comprensión contextual del riesgo y protección en tiempo real.
Observabilidad a través del grafo de seguridad
Salt no trata cada llamada a una API como un evento aislado. Construye un mapa contextual de la cadena de ejecución agéntica, incluyendo la comunicación de agente a LLM, la comunicación de agente a MCP, la actividad de MCP a herramienta, el uso de conectores y las llamadas a API descendentes.
Esto es importante porque los equipos de seguridad necesitan relaciones, no solo registros.
Si una API descendente se comporta de forma anómala, los equipos deben rastrear esa actividad hasta el agente de origen. Si una herramienta MCP expone acciones riesgosas, los equipos deben comprender qué agentes pueden acceder a ella. Si un agente se comunica con un LLM, llama a un conector, invoca una herramienta o mueve datos sensibles a través de una ruta inesperada, los equipos deben ver la ruta completa.
Ese es el valor de un inventario agéntico unificado y un grafo de seguridad. Convierte la actividad bruta en un mapa de riesgo comprensible.
Gestión contextual de la postura
Los sistemas agénticos también necesitan una gestión de la postura que refleje cómo operan realmente.
No basta con inventariar las API, los agentes o las herramientas por separado. Los equipos de seguridad necesitan saber cómo se conectan estos objetos, a qué puede acceder cada uno y dónde existen las combinaciones más riesgosas.
Por ejemplo, un servidor MCP puede no parecer peligroso por sí solo. Pero si expone herramientas potentes a un agente con amplio acceso a API sensibles, se convierte en un riesgo de alta prioridad.
Salt amplía el descubrimiento en todo el ecosistema de IA e incorpora modelos de riesgo específicos de IA. A medida que las capacidades de la hoja de ruta maduren, el soporte para marcos como OWASP MCP Top 10 y OWASP AI Top 10 puede ayudar a las organizaciones a evaluar el riesgo en agentes, objetos MCP, herramientas y API en contexto.
Protección en tiempo real
La visibilidad es el primer paso. La protección es el siguiente.
Dado que las acciones agénticas finalmente pasan por la capa de la API, los equipos de seguridad necesitan la capacidad de detectar comportamientos de riesgo en tiempo real y, cuando sea posible, detenerlos antes de que lleguen a sistemas críticos. Esto incluye capacidades como el bloqueo de herramientas y API, la detección de anomalías y la detección de inyección de prompts, con capacidades adicionales en la hoja de ruta destinadas a ampliar la protección mediante el bloqueo de atacantes y detecciones relacionadas con las barreras de seguridad (guardrails).
Esto es especialmente importante porque los ataques agénticos pueden no parecerse al abuso tradicional de API. La solicitud puede provenir de un agente de confianza. La herramienta puede estar aprobada. La API puede ser legítima. El riesgo proviene de la combinación de prompt, elección de herramienta, permisos y acción posterior.
La posición de Salt en el punto crítico de la API ofrece a los equipos una forma de monitorear y proteger la capa donde la intención de la IA se convierte en impacto empresarial. Igual de importante, Salt proporciona visibilidad del contexto más amplio del agente, incluida la comunicación con el LLM. Con el tiempo, se espera que esta visibilidad se expanda aún más al contexto de las barreras de seguridad (guardrails).
Cuando estas señales basadas en API están conectadas, los equipos de seguridad pueden ver la arquitectura completa del agente en un solo lugar: la solicitud del usuario, el tiempo de ejecución del agente, la comunicación del LLM, la actividad de MCP, el uso de herramientas, la actividad del conector y las llamadas a la API posteriores. Ese contexto completo facilita mucho el razonamiento de seguridad. En lugar de investigar eventos desconectados, los equipos pueden entender cómo un agente tomó una decisión, qué intentó hacer y qué sistemas se vieron afectados.
Conclusión
La era de la seguridad agéntica ya está aquí.
Los agentes de IA ya no son interfaces pasivas que solo responden preguntas. Se están convirtiendo en participantes activos en los flujos de trabajo empresariales. Llaman a herramientas, se conectan a servidores MCP, activan API y actúan sobre datos empresariales.
Eso cambia el modelo de seguridad.
Construir muros más gruesos alrededor del LLM no es suficiente. Las barreras de seguridad (guardrails) son importantes, pero no pueden proporcionar visibilidad completa de lo que sucede después de que un agente decide actuar. Para asegurar los sistemas agénticos, las organizaciones necesitan ver la ruta de ejecución completa: desde el prompt al agente, del agente al LLM, del agente al MCP o herramienta, y de la herramienta a la API. En el futuro, el contexto de las barreras de seguridad (guardrails) hará que esa visión sea aún más rica.
La capa de la API es donde esas acciones se hacen visibles. Combinado con la comunicación del LLM, el contexto de MCP, la actividad de las herramientas y el futuro contexto de las barreras de seguridad (guardrails), proporciona a los equipos de seguridad la imagen completa que necesitan para razonar sobre el riesgo e investigar el comportamiento del agente con confianza.
Sus agentes de IA ya están actuando. Salt le ayuda a ver la ruta completa desde el prompt hasta el LLM, MCP, herramientas y API, para que pueda razonar sobre el riesgo con confianza. Solicitar una demostración.