Keyfactor Days 2027, la conferencia sobre seguridad de confianza, llega a San Diego!   Descubre lo que se avecina

Definición

La identidad de IA es una representación verificable de un agente de IA que establece quién o qué es dicho agente dentro de un entorno digital. Permite a los sistemas autenticar al agente, determinar sus permisos y acciones autorizadas, y asociar dichas acciones a una entidad de confianza. La identidad de IA sienta las bases para la rendición de cuentas, la gobernanza y la revocación, lo que permite a los agentes autónomos operar de forma segura dentro de los sistemas empresariales.

Los sistemas autónomos se están convirtiendo en participantes activos en los entornos empresariales, tomando decisiones y llevando a cabo acciones que pueden afectar a los datos, la infraestructura y las operaciones empresariales. A diferencia software tradicional, los agentes de IA pueden interpretar instrucciones de forma dinámica, acceder a los sistemas, interactuar con otros agentes y operar con un alto grado de independencia. Por lo tanto, las organizaciones necesitan una forma fiable de saber qué agente está actuando, qué está autorizado a hacer y si se puede confiar en sus acciones. Una identidad verificable sienta las bases para la autenticación, la autorización, la rendición de cuentas y la revocación, lo que permite a las organizaciones implementar la IA de forma segura a gran escala. Sin ella, los agentes autónomos se convierten en actores poderosos, pero en gran medida sin control, que operan dentro de redes de confianza, lo que aumenta el riesgo de uso indebido, vulnerabilidades y consecuencias no deseadas. 

La IA ha entrado en la era de la confianza 

La pregunta que se plantean las organizaciones sobre la IA ha cambiado. Ya no es «¿qué puede hacer?». Ahora la pregunta es «¿quién es?». 

Los agentes de IA han ido más allá rápidamente de la mera generación de respuestas a indicaciones. Ahora perciben su entorno, toman decisiones autónomas y llevan a cabo acciones en los sistemas de la empresa, como iniciar flujos de trabajo, acceder a bases de datos confidenciales, llamar a API, coordinarse con otros agentes a la velocidad de una máquina, etcétera. Este cambio de la automatización a la autonomía no es gradual. Los sistemas automatizados siguen instrucciones. Los sistemas agenticos las interpretan. Los sistemas automatizados operan dentro de límites estáticos. Los sistemas agenticos los traspasan de forma dinámica. 

Esa distinción es importante porque cambia radicalmente la naturaleza del riesgo. Los responsables de seguridad consideran que, en los próximos años, las vulnerabilidades relacionadas con la IA supondrán una amenaza mayor que el uso indebido por parte de los seres humanos. Además, pocos de ellos creen que podrían impedir que un agente de IA rebelde causara daños antes de que estos se produzcan. 

La brecha entre la velocidad de implementación de la IA y la preparación en materia de identidad es cada vez mayor. Las organizaciones están implementando agentes de IA en entornos de producción, al tiempo que siguen basándose en modelos de identidad diseñados para personas y aplicaciones predecibles. El resultado es una categoría cada vez mayor de agentes autónomos que operan dentro de los límites de confianza de la empresa sin que existan controles de identidad acordes con sus capacidades. 

La identidad es la línea divisoria entre la innovación en IA y el riesgo de la IA. Es el plano de control fundamental que determina si los agentes autónomos pueden ser autenticados, autorizados, rastreados y revocados. Sin ella, todos los demás controles de seguridad se debilitan. 

¿Qué es la identidad basada en la IA y por qué es importante? 

La identidad basada en IA permite autenticar, autorizar, rastrear y revocar de forma única el acceso y las acciones de un agente autónomo. Permite responder a la pregunta de seguridad más básica sobre cualquier actor en un entorno empresarial:¿qué entidad ha realizado esta acción y bajo qué autoridad? 

Los agentes de IA no se ajustan a los modelos de identidad existentes, diseñados para usuarios humanos o aplicaciones tradicionales. Aportan características que hacen que la identidad sea a la vez más crucial y más difícil de gestionar: 

  • Persistencia y dinamismo.
    Los agentes de IApueden ser servicios de larga duración o trabajadores efímeros que existen durante unos minutos. Algunos persisten a lo largo de varias sesiones, acumulando contexto y autoridad con el tiempo. Otros se activan para una única tarea y se desactivan inmediatamente después. Los modelos de identidad deben adaptarse a ambos patrones. 
  • Escala.
    Las organizaciones pueden implementar cientos o miles de agentes de IA simultáneamente en diferentes flujos de trabajo, lo que plantea retosde gestión de identidadesque superan con creces los de los sistemas tradicionales centrados en el usuario. 
  • Autonomía.
    Los agentes toman decisiones en tiempo real sin supervisión humana. No esperan a recibir autorización antes de actuar, y su valor reside en su capacidad de adaptación. Esta es precisamente la característica que los sistemas de seguridad suelen señalar como sospechosa. 
  • Acceso entre sistemas.
    Un único agente puede interactuar con múltiples API, bases de datos y servicios en el transcurso de una sola tarea. A diferencia de un usuario humano, que suele trabajar con unas pocas aplicaciones, el alcance de acceso de un agente puede abarcar toda la empresa en cuestión de segundos. 
  • Solicitudes indistinguibles.
    A nivel de la API, no existe ninguna forma fiable de que una aplicación empresarial distinga entre una entrada generada por IA y una entrada humana. Cuando un agente realiza una llamada a la API, la solicitud parece idéntica a la de un usuario humano. 

La siguiente analogía (procedente de la biología) resulta útil para comprender el panorama. Para que un organismo vivo sobreviva, debe percibir su entorno, identificar amenazas, seleccionar respuestas y ejecutarlas. Esto requiere lo que los investigadores describen como un «yo»: un modelo de uno mismo como agente causal entre otros agentes causales. Un LLM contiene un sofisticado motor de juicio, pero una IA puramente generativa no es un agente causal. Solo adquiere ese estatus cuando empieza a percibir y a actuar a través de protocolos como el MCP, interpretando su entorno, tomando decisiones y actuando. 

La misma expectativa que se aplica a cualquier agente humano debería aplicarse también a un agente de IA: si está continuamente percibiendo, evaluando y actuando, debería tener su propia identidad única y unas credenciales vinculadas a dicha identidad. 

El problema de las credenciales estáticas: por qué las claves de API y las contraseñas no son suficientes 

Los mecanismos de autenticación tradicionales (como las claves de API, los secretos de cliente de OAuth, las contraseñas y los tokens estáticos) se diseñaron para una época diferente. Resultan ineficaces en entornos de IA en múltiples aspectos. 

No hay una verificación fiable del origen.
Las credenciales estáticas no permiten determinar el verdadero origen de una acción. Un usuario que no comprenda los patrones de interacción esperados podría pegar un secreto de cliente de OAuth en un chat de IA, exponiéndolo potencialmente como datos de entrenamiento de un modelo de lenguaje grande (LLM). Un agente podría extraer una clave de API de un archivo de configuración que haya rastreado. En ambos casos, no existe una forma fiable de garantizar que cada acción se autorice de manera tan sólida que el autor no pueda negarla. Por lo tanto, el principio fundamental de seguridad de la no repudio se viene abajo. 

Deficiencias en la inspección y la gestión.
Por lo general, las claves estáticas no pueden asignarse a un sujeto específico mediante una simple inspección. Sin un contexto adicional, no es posible distinguir las claves legítimas y operativas de las claves no válidas o no fiables. El secreto en sí mismo no contiene información sobre la política en virtud de la cual se emitió, y no existen controles uniformes para garantizar la rotación adecuada de las credenciales. 

No hay protección de datos.
Los secretos de cliente no proporcionan cifrado. Aunque una credencial estática fuera adecuada para la verificación de identidad, no protegería los datos en tránsito. 

Peligroso a escala de IA.
Estas deficiencias, que pueden gestionarse en implementaciones limitadas y centradas en el ser humano, se vuelven peligrosas cuando se ven amplificadas por agentes de IA que operan a la velocidad de las máquinas. Un agente comprometido puede desplazarse lateralmente por los sistemas sin vacilar. Un agente mal configurado puede sobrepasar los límites de formas que, desde fuera, parecen un abuso deliberado. 

En la actualidad, la mayoría de las organizaciones utilizan claves API, claves simétricas o tokens estáticos. Solo aproximadamente una de cada dos utiliza certificados digitales para la identidad de los agentes de IA. Esta combinación de enfoques refleja un momento de transición. La mayoría de las organizaciones reconocen la necesidad de una identidad más sólida, pero muchas siguen recurriendo a mecanismos que nunca se diseñaron para un comportamiento autónomo. 

Lo que más preocupa a algunos expertos no es una IA maliciosa, sino más bien una IA en la que se confía en exceso. Muchas implementaciones de IA reintroducen silenciosamente los mismos antipatrones sobre los que el sector de la seguridad lleva años advirtiendo —credenciales codificadas de forma fija, secretos compartidos y accesos de larga duración— en nombre de la rapidez y la experimentación. 

Identidad basada en certificados: la base de la confianza en la IA 

Los certificados digitales X.509 resuelven los problemas que las credenciales estáticas no pueden resolver. Son el estándar más extendido en materia de certificados digitales y proporcionan la base criptográfica que necesitan los agentes de IA para funcionar de forma segura a escala empresarial. 

Los certificados ofrecen seis características fundamentales de las que carecen las credenciales estáticas: 

  • Origen no repudiable.
    Cada acción puede rastrearse hasta un titular de certificado concreto. No hay ninguna ambigüedad sobre qué entidad ha realizado una acción. 
  • No se pueden compartir accidentalmente.
    Las claves privadas pueden permanecer almacenadas de forma segura en un módulo Hardware (HSM) o en un almacén gestionado por el sistema operativo, sin aparecer nunca en los registros de chat ni en los archivos de configuración. 
  • Gestión integrada del ciclo de vida.
    Los certificados tienen una vigencia definida y pueden revocarse de inmediato en caso de que se vean comprometidos. La caducidad es una característica, no un fallo del sistema. 
  • Aplicación de políticas.
    Las extensiones de los certificados pueden codificar políticas y restricciones de autorización específicas, como a qué sistemas puede acceder el agente, qué operaciones está autorizado a realizar, restricciones temporales y requisitos de cumplimiento. El propio certificado se convierte en un punto de aplicación de políticas. 
  • Autenticación mutua.
    Las dos partes que participan en una comunicación verifican criptográficamente la identidad de la otra, lo que elimina la posibilidad de suplantación de identidad. 
  • Cifrado en tránsito.
    Los certificados no solo identifican los dispositivos finales, sino que también proporcionan un canal seguro para la transmisión de datos. 

La infraestructura de clave pública (PKI) es el sistema que emite, gestiona y valida estos certificados a gran escala. La PKI proporciona la base criptográfica necesaria para establecer y mantener identidades seguras en todo el ecosistema de agentes de una organización. 

Las implementaciones modernas de OAuth están sustituyendo cada vez más los secretos estáticos por certificados de cliente, lo que se traduce en una autenticación de cliente más sólida. En el caso de la IA interactiva (en la que un humano trabaja junto a un agente de IA a través de protocolos como MCP), el certificado de cliente del usuario se autentica ante el proveedor de identidad, que emite tokens de acceso OAuth con un ámbito de autorización específico. Las acciones de la IA se llevan a cabo bajo la autoridad delegada por el usuario, con un registro de auditoría completo. En el caso de los agentes autónomos, el propio certificado de carga de trabajo del agente se autentica directamente, y el proveedor de identidad emite tokens basados en el ámbito de autorización preconfigurado del agente. 

Este enfoque elimina los riesgos asociados a los secretos de cliente estáticos, al tiempo que conserva la escalabilidad y la flexibilidad de los marcos OAuth modernos. 

En el caso de las cargas de trabajo de IA en contenedores, SPIFFE (Secure Production Identity Framework for Everyone) automatiza todo el ciclo de vida de los certificados. Cada contenedor recibe un identificador SPIFFE único; el entorno de ejecución emite automáticamente certificados X.509 de corta duración; TLS establece automáticamente TLS mutuo entre las cargas de trabajo; y la gestión de certificados no supone ninguna sobrecarga operativa, ni siquiera en el caso de los agentes efímeros que solo existen durante unos minutos. 

Ampliar el modelo «Zero Trust» a la IA: «Nunca confíes, verifica siempre» para los agentes no humanos 

La arquitectura «Zero Trust» se basa en un principio fundamental: nunca confiar, siempre verificar. Cada enlace de comunicación requiere que ambas partes estén autenticadas y autorizadas, independientemente de la dirección de red o del historial de acceso previo. Si bien el modelo «Zero Trust» se ha centrado tradicionalmente en los usuarios humanos y las aplicaciones conocidas, el auge de la IA con agentes exige que el modelo se amplíe a los sistemas autónomos. 

En un entorno «Zero Trust» protegido mediante PKI, toda entidad —ya sea una persona, un agente de IA, un servicio o un dispositivo— debe presentar una prueba criptográfica de su identidad antes de acceder a los recursos: 

  • Los agentes de IA necesitan certificados, al igual que los usuarios humanos. 
  • Todas las llamadas a la API realizadas por un agente de IA deben estar sujetas a autenticación mediante certificado. 
  • La comunicación entre agentes requiere autenticación TLS mutua TLS mTLS). 
  • El acceso a los recursos se rige por políticas basadas en la identidad, y no por claves API ni controles de red. 

Sobre esta base, el modelo «Zero Trust» pasa de ser una filosofía de seguridad de red a convertirse en un marco operativo para la autonomía. Cada acción que realiza un agente puede autenticarse y autorizarse en el mismo instante en que se produce. Cada conexión, ya sea entre un agente y una base de datos o entre dos agentes, puede verificarse mediante mTLS. Cuando un agente se comporta de forma anómala o su comportamiento cambia de forma inesperada, su identidad puede revocarse al instante, aislando el riesgo sin afectar al resto de cargas de trabajo. 

Dónde falla el modelo tradicional de «Zero Trust» 

El modelo tradicional de «Zero Trust» parte de supuestos centrados en el ser humano, como, por ejemplo, horarios de trabajo predecibles, patrones de comportamiento estables, una velocidad propia de los seres humanos, señales de confianza basadas en los dispositivos, etc. Los agentes de IA incumplen estos supuestos de varias maneras: 

La identidad pasa a basarse en el comportamiento, y no solo en las credenciales.
Un ser humano tiene una identidad estable gracias al inicio de sesión único (SSO), los certificados y la autenticación multifactorial (MFA). Un agente de IA que ejecuta llamadas a herramientas puede compartir una misma credencial en todas las invocaciones. El modelo «Zero Trust» para la IA debe incorporar una capa de identidad basada en el comportamiento. La trayectoria de acciones del agente (es decir, su historial) pasa a formar parte de su puntuación de confianza. 

El principio del privilegio mínimo debe limitarse al ámbito de la intención, no solo al ámbito del rol. 
En el caso de las personas, las organizaciones conceden «acceso de lectura al depósito de almacenamiento X». En el caso de los agentes de IA, el acceso debe limitarse a la intención de la tarea. Es decir, el agente solo debería invocar aquellas herramientas que sean razonablemente necesarias para la tarea que ha declarado. Esto requiere una capa de políticas que comprenda no solo las listas de control para acceder a los recursos, sino también el contexto de cada tarea. 

Reevaluación continua durante la ejecución de la acción.
Los seres humanos realizan acciones discretas y cierran sesión. Los agentes de IA ejecutan cadenas de llamadas a herramientas en las que el perfil de riesgo cambia a lo largo de la cadena. El modelo «Zero Trust» para la IA requiere una reevaluación de las políticas durante la sesión. Tras cada llamada a una herramienta, el sistema debe volver a evaluar si la siguiente acción solicitada se mantiene dentro de los límites de confianza, teniendo en cuenta lo que ya ha ocurrido. 

La instrucción es una superficie de ataque.
No existe un equivalente humano a la inyección de instrucciones. El modelo «Zero Trust» para la IA debe considerar que el propio canal de entrada no es de confianza. Un documento recuperado o una respuesta de una API externa pueden contener instrucciones maliciosas que intenten elevar los privilegios de un agente en mitad de una tarea. 

Estas adaptaciones suponen una evolución significativa de los principios del modelo «Zero Trust», pero no alteran el marco básico. Lo amplían para dar cabida a agentes cuyo valor radica en la adaptabilidad y la autonomía. 

Gestión de la identidad de la IA a gran escala: ciclo de vida, automatización y observabilidad 

La realidad operativa que supone gestionar la identidad de lo que podrían ser miles de agentes de IA de corta duración obliga a la PKI a evolucionar en tres aspectos clave. 

Vidas útiles más cortas 

Los agentes de IA rara vez necesitan una identidad a largo plazo. Los certificados de corta duración (aquellos válidos durante minutos u horas, en lugar de meses) reducen la exposición y limitan el alcance del impacto cuando se ven comprometidas las credenciales. En la mayoría de los casos, no es necesario que un certificado tenga una vigencia superior a la del agente al que se le ha expedido. La caducidad se convierte en una medida de seguridad, ya que elimina automáticamente las credenciales que ya no son necesarias. 

Automatización total 

La gestión manual de certificados resulta insostenible casi de inmediato a la escala de la IA. La emisión, renovación, rotación y revocación deben automatizarse de principio a fin. Los certificados deben emitirse automáticamente como parte de los procesos de implementación de agentes, las plataformas de orquestación o los flujos de trabajo de admisión en redes en malla. La intervención humana en las operaciones rutinarias de identidad, sencillamente, no es escalable. 

Identidad basada en políticas 

Las decisiones de autorización deben integrarse en las políticas de identidad y en las plantillas de certificados, en lugar de gestionarse mediante excepciones y controles manuales. Las plantillas de certificados pueden incorporar las capacidades y limitaciones de los agentes, lo que garantiza que la aplicación de las políticas se produzca en el nivel de identidad, y no como una medida de última hora. 

Las mallas de servicios como capas de aplicación 

Las mallas de servicios se están imponiendo como un punto de control práctico para la identidad de las cargas de trabajo, incluidos los agentes de IA. Se sitúan en una capa de aplicación natural en las implementaciones en contenedores, donde pueden distinguir una carga de trabajo de otra, observar qué cargas de trabajo se están comunicando, aplicar TLS mutuo TLS predeterminada, validar las afirmaciones de identidad de las cargas de trabajo y regular qué identidades pueden interactuar entre sí. 

En este contexto, la emisión de certificados pasa a formar parte de la admisión y la coordinación de la carga de trabajo, en lugar de ser un proceso de seguridad independiente. 

Clasificación de agentes 

No todos los agentes de IA son iguales. Las organizaciones deberían clasificar a sus agentes en función de cuatro dimensiones: 

  • Privilegios de acceso:
    qué sistemas y datos pueden manejar 
  • Facultad de decisión:
    qué medidas pueden adoptar sin la aprobación de una persona 
  • Exposición al riesgo:
    el impacto potencial en caso de que el agente se vea comprometido 
  • Vida útil:
    , tanto si se trata de servicios persistentes como de trabajadores efímeros 

Los agentes con privilegios elevados y de larga duración requieren políticas de certificados más estrictas y una supervisión más frecuente que los agentes de alcance limitado y de corta duración. 

Observabilidad centrada en la identidad 

Los registros, la telemetría y las alertas deben estar vinculados a una identidad criptográfica para que las acciones puedan atribuirse con precisión. Si no puedes determinar qué agente realizó una acción, no tienes un control significativo. La observabilidad centrada en la identidad cierra la brecha entre lo que ocurrió y quién lo hizo. 

Gobernanza y cumplimiento normativo en materia de identidad con IA 

La gestión de identidades basada en la inteligencia artificial se está convirtiendo en uno de los ámbitos más importantes y menos desarrollados de la seguridad empresarial. 

La situación actual 

En la actualidad, solo una de cada dos organizaciones ha implantado plenamente marcos de gobernanza para los agentes de IA. La otra mitad se encuentra todavía en fases de planificación o de debate informal. Esta división refleja que nos encontramos en un momento de transición. La adopción de la IA se está acelerando, pero la madurez en materia de gobernanza es desigual. 

El riesgo no es que las organizaciones no sean conscientes del problema, sino que la puesta en práctica va a la zaga de la realidad operativa. 

 Esta proporción también se refleja en el número de dirigentes que se toman en serio estas amenazas. Esa brecha pone de manifiesto una tensión más profunda en la gobernanza: el riesgo relacionado con la IA suele reconocerse a nivel técnico antes de que se asuma plenamente a nivel ejecutivo. 

Mientras tanto, las expectativas en torno a la resiliencia siguen siendo bajas. Pocos expertos en seguridad creen que podrían detener a un agente de IA rebelde antes de que se produzcan daños. Por el contrario, la mayoría prevé que la detección o la respuesta solo se producirán una vez que el incidente ya haya comenzado, y a menudo consideran que las vulnerabilidades originadas por la IA suponen una amenaza mayor a corto plazo que el uso indebido por parte de los seres humanos. 

Los riesgos operativos de la autonomía 

Los agentes de IA heredan permisos que se diseñaron pensando en la comodidad, no en la rendición de cuentas. El acceso «temporal» tiene un largo historial de acabar convirtiéndose en permanente. Con los agentes autónomos, esas concesiones se vuelven peligrosas. 

El principio del privilegio mínimo en la era de los agentes no es una política estática. Se trata de una negociación en tiempo real entre las capacidades y las restricciones. Requiere una asignación dinámica de privilegios, una sólida percepción del contexto y una validación continua de la intención. Además, obliga a enfrentarse a una pregunta que subyace en todo debate sobre gobernanza: ¿quién es responsable cuando un agente autónomo hace un uso indebido del acceso? 

Rotación de identidades y evidencia continua 

Los agentes de corta duración generan una rotación de identidades que los modelos de gobernanza tradicionales nunca fueron diseñados para gestionar. Las identidades pueden existir durante minutos o segundos, lo que requiere una emisión y rotación continuas, revocaciones frecuentes sin interrupción del servicio y grandes volúmenes de tráfico este-oeste entre los agentes. 

Los equipos de riesgo y cumplimiento normativo necesitarán cada vez más pruebas continuas, en lugar de controles puntuales. Los auditores están desplazando su atención del diseño de los modelos al comportamiento operativo: cómo se autentifica un agente de IA antes de actuar, cómo se registran y atribuyen sus acciones, con qué rapidez se le puede revocar el acceso y si las decisiones pueden reconstruirse a posteriori. 

La convergencia que se avecina 

En la actualidad, la gobernanza de la IA suele desarrollarse en paralelo a los programas de seguridad e identidad. En los próximos años, esa separación desaparecerá. La identidad se convertirá en el nexo de unión entre el control de acceso, la aplicación de las medidas de seguridad, la gestión de riesgos y la supervisión del ciclo de vida. 

Para finales de la década, la gobernanza de la IA ya no será una iniciativa aislada. Se integrará en las arquitecturas de identidad y seguridad de las empresas, ya que es ahí donde ya existe un control efectivo. 

Como señala un experto en regulación: «La gobernanza sin controles de identidad exigibles es gobernanza solo de nombre». Marcos como el NIST AI RMF, la norma ISO/IEC 42001 y la Ley de IA de la UE dependen todos de la capacidad de rastrear, atribuir y auditar las acciones de la IA. Cada uno de ellos da por sentado que las organizaciones pueden identificar qué agente de IA actuó y bajo qué autoridad. Para los reguladores, la madurez desigual suele ser un precursor de los mandatos formales. El margen para sentar las bases de la identidad antes de que la regulación se endurezca ya se está reduciendo. 

Nuevas fronteras: MCP, Vibe Coding y PKI asistida por IA 

Tres dimensiones de futuro de la identidad basada en la IA ilustran la rapidez con la que está evolucionando el panorama. 

Protocolo de contexto del modelo (MCP): dotar a la IA de «ojos y manos» 

MCP es el protocolo que transforma un modelo de lenguaje grande (LLM) de un motor generativo en un agente autónomo. Desarrollado por Anthropic y cedido a la fundación open-source AI Foundation, MCP integra la IA en los sistemas empresariales, lo que permite a los agentes leer recursos compartidos, ajustar configuraciones, interactuar con aplicaciones de negocio e integrar múltiples herramientas en flujos de trabajo complejos. 

La magnitud es impresionante: solo en el primer año de MCP, se crearon más de 17 000 servidores MCP. A medida que las organizaciones amplían sus cargas de trabajo basadas en agentes, MCP se está convirtiendo en una capa fundamental, y no en una tecnología marginal. Los expertos y los profesionales del sector creen que MCP está llamado a convertirse en «el HTTP de la era de la IA». Y, al igual que ocurrió con el HTTP en su momento, necesita una capa de identidad y cifrado para estar preparado para su uso empresarial. 

Es fundamental proteger los servidores MCP mediante TLS mutuo TLS autenticación basada en certificados. Un servidor MCP expone funciones de API a la IA, y esta puede utilizar sus capacidades de lenguaje natural para leer la documentación del servidor y utilizar las operaciones disponibles de forma dinámica, al margen de cualquier secuencia preprogramada. Esto significa que los servidores MCP deben protegerse con una autenticación adecuada basada en certificados, ya que el cliente de IA es, en la práctica, un usuario de la aplicación que genera un tráfico que la aplicación no puede distinguir de las acciones de un ser humano. 

Estilo e identidad 

En la jerga actual, el «vibe coding» es un término que se utiliza para describir el proceso de escribir código mediante indicaciones en lenguaje natural, en lugar de pulsaciones de teclas. Los desarrolladores describen lo que quieren y un modelo de lenguaje grande (LLM) elabora la lógica. Las mejoras en la productividad son reales: los prototipos se crean en un tiempo récord y los ingenieros noveles pueden trabajar al mismo ritmo que los más experimentados. 

Pero la programación basada en «vibes» rompe la cadena tradicional de autoría y revisión. Cuando un desarrollador le pide a un modelo de lenguaje grande (LLM) que «corrija este error» y el parche resultante introduce una vulnerabilidad, ¿quién es el autor de esa lógica? ¿El desarrollador? ¿El modelo? ¿Los datos de entrenamiento? 

Las cifras son contundentes: solo una de cada tres organizaciones afirma tener una visibilidad y una gobernanza adecuadas sobre la programación asistida por IA. Esta brecha supone un punto ciego cada vez mayor en DevSecOps y en los riesgos software . 

La identidad es la solución. La procedencia criptográfica y la firma de código garantizan la responsabilidad del código generado por la IA a través de varios mecanismos: 

  • Firmar criptográficamente todos los cambios en el código, ya sean realizados por personas o por IA, asegurándose de que cada línea tenga un autor verificable. 
  • Exigir una autenticación basada en la identidad para las confirmaciones, de modo que los agentes de IA interactúen con los repositorios bajo identidades únicas y vinculadas criptográficamente. 
  • Validar y firmar las instruccionesantes de que los modelos generen código, creando así una protección contra la inyección de instrucciones 
  • Implementa flujos de trabajo seguroscon análisis estático, comprobaciones de dependencias, creación de SBOM y análisis de vulnerabilidades durante la fase de compilación 

A medida que software evoluciona hacia un futuro en el que los desarrolladores y los agentes de IA escriban código de forma conjunta, cada aportación de la IA debe llevar una huella criptográfica, cada ruta de código debe tener una procedencia auditable y cada commit debe tener una identidad atribuible. 

La IA como palanca operativa para la PKI 

A medida que proliferan los agentes de IA, la complejidad de la gestión de la identidad criptográfica aumenta considerablemente. La propia IA se está convirtiendo en parte de la solución. 

Las organizaciones están empezando a adoptar operaciones de PKI asistidas por IA: 

  • Interfaces de lenguaje natural para la gestión de certificados: permiten a los administradores gestionar los certificados mediante indicaciones conversacionales, en lugar de utilizar herramientas especializadas. 
  • Detección autónoma de activos criptográficos: agentes de IA que identifican certificados, claves y configuraciones en toda la empresa 
  • Emisión y renovación basadas en políticas: gestión automatizada del ciclo de vida de los certificados que se adapta a los cambios en las políticas en tiempo real 
  • Detección inteligente de errores de configuración y anomalías: supervisión basada en inteligencia artificial que identifica los problemas antes de que provoquen interrupciones del servicio o incidentes de seguridad 

Estas capacidades no pretenden sustituir a los equipos de PKI, sino más bien permitir que los equipos trabajen al ritmo que exigen los sistemas autónomos. 

CómoKeyfactor ayudarteKeyfactor 

Keyfactor realidad estos principios de identidad basados en la IA a través de una plataforma diseñada específicamente para garantizar la confianza digital a escala empresarial.Keyfactor , en la que confían las empresas más grandes del mundo para emitir y gestionar miles de millones de certificados en distintos dispositivos, cargas de trabajo y, ahora, agentes de IA,Keyfactor la base criptográfica necesaria para un despliegue seguro de la IA basada en agentes. 

Capacidades fundamentales para la identidad basada en la IA 

Certificados X.509 únicos para cada agente de IA.
Cada agente recibe una identidad respaldada criptográficamente e irreplicable a través deKeyfactor EJBCA de Keyfactor, una infraestructura de clave pública (PKI) completa y flexible con la escalabilidad que exigen las empresas modernas. 

Flujos OAuth basados en certificados.
Sustituye los secretos de cliente estáticos por la autenticación mediante certificado de cliente, tanto para la IA interactiva (humano + IA a través de MCP) como para los agentes totalmente autónomos. Cada acción puede rastrearse hasta un titular de certificado específico. 

TLS mutuo TLS todas las comunicaciones de IA.
Aplicar mTLS a las comunicaciones entre agente y servicio y entre agente y agente, garantizando que cada conexión se verifique criptográficamente. 

Gestión automatizada del ciclo de vida de los certificados a escala de IA. 
Keyfactor Command supervisa y gestiona los ciclos de vida de los certificados en cualquier solución de CA, ofreciendo revocación y aprovisionamiento masivos, supervisión del estado en tiempo real y la «criptoagilidad» necesaria para adaptarse a los estándares en constante evolución. La integración con SPIFFE permite una gestión de certificados sin sobrecarga para cargas de trabajo de IA en contenedores. 

Plantillas de certificados basadas en políticas.
Incorpora las capacidades y limitaciones de los agentes directamente en las plantillas de certificados: a qué sistemas pueden acceder los agentes, qué operaciones pueden realizar y las restricciones temporales de su actividad. 

Servidor MCP paraKeyfactor Command.
Una interfaz de lenguaje natural para la gestión de certificados que permite realizar operaciones de PKI asistidas por IA, lo que reduce horas de trabajo administrativo a simples indicaciones conversacionales. 

Inteligencia de riesgos y observabilidad centrada en la identidad.
Supervisa el uso de certificados, detecta anomalías, evalúa el estado de seguridad y recibe alertas en tiempo real sobre incumplimientos de las políticas, todo ello vinculado a la identidad criptográfica. 

Criptoagilidad y preparación para la era poscuántica.
A medida que los agentes de IA se amplían, también lo hace la necesidad de certificados.Keyfactor las organizaciones puedan emitir, gestionar y sustituir certificados a gran escala, sin dejar de ser ágiles y estando preparadas para la era cuántica. 

Firma segura de código.
Keyfactor SignServer ofrece un motor de firma basado en API que permite realizar firmas rápidas y seguras en prácticamente cualquier formato, incluyendola firmasegurade códigoyla firma inmediata. Esto es fundamental para mantener la trazabilidad en entornos de programación dinámicos. 

La hoja de ruta de la implantación 

La transición hacia una IA agentiva protegida mediante PKI sigue una progresión lógica: 

Fase 1: Establecer las bases del modelo «Zero Trust».
Antes de implementar ni un solo agente de IA, establece un modelo «Zero Trust» basado en PKI para los sistemas con los que interactuarán los agentes. Evalúa el entorno de destino, implementa la autenticación basada en certificados, configura los proveedores de identidad para OAuth respaldado por certificados, protege los servidores MCP con mTLS y establece la infraestructura de monitorización. 

Fase 2: Implementa tu primer agente seguro.
Elige un caso de uso de bajo riesgo y alto valor. Configura la identidad criptográfica del agente. Prueba los flujos de autenticación tanto interactivos como autónomos. Supervisa el estado de los certificados y documenta los patrones recurrentes. 

Fase 3: Escalar a miles de millones gracias a la automatización.
Automatizar la inscripción de certificados en los procesos de implementación. Implementar SPIFFE para agentes en contenedores. Establecer plantillas de certificados para una identidad basada en políticas. Ampliar el perímetro «Zero Trust» a medida que aumentan los casos de uso. Implementar la gestión de certificados asistida por IA y planificar las transiciones postcuánticas.