Skip to content
VeriSwarm
Acerca de
DocumentaciónPreciosHabilidad del agente
Iniciar sesiónRegistrarse
  1. Inicio
  2. /Learn
  3. /Identity vs trust ai agents
VeriSwarm
  • English
  • ✓ Español
  • Deutsch
  • Français
  • Italiano
  • Português
  • 日本語
  • 한국어
  • 简体中文

Producto

  • Precios
  • Documentación
  • API
  • Habilidad del agente
  • Especificación OATS

Confianza

  • Centro de confianza
  • Seguridad
  • Cumplimiento
  • Estado
  • Registro de cambios

Empresa

  • Acerca de
  • Blog
  • Código abierto
  • Inversionistas
  • Prensa

Legal

  • Términos
  • Privacidad
  • SLA
  • DPA
  • Accesibilidad
Guía técnica

Identidad frente a confianza para agentes de IA

¿Todo agente verificado es fiable? Es como decir que todo conductor con carné es un buen conductor. La industria de la IA corre por resolver el problema de identidad de los agentes autónomos, y los proveedores de IAM corren con ella. Están resolviendo el problema correcto. Están resolviendo la mitad. Esta guía repasa las dos preguntas que hay que responder por separado, por qué OAuth y los roles no pueden responder ambas, y cómo es la capa de comportamiento cuando realmente está implementada.

Las dos preguntas

Toda decisión de acceso para un agente autónomo responde a dos preguntas distintas, y confundirlas es la forma en que falla la gobernanza en producción.

¿Es legítimo este agente?

Capa de identidad. ¿Quién es este agente? ¿Quién lo construyó? ¿A quién representa? ¿La credencial que presenta es verificable criptográficamente? ¿Ha sido revocada? Toda plataforma IAM responde bien a esta pregunta.

¿Se está comportando bien este agente?

Capa de comportamiento. ¿Se ha mantenido este agente dentro de su alcance? ¿Ha estado alucinando? ¿Ha filtrado PII a través de llamadas a herramientas? ¿Está cambiando su perfil de riesgo? Las plataformas IAM no pueden responder a esto, y nunca fueron diseñadas para hacerlo.

Un agente que no supera la verificación de identidad debe ser bloqueado. Un agente que supera la verificación de identidad pero se comporta mal debe ser restringido. Ninguna de las dos capas es suficiente por sí sola.

Qué cubre el IAM tradicional

Los proveedores IAM consolidados —Okta, SailPoint, Microsoft Entra, IBM, Auth0, Curity y el resto del ecosistema basado en estándares (W3C DID, OpenID Foundation)— están convergiendo hacia una respuesta sofisticada a la cuestión de identidad para agentes autónomos. El vocabulario es coherente entre proveedores: aprovisionamiento just-in-time, concesión dinámica de permisos, credenciales efímeras, autoridad delegada, cadenas de atestación. El NCCoE del NIST tiene un proyecto de identidad y autorización de software y agentes de IA que mapea el mismo espacio.

Es un buen trabajo. La capa de identidad es difícil y es el punto correcto para empezar. Nada de lo que sigue argumenta que la identidad sea innecesaria o que estos proveedores se equivoquen al respecto. No se equivocan.

Para saber qué hace que la identidad de un agente sea realmente verificable —y no solo aprovisionada— consulta Identidad verificable de agentes.

Lo que no cubre — la brecha en tiempo de ejecución

El IAM responde a quién fue aprovisionado con qué acceso en el momento en que emitimos la credencial. Los agentes autónomos necesitan responder a una pregunta distinta: ¿se está comportando esta entidad, con esta credencial, en este contexto, de una manera que justifique conservar su acceso ahora mismo?

El historial de 2025–2026 muestra cómo es esta brecha en la práctica:

  • El agente descontrolado de Meta (marzo de 2026). Superó todas las comprobaciones de identidad y credenciales. Autenticado, autorizado, desplegado internamente. Después realizó acciones no autorizadas y expuso datos sensibles. El fallo no estaba en el «quién». Estaba en el «qué». VentureBeat informó de que el 47% de los CISO ya han observado agentes con comportamiento no autorizado; solo el 5% se siente seguro de poder contener uno comprometido.
  • La crisis del marketplace de skills de OpenClaw (febrero de 2026). Más de 1.100 skills maliciosas plantadas mediante inyección de prompts y exfiltración de credenciales. 135.000 instancias expuestas. Todos los agentes estaban registrados. Todos los agentes tenían una identidad. La capa de comportamiento simplemente no existía. (Misma superficie de riesgo que los agentes en la sombra.)
  • Compromiso de la cadena de suministro de plugins de OpenAI (2025). 47 despliegues empresariales comprometidos mediante tokens OAuth robados: credenciales válidas usadas para acceder a datos de clientes durante seis meses antes de su detección. La identidad era real. El comportamiento fue malicioso.

Cada uno de estos incidentes habría superado una auditoría de Okta en el momento en que ocurrió. La credencial se emitió correctamente, el rol se delimitó correctamente, la autenticación fue exitosa. Nada de eso evitó el fallo, porque el fallo estaba aguas abajo de la identidad.

Las cinco dimensiones de la confianza, más allá de la identidad

La capa de comportamiento puntúa a un agente de forma continua en cinco dimensiones —confianza de identidad (sí, la identidad es una de las cinco, pero con un modelo de decaimiento honesto en lugar de un hecho permanente), riesgo, fiabilidad, autonomía y calibración (si la confianza reportada por un agente coincide con sus resultados reales)— y emite un nivel de política (allow / review / deny) por decisión. De forma crucial, las cinco dimensiones son ortogonales: un agente puede estar verificado criptográficamente (alta confianza de identidad) y aun así tener una puntuación de fiabilidad en deterioro, y el nivel de política respeta ambas cosas.

La guía completa del modelo de puntuación de cinco dimensiones está en Puntuación de confianza de agentes — Una guía técnica. El argumento más profundo de por qué una puntuación compuesta no sobrevive en producción está en Identidad, riesgo, fiabilidad, autonomía: por qué una sola puntuación de confianza no basta para agentes en producción.

Por qué OAuth + identidad de máquina no es suficiente

OAuth y los sistemas de identidad de máquina (SPIFFE/SPIRE, mTLS, credenciales de cliente OIDC) se diseñaron para servicios con identificadores estables, credenciales de larga duración y humanos en el bucle para las decisiones de acceso. Los agentes autónomos rompen las tres suposiciones: son efímeros, toman decisiones de acceso de forma autónoma a velocidad de máquina, y sus credenciales necesitan transportar autoridad delegada, alcance y señales de nivel de comportamiento que los protocolos originales no fueron diseñados para expresar.

La incorporación de OAuth 2.1 a MCP en 2026 es un progreso real. Pero un escaneo de seguridad de unos 2.000 servidores MCP encontró que todos y cada uno carecían de autenticación. La especificación existe; el despliegue no. (Panorama completo en Seguridad de servidores MCP: la brecha de PII.) Las Agent Cards de A2A están firmadas pero son autodeclaradas: no hay vinculación de atestación, ni historial de comportamiento, ni mecanismo para revocar la confianza en función del comportamiento observado. Ambos protocolos resuelven el descubrimiento y la interoperabilidad. Ninguno te dice si se debe confiar en el agente del otro extremo para lo que está a punto de hacer.

El circuito Passport → Gate → Vault

Las dos capas, conectadas entre sí en VeriSwarm:

Passport

La capa de identidad. Verificación criptográfica, credenciales JWT ES256 con un TTL de 1 hora, cadenas de delegación para flujos multiagente, un endpoint JWKS para que cualquier plataforma pueda verificar sin llamar a nuestra API. Todo el detalle en Agent Passport: credenciales portátiles.

Gate

La capa de comportamiento. Puntuación continua en las cinco dimensiones, niveles de política dinámicos, la taxonomía de 24 eventos. Nivel gratuito. El mismo libro de auditoría encadenado por hash que usan los planes de pago.

Vault

La capa de prueba. Libro de auditoría inmutable encadenado por hash que cubre eventos de identidad, señales de comportamiento, decisiones de política y todo cambio de estado. Verificación de la cadena bajo demanda: guía práctica en Verificar una cadena de Vault.

Cuando un agente presenta una credencial de Passport, la plataforma receptora sabe quién es. Cuando esa credencial lleva asociada una puntuación de confianza de Gate, la plataforma también sabe cómo se ha estado comportando. Vault demuestra que toda la secuencia ocurrió. Esa es la diferencia entre un carné de conducir y un historial de conducción.

La regulación ya asume ambas capas

La EU AI Act no solo exige transparencia sobre quién construyó un sistema de IA. El artículo 9 exige un proceso continuo de gestión de riesgos a lo largo de todo el ciclo de vida, no una comprobación de identidad puntual. El artículo 12 exige el registro automático de eventos durante toda la vida del sistema: registro de comportamiento, no verificación de identidad. El artículo 14 exige supervisión humana que permita interpretar los resultados; interpretar requiere monitorizar el comportamiento. La regulación ya asume que la identidad no es confianza; el cumplimiento exige ambas cosas. Todo el planteamiento de la EU AI Act para pilas de agentes.

Preguntas frecuentes

¿Sigo necesitando mi plataforma IAM si implemento esto?

Sí. La identidad es la capa uno: VeriSwarm no la sustituye. Si tus agentes se autentican mediante Okta, SailPoint, Entra, Auth0 o cualquier IAM personalizado, consérvalo. VeriSwarm se sitúa junto a él, añade la capa de comportamiento que tu IAM no tiene, y se integra con la identidad que tu plataforma ya emite. Las dos capas trabajan juntas; no compiten entre sí.

¿Es esto un sustituto de Okta / SailPoint / IBM?

No. Esos son proveedores de identidad: responden a «¿quién es esta entidad y qué rol ocupa?». Es un problema difícil y lo resuelven bien. VeriSwarm responde a una pregunta distinta: «¿se está comportando esta entidad de una manera que justifique conservar su acceso ahora mismo?». Una pila de identidad te dice que el Agente A fue aprovisionado con el rol X hace seis meses. La pila de comportamiento te dice que el Agente A ha estado alucinando desde el martes y debería perder el rol X hoy. Preguntas diferentes, ambas necesarias.

¿Qué pasa con ERC-8004 o los pasaportes de agentes basados en blockchain?

Es una apuesta distinta. La identidad de agentes basada en blockchain (ERC-8004, OriginTrail, pasaportes descentralizados) prioriza la resistencia a la censura y la atestación en cadena. VeriSwarm Passport usa JWT ES256 con verificación JWKS: un enfoque basado en estándares, sin necesidad de blockchain, que se verifica más rápido (sin consulta a la cadena) y se integra con la infraestructura de identidad empresarial existente. Ambos son válidos para la capa de identidad; la elección depende de si necesitas procedencia en cadena. En cualquier caso, la capa de comportamiento es la mitad que falta.

¿Qué cubre el nivel gratuito?

Gate —la capa de comportamiento— funciona en el nivel gratuito con ingesta de eventos ilimitada, 5.000 decisiones de confianza al día, el motor de puntuación de cinco dimensiones, y el mismo libro de contabilidad encadenado por hash que usan los planes de pago. Las credenciales portátiles básicas —JWT ES256 con verificación JWKS— también son gratuitas e ilimitadas. Lo que está limitado a los planes Pro y superiores es la suite Passport completa: cadenas de delegación para flujos multiagente, manifiestos firmados y verificación de identidad entre organizaciones. Puedes empezar con monitorización de comportamiento y credenciales básicas en los agentes que tu IAM actual ya autentica, y luego añadir el Passport completo cuando necesites delegación multiagente.

¿En qué se diferencia Passport de la identidad de máquina (SPIFFE, certificados mTLS, credenciales de cliente OAuth)?

Los sistemas de identidad de máquina se diseñaron para servicios con identificadores estables, credenciales de larga duración y operadores humanos tomando las decisiones de acceso. Los agentes son efímeros (a menudo de segundos a minutos), toman decisiones de acceso de forma autónoma y necesitan credenciales que expresen explícitamente autoridad delegada y alcance. Passport se basa en JWT por compatibilidad, pero su modelo de credenciales transporta cadenas de delegación, expresiones de alcance y señales de nivel de comportamiento que los formatos de identidad de máquina no fueron diseñados para expresar. Usa la identidad de máquina para tu capa servicio a servicio; usa Passport para la capa agente a agente por encima de ella.

¿Qué decide si una solicitud es allow, review o deny — la identidad o la confianza?

Ambas, combinadas en la capa de decisión. Una decisión de política toma la identidad del agente, su puntuación de confianza actual en las cinco dimensiones, la acción concreta que se intenta realizar, y cualquier anulación por kill switch o verificación de Passport, y emite un único allow / review / deny con un código de motivo. Ni la identidad ni la puntuación de confianza por sí solas determinan el resultado: el motor de decisión evalúa primero la política Cedar del tenant (o una matriz predeterminada codificada si no hay ninguna configurada) frente a todo ese contexto en conjunto.

¿Puede denegarse el acceso a un agente con una credencial de identidad válida y no caducada?

Sí, y ese es exactamente el sentido de la capa de comportamiento. Una credencial de Passport válida o un token emitido por el IAM demuestra que la identidad del agente es legítima; no dice nada sobre si se debe confiar en el agente para una acción dada en este momento. El kill switch es el ejemplo más claro: matar un agente no revoca ni altera su credencial de identidad, pero toda comprobación de decisión contra ese agente devuelve deny con reason_code: "agent_killed" hasta que un operador lo revierta; la capa de identidad se mantiene en verde mientras la capa de comportamiento la anula.

¿La verificación de identidad por sí sola satisface los requisitos de la EU AI Act o del NIST AI RMF para agentes?

No. La verificación de identidad satisface los requisitos de transparencia y procedencia —quién lo construyó, quién lo opera— pero ambos marcos exigen evidencia de comportamiento continua, no una comprobación puntual. El requisito de registro automático de eventos del artículo 12 de la EU AI Act y las expectativas de monitorización continua del NIST AI RMF se satisfacen mediante el registro de eventos de la capa de comportamiento y el libro de contabilidad encadenado por hash de Vault, no mediante una credencial de identidad por sí sola.

Conserva el IAM. Añade la capa de comportamiento.

El motor de puntuación de Gate funciona en el nivel gratuito y se integra con la identidad que tu plataforma ya emite. No necesitas quitar nada. Necesitas añadir la capa que tu IAM no tiene.

Probar la demoEmpezar gratis