# Anatomía de un pipeline de verificación de 12 etapas para credenciales de agentes IA

> Source: <https://dev.to/edison_flores_6d2cd381b13/anatomia-de-un-pipeline-de-verificacion-de-12-etapas-para-credenciales-de-agentes-ia-2dcp>
> Published: 2026-09-01 16:06:14+00:00

Cuando empecé a diseñar el **Universal Trust Adapter (UTA)**, pensé: "verificar una credencial es verificar la firma criptográfica y punto." Error.

Una credencial puede tener la firma criptográfica correcta y aún así ser:

Cada uno de estos casos requiere una etapa de verificación separada. De ahí el pipeline de **12 etapas**:

```
PARSER → DETECT → SCHEMA → CRYPTO → ISSUER → KEY_BINDING
       → POP → PROVENANCE → LIFECYCLE → EVIDENCE → POLICY → DECISION
```

Recibe bytes crudos (JSON, CBOR, PEM, DER) y los convierte a un formato interno. Si los bytes no parsean, fail.

Identifica el formato de la credencial: ¿es JWT? ¿W3C VC? ¿ATC v3? ¿MCP Card? UTA soporta 8 formatos.

Valida que la credencial tenga los campos obligatorios del formato detectado. Un JWT sin `alg`

falla aquí.

Verifica la firma criptográfica. Si la firma no cuadra con la clave pública del issuer, fail.

Resuelve la identidad del issuer. ¿Es una CA conocida? ¿Es un issuer en una lista de confianza? ¿Es desconocido?

Verifica que la clave usada para firmar la credencial esté vinculada al issuer declarado. Previene suplantación.

Verifica que quien presenta la credencial realmente posee la clave privada vinculada. Esto previene el robo de credenciales.

Traza el origen de la credencial. ¿Viene del issuer directo? ¿De un cache? ¿De un tercero? Esto afecta la confianza.

Verifica vigencia: `not_before`

, `expires_at`

, `revocation_status`

. Una credencial expirada falla aquí.

Recopila evidencia criptográfica (logs, timestamps, receipts) que justifica la decisión. Útil para auditoría.

Aplica políticas específicas del sistema: "solo issuers en esta lista", "solo scopes que empiecen con `read:`

", etc.

Combina los resultados de las 11 etapas anteriores y emite un veredicto: `PERMIT`

, `DENY`

, o `UNDETERMINED`

.

Si todo fuera una función `verify(card)`

, no podrías:

Separar las etapas te da observabilidad y flexibilidad.

El pipeline está implementado en TypeScript y publicado como `@marketnow/trust-core`

:

``` js
import { verify, getStageResult } from '@marketnow/trust-core';

const result = await verify(card);
console.log(result.decision);           // 'PERMIT' | 'DENY' | 'UNDETERMINED'
console.log(result.failed_stage);        // 'LIFECYCLE' si expiró
console.log(getStageResult('CRYPTO'));   // detalle de la verificación criptográfica
```

Cada etapa expone su resultado individual para que puedas inspeccionar.

La verificación de credenciales no es un paso, es un pipeline. Si lo tratas como un paso, vas a tener falsos positivos (credeniales inválidas que pasan) o falsos negativos (credenciales válidas que no pasan).

UTA implementa los 12 pasos. Tú decides cuáles activar.

*Repo: alicelabs-llc/universal-trust-adapter · API: marketnow.site/api/trust*