Por qué escribà esto en español
Llevo semanas publicando en inglĂ©s sobre el Universal Trust Adapter (UTA) y me di cuenta de algo: la mitad de los desarrolladores que me escriben por DM son hispanohablantes. Pero no encuentran documentaciĂłn en su idioma. Este artĂculo corrige eso.
El problema
Cuando un agente IA invoca un tool — un MCP server, una API interna, un microservicio — no hay forma canónica de responder a tres preguntas básicas:
- ¿Quién emitió la credencial de ese tool?
- ¿Hasta cuándo es válida?
- ¿Qué scope tiene — qué puede y qué no puede hacer?
Si vienes del mundo de OAuth, te suena. Si vienes del mundo X.509, también. Si vienes del mundo W3C Verifiable Credentials, idem. El problema es que cada estándar responde la pregunta de manera distinta, y los agentes de IA no saben cuál estándar usar.
La soluciĂłn: UTA
Universal Trust Adapter — https://github.com/alicelabs-llc/universal-trust-adapter
UTA es un verificador universal que acepta 8 formatos de credenciales:
| # | Formato | Origen |
|---|---|---|
| 1 | ATC v3 (Agent Trust Card) | Propuesta de AliceLabs |
| 2 | JWT (con x5c chain) |
IETF RFC 7519 |
| 3 | W3C Verifiable Credentials | W3C VC Data Model |
| 4 | A2A (Agent-to-Agent) cards | Google A2A Protocol |
| 5 | EAT-AI (Entity Attestation Tokens) | IETF RATS |
| 6 | ZTA (Zero Trust Agent) cards | Variante ZTA |
| 7 | MCP Server Cards | Anthropic MCP |
| 8 | X.509 certificates | ITU-T |
Y los procesa a través de un pipeline de 12 etapas:
PARSER → DETECT → SCHEMA → CRYPTO → ISSUER → KEY_BINDING
→ POP → PROVENANCE → LIFECYCLE → EVIDENCE → POLICY → DECISION
Cada etapa es independiente y testeada. El pipeline completo está documentado en el repo.
CĂłmo usarlo
OpciĂłn A: API pĂşblica
curl -X POST https://www.marketnow.site/api/trust?action=verify \
-H "Content-Type: application/json" \
-d '{"card": "...tu JWT o VC aquĂ..."}'
OpciĂłn B: NPM package
npm install @marketnow/trust-core
import { verify } from '@marketnow/trust-core';
const result = await verify(card);
if (result.decision === 'PERMIT') {
// tool es confiable, ejecĂştalo
} else {
// algo fallĂł en el pipeline, no ejecutes
console.log(result.failed_stage);
}
Benchmarks reales
- 6,744 verificaciones por segundo en un solo nĂşcleo
- 480+ tests en Node.js
- 16 tests en Python (adapter)
- 23 property tests (conformance suite)
Por qué esto importa en LatAm
En LatAm tenemos una ventaja: podemos adoptar estándares desde el principio, sin cargar con el legacy de sistemas crĂticos que corren hace 20 años. Si tu startup está construyendo agentes IA hoy, la capa de confianza deberĂa ser un default, no un afterthought.
UTA está pensado para eso: ser una librerĂa pequeña, rápida, sin dependencias pesadas, que cualquier dev pueda integrar en una tarde.
Lo que NO resuelve UTA
Honestidad:
- Reputation layer: UTA verifica la criptografĂa y el issuer, pero no resuelve "Âżeste issuer es de confianza?". Eso requiere un reputation graph separado.
- EAT-AI y ZTA están en beta — los formatos están implementados pero la adopción es baja.
- Policy engine: la etapa POLICY acepta cualquier polĂtica que implementes, pero UTA no trae polĂticas predefinidas.
PrĂłximos pasos
Si te interesa:
- Lee el README — está en inglés pero el código es universal.
- Prueba la API: https://www.marketnow.site/api/trust?action=formats
- Si quieres contribuir — traducciones, adapters en otros lenguajes, casos de uso — abre un issue en el repo.
Cierre
La confianza entre agentes no es un problema tĂ©cnico de criptografĂa. Es un problema de interoperabilidad de estándares. UTA no inventa un nuevo estándar — conecta los que ya existen.
Si eres dev hispanohablante trabajando en agentes IA, este es el momento de aportar a la capa de confianza. Nosotros ponemos la infraestructura; tĂş pones los casos de uso.
Repo: alicelabs-llc/universal-trust-adapter · API: marketnow.site/api/trust · NPM: @marketnow/trust-core
