Todo el mundo dice que la IA es insegura, así que lo medí

Si sigue el discurso que rodea la seguridad de la IA hoy en día, se le perdonaría pensar que estamos en el borde de un acantilado existencial.Los títulos y las advertencias de seguridad son implacables, pintando una imagen de un paisaje de amenaza inmediata y sin precedentes. Cada semana trae un nuevo, triste título que parece amplificar la sensación de crisis inminente: “Los agentes de IA pueden ser engañados en sistemas de ataque” Esto a menudo se refiere a la investigación que demuestra cómo los sistemas de IA autónomos, diseñados para realizar tareas útiles, pueden ser manipulados a través de entradas sutiles conocidas como ejemplos adversarios o técnicas de jailbreaking para realizar acciones maliciosas, eludir las guarniciones de seguridad o incluso lanzar ataques sofisticados contra la infraestructura subyacente. “Los LLMs permiten nuevos ciberataques” Esto cubre la doble amenaza planteada por los Grandes Modelos de Idiomas (LLM). La principal preocupación es que los LLM pueden bajar la barrera para entrar en el cibercrimen al ayudar a los novatos a diseñar correos electrónicos de phishing altamente convincentes, generar código de explotación o realizar reconocimiento. En segundo lugar, hay una preocupación de que los atacantes puedan usar los LLM como un componente en sus ataques, aprovechándolos para automatizar campañas de ingeniería social complejas y adaptativas o para descubrir y crear dinámicamente cargas de pago de día cero. “La inyección rápida es la nueva inyección SQL” Esta analogía destaca la nueva clase de vulnerabilidad específica para los sistemas de IA. Al igual que la inyección de SQL explota un fracaso en sanitar la entrada de usuario destinada a una base de datos, la inyección de prompt explota un fracaso en aislar adecuadamente las instrucciones de un usuario (el "prompt") de las instrucciones de operación internas del modelo. Esto permite a un atacante tomar el control del comportamiento del modelo, lo que conduce a la exfiltración de datos, acciones no autorizadas o violación de las políticas. La implicación acumulativa de este flujo constante de noticias negativas y análisis impulsado por el miedo a menudo es la misma: la propia IA es el problema.La narración tiende a centrarse en la inherente inestabilidad, impredecibilidad y riesgo asociado con la tecnología principal, lo que conduce a la creencia de que la tecnología debe ser contenida, estrictamente regulada o fundamentalmente rediseñada para ser segura. Como alguien que ha pasado años analizando el comportamiento de los atacantes del mundo real, este marco siempre se ha sentido incompleto. La mayoría de las afirmaciones se basan en hipótesis, ejemplos de juguetes o demostraciones intencionalmente inseguras. Muy pocos hacen una pregunta más simple: ¿Qué superficie de ataque está realmente expuesta por las integraciones de IA reales de hoy? Por qué el MCP es una comprobación de realidad útil El surgimiento de sofisticados modelos lingüísticos ha necesitado el desarrollo de mecanismos robustos y estandarizados para la interacción con recursos externos. Se ha introducido, estableciendo un marco crucial y estandarizado que permite a los modelos de idiomas invocar herramientas y servicios externos de manera segura y previsible. Protocolo de modelo de contexto (MCP) Protocolo de modelo de contexto (MCP) Este protocolo actúa como un intermediario seguro, permitiendo que el modelo de lenguaje amplíe sus capacidades más allá de sus conocimientos internos y límites computacionales. En esencia, el MCP es vital para transformar modelos de lenguaje de procesadores de texto sofisticados en agentes capaces e interactivos que pueden realizar tareas del mundo real mediante la integración segura y contextual con el ecosistema digital más amplio. Metodología de Investigación Este análisis evitó deliberadamente configuraciones especulativas o adversarias.El diseño del estudio empleó una metodología conservadora que involucra cinco pasos clave: Identificación de repositorio: Los repositorios de servidores MCP se localizaron analizando los patrones de importación de SDK encontrados en GitHub. Verificación de ejecución: Los repositorios que no comenzaron con éxito fueron excluidos del análisis. Análisis de herramientas: Los servidores que funcionaron con éxito extrayeron sus herramientas y esquemas expuestos. Mapeo de capacidades: Las herramientas se clasificaron en función de sus acciones potenciales (es decir, lo que pueden hacer), independientemente de si contenían vulnerabilidades conocidas. Clasificación de servidores: Los servidores fueron finalmente agregados y clasificados según la densidad y el tipo de capacidades expuestas que contenían. Sólo se incluyeron los servidores MCP que realmente se ejecutaron y las herramientas expuestas, ya que una superficie de ataque que no ejecuta no es una superficie de ataque. Lo que los servidores MCP realmente exponen Una vez que los servidores ejecutables fueron aislados, surgió un patrón claro: los servidores MCP exponen primitivas de seguridad familiares, no capacidades exóticas únicamente de IA. Tabla 1 — Clases de capacidad de MCP observadas: Capability Class Description Filesystem access Read/write operations on files or documents HTTP requests Fetching or scraping remote URLs Database queries Structured data retrieval Process execution Local command or script execution Orchestration Tool chaining, planning, or agent control Read-only search Constrained data or API lookups Acceso al sistema de archivos Leer/escribir operaciones en archivos o documentos Peticiones HTTP Retirar o raspar URLs remotos Bases de datos Queries Recuperación de datos estructurados Proceso de ejecución Comando local o ejecución de scripts Orquesta Cadenas de herramientas, planificación o control de agentes Búsqueda sólo Datos restringidos o búsquedas de API El punto clave aquí es que estos primitivos ya existen en todos los sistemas de software modernos. Distribución de la capacidad a través de servidores MCP reales A pesar de las alegaciones generalizadas de que las herramientas de IA permiten rutinariamente comportamientos peligrosos, la distribución observada fue mucho más restringida. Tabla 2 - Frecuencia de capacidad (servidores MCP ejecutables): Capability Relative Frequency Filesystem access Medium HTTP requests Medium Database queries Low Process execution Rare Orchestration Occasional Acceso al sistema de archivos Medium Peticiones HTTP Medium Bases de datos Queries Bajo Proceso de ejecución Raro Orquesta ocasional La observación: Los hallazgos iniciales sugieren una divergencia significativa de las narrativas predominantes, a menudo alarmistas, sobre la inseguridad inherente de los sistemas avanzados de IA. En concreto, la investigación sobre la explotación práctica de estos sistemas reveló que la ejecución arbitraria de comandos, una capacidad que podría conducir a un compromiso catastrófico del sistema o una violación de datos, fue identificada como la Vulnerabilidad de seguridad de alto impacto. por lo menos Este resultado contraintuitivo desafía directamente a la afirmación generalizada de que los modelos actuales de IA son fundamentalmente "irresponsables" o propensos a vulnerabilidades de alta gravedad fácilmente explotables que otorgan a los atacantes un control profundo sobre la infraestructura subyacente. Mientras que otras vulnerabilidades existen sin duda, la baja frecuencia de fallas de ejecución de comandos implica que las robustas sanitizaciones de entrada, sandboxing y defensas arquitectónicas en lugar pueden ser más eficaces que lo que se reconoce comúnmente. Los datos sugieren que los esfuerzos de seguridad podrían ser más eficaces para abordar las vulnerabilidades comunes de menor impacto que ocurren con mayor frecuencia, en lugar de centrarse predominantemente en los explosivos potenciales más raros, aunque más sensacionales. El riesgo real: la composición de la capacidad Individualmente, muchos servidores parecen inofensivos. El riesgo aumenta cuando múltiples primitivos coexisten en el mismo servidor, especialmente cuando está presente la orquestación. El riesgo de seguridad planteado por un servidor MCP individual a menudo es mínimo o parece inofensivo cuando se ve aislado. Un MCP único, con un alcance estrecho, puede realizar una función necesaria, como administrar un cambio de configuración simple o realizar una operación de registro básico. Sin embargo, el potencial de explotación aumenta dramáticamente cuando se desplegan múltiples servidores y coexisten dentro del mismo servidor o entorno operativo. Este riesgo agravante está enraizado en las posibilidades combinatorias que surgen cuando distintos primitivos pueden ser encadenados o aprovechados en secuencia. Por ejemplo, un servidor MCP podría ser capaz de leer datos de configuración sensibles, mientras que otro podría ser capaz de alterar las reglas del firewall, y un tercero podría ser capaz de reiniciar un servicio crítico. Individualmente, estas acciones son limitadas. Juntos, forman un potente vector de ataque, permitiendo a un atacante escalar privilegios, lograr persistencia y exfiltrar datos. El verdadero punto de inflexión para este riesgo es la introducción de La orquestación, ya sea proporcionada por herramientas de seguridad automatizadas, plataformas de contenedores (como Kubernetes), marcos nativos de la nube o scripting sofisticado, está diseñada para coordinar y gestionar eficientemente estas capacidades distribuidas. Orquesta Un atacante que obtiene el control sobre la capa de orquestación puede dirigir eficazmente una sinfonía de acciones maliciosas, convirtiendo una colección de primitivos inofensivos en un poderoso sistema de armas automatizadas. Tabla 3 – Exemplos de patrones de composición: Composition Security Implication HTTP fetch + filesystem write Content injection / persistence Database query + orchestration Data exfiltration pipelines HTTP fetch + planning Prompt-injection amplification Filesystem write + orchestration Supply-chain style poisoning HTTP FETCH + Sistema de archivos Injeción de contenido / Persistencia Base de datos + Orquestación Pipelines de exfiltración de datos HTTP FETCH + Planificación Amplificación de inyección rápida Sistema de archivos + orquestación Envenenamiento en cadena de suministro MCP no está inventando estas cadenas; simplemente hace que sea mucho más fácil ponerlas juntas. Esquemas, No Prompts, Define la superficie de ataque Un tema recurrente en las discusiones de seguridad de la IA, especialmente en el ámbito de los LLMs, es la vulnerabilidad a la manipulación instantánea, a menudo sensacionalizada como "injección instantánea".Este enfoque, aunque comprensible dada su directez, a menudo sombra defectos de seguridad más sistémicos e impactantes.En la práctica, nuestra investigación y la experiencia de la industria más amplia han demostrado consistentemente que los esquemas importan mucho más que los simples ataques basados en prompt. El esquema en este contexto se refiere a todo el marco operativo: la arquitectura, los modelos de datos subyacentes, los controles de acceso, la lógica de orquestación, y los pasos de pre- y post-procesamiento que envuelven alrededor del LLM principal.Un atacante sofisticado no se centrará en coaccionar una ligera desviación de la salida del modelo a través de un prompt inteligente. Por ejemplo, un esquema inseguro podría: Permitir la llamada de funciones sin control: Si el esquema permite al LLM llamar APIs o funciones externas sin validación de entrada robusta y principios de menor privilegio, un ataque de inyección exitoso permite el movimiento lateral, la exfiltración de datos o la ejecución arbitraria de comandos. Falta de separación de contexto e instrucción: La mezcla de la entrada del usuario (el prompt) con las instrucciones del sistema o el contexto operativo de una manera que permita a la entrada del usuario hackear las directivas del sistema es un fallo de esquema. Uso de entradas/salidas insuficientemente validadas en sistemas de generación aumentada de recuperación (RAG): Si los documentos recuperados no son sanitizados adecuadamente antes de ser enviados de vuelta al contexto prompt, o si el sistema ejecuta ciegamente los pasos de postprocesamiento basados en la salida, el vector de ataque oculta las defensas del modelo central. En esencia, mientras que la inyección rápida demuestra que el LLM es un validador de entrada complejo y no determinista, los graves riesgos críticos para el negocio están enraizados en la fragilidad del esquema.Segurar los sistemas de IA requiere cambiar el enfoque de la seguridad de las técnicas de exhortación puramente defensivas a la adopción de sonido, la instalación de software tradicional, la aplicación de principios de seguridad en toda la pila de aplicaciones de IA y el tratamiento del LLM como un componente de un sistema más grande, interconectado y potencialmente vulnerable. Tabla 4 - Impacto del esquema de restricción: Schema Pattern Risk Implication url: string High (arbitrary network access) path: string High (potential traversal / overwrite) query: string Medium (depends on backend) enum(values) Low (constrained intent) Hard-coded parameters Minimal Categoría: String Alta (acceso arbitrario a la red) Título: String Alta (potencia de travesaje / sobreescritura) Categoría: String Medium (dependiendo del backend) enum (valores) Bajo (intención restringida) Parámetros de código duro El mínimo En los servidores MCP, el esquema es el límite de confianza.Si una herramienta acepta una entrada ilimitada y la pasa a un potente sink, el riesgo es arquitectónico, no impulsado por la IA. Por qué esta no es una historia de "AI es peligrosa" La discusión generalizada que proclama que la IA introduce un "riesgo sin precedentes" a menudo pierde la realidad más matizada y arquitectónicamente significativa. o En cambio, la consecuencia profunda de la integración de la IA, particularmente en forma de LLMs y agentes inteligentes, es que la IA cambia fundamentalmente la ubicación donde se toman y ejecutan decisiones esenciales de seguridad. Nuevo Inmanente Esta no es una simple actualización incremental a los modelos de seguridad existentes; representa un profundo cambio arquitectónico en la forma en que se construyen y defienden las aplicaciones. FROM: The Traditional Application Security Focus TO: The Modern AI-Driven System Security Focus UI Flows (User Interface) Schemas (Data and Interaction) Security was heavily focused on validating inputs and protecting against manipulation of front-end components and presentation layers. The emphasis moves to strictly defining and validating the structure and content of data exchanged between models, tools, and the application, ensuring input and output types are rigorously adhered to. Human Intent and Manual Vetting Tool Composition and Orchestration Logic was often designed around what a human to do, relying on role-based access control (RBAC) and explicit permissions tied to individual actions or user profiles. intended Security now centers on how the AI agent selects, chains, and uses various external tools (e.g., APIs, databases, services). The integrity and safety of the of actions must be guaranteed, focusing on preventing prompt injection from driving unintended tool use. entire sequence Application Logic (Hard-Coded Business Rules) Execution Context Isolation (Sandboxing) Security resided within monolithic or tightly coupled business logic, where rules were explicitly coded and easy to audit within the application's source code. The focus shifts to isolating the AI model's runtime environment, ensuring that the consequences of any erroneous or malicious model output (e.g., code generation or external calls) are strictly contained and cannot impact critical infrastructure or bypass perimeter defenses. Flujos de usuario (User Interface) Esquemas (Datos e Interacciones) La seguridad estaba fuertemente enfocada en la validación de las entradas y la protección contra la manipulación de los componentes frontales y las capas de presentación. El énfasis se mueve a definir y validar estrictamente la estructura y el contenido de los datos intercambiados entre modelos, herramientas y la aplicación, asegurando que los tipos de entrada y salida se adhieran estrictamente. Intención humana y vigilancia manual Composición y orquestación de instrumentos La lógica se desarrolló a menudo en torno a lo que un ser humano para hacer, confiando en el control de acceso basado en roles (RBAC) y permisos explícitos vinculados a acciones individuales o perfiles de usuario. Intentado La seguridad ahora se centra en cómo el agente de IA selecciona, cadena y utiliza varias herramientas externas (por ejemplo, APIs, bases de datos, servicios). Las acciones deben garantizarse, centrándose en evitar que la inyección rápida conduzca al uso no intencionado de la herramienta. Toda la secuencia Lógica de Aplicaciones (Reglas de Negocios Hardcoded) Aislamiento de Contexto (Sandboxing) La seguridad residió dentro de una lógica de negocio monolítica o estrechamente ligada, donde las reglas estaban explicitamente codificadas y fáciles de auditar dentro del código fuente de la aplicación. El enfoque se desplaza a aislar el entorno de ejecución del modelo de IA, asegurando que las consecuencias de cualquier salida de modelo errónea o maliciosa (por ejemplo, generación de código o llamadas externas) están estrictamente contenidas y no pueden afectar a la infraestructura crítica o eludir las defensas del perímetro. Este desplazamiento del locus de seguridad es un cambio arquitectónico, no sólo un reflejo del fracaso en las prácticas de seguridad existentes.Requiere que las organizaciones adapten sus estrategias defensivas, herramientas de seguridad y capacitación de desarrolladores para abordar estos nuevos puntos de control.Reconociendo que el límite de seguridad primario ya no es la puerta de entrada de la aplicación, sino la configuración y gestión de la propia tubería de inteligencia. Conclusión: Medir primero, pánico después El discurso generalizado en torno a la seguridad de la IA a menudo está dominado por los escenarios de peores casos hipotéticos y de miedo.No obstante, para los practicantes, mejorar el estado de la seguridad de la IA requiere un cambio de perspectiva: debemos reemplazar el miedo con la medición y la disciplina pragmática. Los LLM y otros complejos sistemas de procesamiento controlados por IA/máquina no son inherentemente inseguros; son simplemente sistemas ricos en capacidades.Esta abundancia de funcionalidad significa que requieren el mismo enfoque riguroso y disciplinado para la modelización de amenazas, la configuración segura y la supervisión operativa que ya aplicamos a otras infraestructuras críticas como las pipelines de automatización y las API en la nube. La incómoda pero finalmente empoderante verdad es que un número significativo de los llamados "riesgos" de la IA son, en realidad, viejos problemas de seguridad que usan un nuevo lenguaje.Conceptos como estándares inseguros, vulnerabilidades en la cadena de suministro, fallas de inyección y controles de acceso mal configurados han sido preocupaciones fundamentales durante décadas. Y eso es una buena noticia. Es una buena noticia porque significa que no estamos empezando desde cero.Ya sabemos cómo resolver estos problemas.Los principios de seguridad establecidos, marcos y metodologías, como el Principio de Privilegios Menos Importantes (PoLP) y la arquitectura de defensa en profundidad, siguen siendo perfectamente válidos.El desafío no es inventar una nueva ciencia, sino adaptar sistemáticamente la experiencia de seguridad existente a las nuevas superficies de ataque y características del sistema introducidas por la IA. Al enmarcar la seguridad de la IA como una extensión de la seguridad empresarial establecida en lugar de un problema completamente nuevo e insuperable, las organizaciones pueden pasar de la ansiedad paralizante a la reducción de riesgos efectiva y mensurable.