Identidad Agéntica Verificable

El alcance (scope), el riesgo máximo sin aprobación, el límite de importe y el TTL no viven en el manifiesto: son parámetros de la emisión, y por eso pueden endurecerse sin tocar la configuración del agente.

Las acciones se identifican con el skill_id del catálogo de skills del emisor, en notación dominio.verbo. No es una lista cerrada en el código: cada skill del catálogo declara su risk_level (LOW, MEDIUM, HIGH, PROHIBITED), su estado (DRAFT, ACTIVE, QUARANTINED, DEPRECATED), sus herramientas y conectores necesarios, si es idempotente y qué evidencia exige. Al emitir se avisa —sin bloquear— si una skill del alcance no existe o no está activa.

Las acciones documentadas hoy, tal y como aparecen en el alcance de referencia:

El hash es SHA-256 en hexadecimal sobre una serialización JSON canónica del manifiesto: claves ordenadas alfabéticamente en todos los niveles de anidamiento, sin espacios, con los valores undefined descartados. Antes de calcularlo se retiran los campos volátiles del almacenamiento (id, created_date, updated_date, created_by, is_sample), que cambiarían el hash sin que cambiase el agente.

function canonical(v) {
  if (v === null || typeof v !== 'object') return JSON.stringify(v ?? null);
  if (Array.isArray(v)) return '[' + v.map(canonical).join(',') + ']';
  return '{' + Object.keys(v).sort()
    .filter(k => v[k] !== undefined)
    .map(k => JSON.stringify(k) + ':' + canonical(v[k])).join(',') + '}';
}
// manifest_hash = SHA-256(canonical(manifiesto)) en hexadecimal, 64 caracteres

La comprobación manifestBinding compara el hash firmado con el manifiesto registrado como vigente. Cambiar sus campos exige publicar una nueva versión y reemitir. Esta comprobación no inspecciona la configuración efectiva del sistema en ejecución: cambios externos en prompts, modelos, herramientas o permisos requieren controles adicionales. El alcance de la emisión se firma por separado y no forma parte de ese hash.

{
  "human_id": "AGT-2026-0004",
  "name": "Argos",
  "slug": "argos",
  "role": "Lead NextAI",
  "mission": "Conducir NextAI entregando valor medible a cada cliente.",
  "manifesto": "Vigilancia panorámica sobre cada compromiso con cliente.",
  "autonomy_max": "A4",
  "domain_scope": ["nextai"],
  "is_lead": true,
  "is_overseer": false,
  "is_independent": false,
  "health_status": "healthy",
  "public": true
}

// manifest_hash = SHA-256(canonical(…)) → 64 caracteres hexadecimales
// Se publica con { subject_type: "AGENT", version: "1.0.0", changelog: "Primera versión" }

La instantánea se toma del registro del agente antes de escribirle la nueva versión, de modo que el hash no dependa de sí mismo. Puedes comprobar el hash vigente de cualquier agente público en la respuesta del verificador, campo credential.manifestHash.

{
  "alg": "ES256",
  "typ": "vc+jwt",
  "kid": "did:web:digitalcortex.tech#Cf3q-SmjX9b0cdB3PbbvnnvVudiVXiPkt-9guZgAIGY"
}

El kid apunta a un verificationMethod del documento DID del emisor; el fragmento tras # es la huella JWK de la propia clave (RFC 7638). El verificador exige typ = "vc+jwt" y un kid que contenga #, y rechaza cualquier otra combinación antes incluso de mirar la firma.

La credencial y el sello no contienen datos personales de personas físicas: ni de quien opera el agente, ni de terceros. La rendición de cuentas pública se expresa como organización + rol + canal de contacto (accountableRole), porque la persona concreta consta en el registro mercantil, no en un documento que va a circular. El verificador filtra además cualquier campo de persona responsable aunque una credencial antigua lo llevara dentro.

{
  "valid": true,
  "checks": {
    "format":          { "ok": true, "detail": "JWS con typ=vc+jwt y kid presente" },
    "keyDeclared":     { "ok": true, "detail": "La clave está declarada en assertionMethod del emisor" },
    "signature":       { "ok": true, "detail": "Firma ES256 válida" },
    "issuerMatch":     { "ok": true, "detail": "Emitida por Cosmolabs OÜ (did:web:digitalcortex.tech)" },
    "validity":        { "ok": true, "detail": "En vigor, caduca en 83 días" },
    "revocation":      { "ok": true, "detail": "No revocada" },
    "manifestBinding": { "ok": true, "detail": "Manifiesto 1.0.0 (a91c4f22e8…3b7d) sin cambios" }
  },
  "credential": { "humanId": "CRD-2026-0001", "id": "urn:uuid:8f1c9a52-…",
                  "issuedAt": "…", "expiresAt": "…",
                  "manifestVersion": "1.0.0", "manifestHash": "…", "signingBackend": "KMS_GCP" },
  "reference":  { "requested": "CRD-2026-0001", "isCurrent": true },
  "didDocument": { "published": true, "matches": true,
                   "url": "https://digitalcortex.tech/.well-known/did.json" },
  "agent":      { "did": "did:web:digitalcortex.tech:agents:argos", "name": "Argos",
                  "slug": "argos", "role": "Lead NextAI", "domain": "nextai",
                  "autonomyLevel": "A4", "manifestVersion": "1.0.0",
                  "scope": { }, "disclosure": { } },
  "principal":  { "type": "Organization", "legalName": "Cosmolabs OÜ" },
  "termsOfUse": [ ],
  "issuer":     { "id": "did:web:digitalcortex.tech", "name": "Cosmolabs OÜ" },
  "validity":   { "from": "…", "until": "…" }
}

Cuando algo falla, valid es false, reason trae el motivo en texto legible y checks contiene solo las comprobaciones ejecutadas hasta la que falló, con esa última marcada ok: false. Si el sello escaneado apunta a una credencial que ya no es la vigente, reference.isCurrent es false y reference.note explica si fue revocada o sustituida y cuál es la vigente ahora.

No hace falta confiar en nuestra página. Con curl y jose en Node (v18 o superior, sin más dependencias) tienes la verificación completa en unas veinte líneas.

# 1 · la credencial vigente del agente (JWS compacto, typ vc+jwt)
curl -s "https://digitalcortex.tech/functions/agentCredential?slug=argos" -o argos.jwt

# 2 · el documento DID del emisor, con su clave pública
curl -s "https://digitalcortex.tech/.well-known/did.json" -o did.json

import { readFileSync } from 'node:fs';
import { gunzipSync } from 'node:zlib';
import { importJWK, compactVerify, decodeProtectedHeader } from 'jose';

const jws = readFileSync('argos.jwt', 'utf8').trim();
const did = JSON.parse(readFileSync('did.json', 'utf8'));

// 1 · formato
const { alg, typ, kid } = decodeProtectedHeader(jws);
if (typ !== 'vc+jwt' || alg !== 'ES256') throw new Error('Formato inesperado');

// 2 · la clave está declarada por el emisor
const vm = did.verificationMethod.find((m) => m.id === kid);
if (!vm || !did.assertionMethod.includes(kid)) throw new Error('kid no declarado');
const key = await importJWK(vm.publicKeyJwk, 'ES256');

// 3 · firma — compactVerify lanza si no casa
const { payload } = await compactVerify(jws, key);
const vc = JSON.parse(new TextDecoder().decode(payload));

// 4 · emisor coherente   5 · vigencia
const now = new Date();
if (vc.issuer.id !== 'did:web:digitalcortex.tech') throw new Error('Emisor incoherente');
if (new Date(vc.validFrom) > now || new Date(vc.validUntil) < now) throw new Error('Fuera de vigencia');

// 6 · revocación — la lista va firmada por la MISMA clave
const res = await fetch(vc.credentialStatus.statusListCredential);
const { payload: lp } = await compactVerify(await res.text(), key);
const list = JSON.parse(new TextDecoder().decode(lp));
const bits = gunzipSync(Buffer.from(list.credentialSubject.encodedList.slice(1), 'base64url'));
const i = Number(vc.credentialStatus.statusListIndex);
if ((bits[i >> 3] & (128 >> (i % 8))) !== 0) throw new Error('REVOCADA');

console.log('OK', vc.credentialSubject.name, vc.credentialSubject.autonomyLevel, vc.validUntil);

Falta la séptima comprobación —que el manifiesto del agente no haya cambiado— porque solo el emisor conoce el hash del manifiesto que el emisor tiene registrado como vigente. Se obtiene del verificador, en credential.manifestHash. Es, a propósito, la única pieza que no puedes reproducir por tu cuenta.

• No acredita la calidad ni el resultado de ninguna tarea concreta que haya hecho el agente.
• No sustituye al contrato ni a las condiciones del servicio que rijan entre las partes.
• No convierte al agente en sujeto de derechos u obligaciones: de sus actuaciones dentro del alcance autorizado responde Cosmolabs OÜ conforme a la legislación aplicable.
• No prueba que el mensaje que has recibido lo enviara ese agente: prueba que existe un agente identificado con ese alcance. Atribuir un mensaje concreto exige firmar también el mensaje, y eso no forma parte de esta credencial.
• No es una auditoría externa ni la revisión de un tercero: es una declaración del emisor, verificable en su integridad y en su vigencia.
• No vale una captura. El resultado es válido en el instante de la consulta. Un sello impreso o una pantalla guardada no acreditan nada: hay que volver a comprobar.

• Puede reproducirse íntegro y sin alteraciones, con fines informativos.
• Siempre acompañado de su QR o con la URL de verificación visible. Recortar o sustituir el QR está prohibido.
• El sello que servimos se apaga solo cuando la credencial se revoca o caduca: nunca miente sobre el estado. Una copia antigua guardada como imagen no prueba nada.
• Está prohibido presentar como vigente una identidad revocada o caducada, o hacer pasar por agente de CORTEX a un sistema que no lo sea. Avisos a legal@digitalcortex.tech.

Un bit por credencial, el más significativo primero dentro de cada byte, sobre una lista de 131.072 bits (16 KB). Se comprime con GZIP y se codifica en multibase base64url sin relleno, con prefijo u. La lista es a su vez una credencial firmada: si no lo fuera, cualquiera podría servir una lista vacía y «des-revocar» agentes.

Cada publicación crea una versión nueva y marca la anterior como sustituida; la vigente viaja en la cabecera X-Status-List-Version. La caché es de 60 segundos con revalidación en segundo plano: ese valor no es una garantía de propagación global ni de retirada efectiva de acceso. Los índices no se reutilizan jamás, aunque la credencial que los ocupaba haya caducado.

• El verificador devuelve valid: false con la comprobación revocation en rojo y el detalle «REVOCADA (índice N)».
• La página /verify/<agente> muestra «Credencial revocada» y el sello atenuado.
• El sello servido desde este dominio deja de animarse, se atenúa y pinta el banner REVOCADA, con la cabecera X-Credential-Status: REVOKED.
• El registro sigue listando al agente con status: "revoked" y su fecha de revocación: un registro que solo enseña lo vigente es un escaparate, no un registro.
• La credencial en sí deja de servirse: /functions/agentCredential responde 404. Quien conserve una copia del JWT podrá seguir comprobando la firma, y precisamente por eso la consulta de la lista de revocación es obligatoria en cualquier verificación seria.

El sello es un SVG servido con CORS abierto: basta una etiqueta img envuelta en un enlace a la página de verificación. No lo copies a tu servidor: si lo sirves desde el nuestro, se apaga solo cuando la credencial deja de estar vigente.

<a href="https://digitalcortex.tech/verify/argos"
   rel="noopener" target="_blank"
   title="Verificar la identidad de este agente de IA">
  <img src="https://digitalcortex.tech/functions/agentSeal?slug=argos"
       alt="Sello de identidad del agente de IA Argos, emitido por Cosmolabs OU"
       width="240" height="240" loading="lazy" />
</a>

Si necesitas saber el estado sin renderizar la imagen, una petición HEAD al mismo endpoint devuelve X-Credential-Status. Para integraciones programáticas, usa el verificador y lee valid y checks.

En la firma de los correos que envía un agente, tres líneas bastan y son verificables: qué es, quién responde y dónde comprobarlo. El texto exacto del aviso ya viene dentro de la credencial, en credentialSubject.disclosure.statement, y la URL en disclosure.verifyUrl.

Argos · Agente de IA de Cosmolabs OU (CORTEX)
Sistema de inteligencia artificial. No es una persona.
Identidad verificable: https://digitalcortex.tech/verify/argos

El art. 50 del Reglamento (UE) 2024/1689 exige que quien interactúa con un sistema de IA lo sepa. La práctica que seguimos: el aviso aparece en el primer mensaje de cada conversación, en lenguaje claro, con el nombre de la sociedad responsable y un enlace donde comprobarlo. En canales con cabeceras propias, además, un encabezado legible por máquinas.

Hola, soy Argos, un sistema de inteligencia artificial operado por Cosmolabs OU.
No soy una persona. Puedes comprobar mi identidad, quien responde por mi y que
tengo permitido hacer en https://digitalcortex.tech/verify/argos

X-AI-Agent: did:web:digitalcortex.tech:agents:argos
X-AI-Agent-Verify: https://digitalcortex.tech/verify/argos

Cachea con cabeza: el verificador se sirve con max-age=30 y la lista de estado con max-age=60. No caches un resultado de verificación más allá de eso, porque una revocación debe verse en menos de un minuto.

Nada de esto es propietario. Si quieres identificar tus propios agentes con los mismos estándares, necesitas cuatro cosas:

1. Una clave de firma ES256 en un KMS (o en un HSM). La clave privada no debe estar nunca en el servidor web ni en un equipo personal.
2. Un documento DID publicado en tu dominio: did:web:tudominio.tld → https://tudominio.tld/.well-known/did.json, con tu clave pública en verificationMethod y referenciada en assertionMethod. Para los agentes, con path: did:web:tudominio.tld:agents:<slug> → https://tudominio.tld/agents/<slug>/did.json, sin .well-known.
3. Credenciales W3C VC 2.0 firmadas como JWS typ: vc+jwt, con credentialStatus apuntando a tu propia Bitstring Status List firmada.
4. Un verificador público. Sin una URL donde un tercero compruebe en el momento, la credencial no sirve de nada.

Publicaremos la especificación completa de la credencial de delegación agéntica y del sello con licencia abierta. Mientras tanto, esta página documenta el formato con el detalle suficiente para reimplementarlo, y todos los artefactos de un agente real están accesibles para inspección. Si estás construyendo algo parecido y quieres que los formatos converjan, escribe a legal@digitalcortex.tech.

La idea: por cada emisión y cada revocación, escribir una atestación en el Ethereum Attestation Service desplegado en Base, con el hash del JWT de la credencial, el manifestHash, el DID del agente y las fechas. Una atestación cuesta céntimos y es pública.

El registro de auditoría ya está encadenado por hash, pero la base de datos la controla el operador. Un sello diario de la cabeza de cada partición, firmado con una clave que vive fuera del sistema, convierte «reescribí el ledger» en algo detectable: el sello de ayer deja de casar. Llevar ese sello a una cadena pública añade una marca de tiempo que el operador tampoco controla. El proceso es idempotente: si la cabeza no ha cambiado desde el último sello, no se escribe otro.

ERC-8004 propone un registro de identidad de agentes on-chain donde cada agente tiene un identificador y una agentURI que apunta a un fichero de registro con sus metadatos. Encaja de forma natural: esa agentURI sería el documento DID del agente publicado en este dominio, y el fichero de registro, los metadatos que ya devuelve hoy /functions/agentSeal?slug=<slug>&format=json.

Cuando lo anterior esté desplegado, la página de verificación mostrará una comprobación más junto a las ocho actuales: que existe una atestación on-chain para esta credencial, que no ha sido revocada en la cadena y en qué bloque y fecha se escribió. Hasta entonces no aparecerá: una comprobación que no se ejecuta no se pinta.

Resolvería: marca de tiempo independiente del operador (no repudio), prueba de que una credencial existía en una fecha aunque el emisor desapareciera, y un punto de consulta que no depende de que nuestro dominio siga en pie. Refuerza, en una palabra, la atribución, el alcance y el no repudio.

No resolvería nada sobre el comportamiento del agente: no hace que esté mejor alineado, ni que sus resultados sean correctos, ni que cumpla lo que promete. Poner un hash en una cadena pública no mejora a un agente; solo hace más difícil mentir después sobre lo que se autorizó y cuándo. Cualquiera que venda lo contrario está vendiendo otra cosa.