La detección por tenant ha fallado. El substrate fingerprinting capta lo que Sigstore no puede captar.

Tres clases de compromisión se sitúan aguas arriba del runtime del agente, invisibles para la detección por tenant porque cada tenant recibe el mismo artefacto envenenado.

Cada evaluación que pasa por el gateway gestionado de Mnemom queda estampada con un substrate fingerprint: la tupla provider + model + SDK version, más una cabecera lockfile-hash opcional fijada por el cliente para una granularidad superior. El fingerprint se convierte en una de las cuatro axis identities — substrato, vertical, patrón, fuente — en cada fila que lee el agregador entre tenants. (Véase /protection-network para entender cómo encajan las capas L0-L5.)

{
  "provider": "anthropic",
  "model":    "claude-sonnet-4.7",
  "sdk":      "@anthropic-ai/[email protected]",
  "lockfile_hash": "sha256:9f3b...",   // optional, customer-supplied
  "fingerprint":   "sub_a4f1c8e7..."   // stable hash of the tuple
}

El flujo de evaluación de un cliente puede parecer poco destacable de forma aislada. A través de cada cliente que se ejecuta sobre la misma substrate fingerprint, la misma desviación de comportamiento se ilumina en las estadísticas móviles del agregador L1. AEGIS atribuye la anomalía al substrate, eleva el bucket dentro del techo configurado por el cliente (según el modelo de ratcheting aditivo bajo ataque) y una Managed Rule firmada se propaga a cada gateway — apuntando a P95 ≤ 30 segundos desde la promoción firmada hasta la carga en el gateway (un objetivo; las primeras mediciones se publican 30 días después de la GA). (Véase /trust/slos.)

El substrate fingerprint base (provider + model + SDK version) se envía por defecto con cada llamada al gateway. Para una granularidad superior, envíe una cabecera X-Mnemom-Lockfile-Hash en cada petición: el SHA-256 de su manifiesto de dependencias resuelto. AEGIS usa solo el digest hexadecimal — el lockfile en bruto no abandona nunca su entorno.

Con el lockfile-hash presente, el agregador puede atribuir las anomalías no solo a los «clientes que ejecutan este provider + model + SDK version», sino a los «clientes que ejecutan exactamente este árbol de dependencias resuelto». Es esa granularidad la que capta el parche SDK malicioso antes de que el resto del substrato lo vea.

# Opt into substrate-fingerprint granularity by sending the lockfile-hash
# header on every gateway request. The hash is computed over your
# resolved dependency manifest (package-lock.json, pnpm-lock.yaml,
# poetry.lock, requirements.txt) and never leaves your environment in
# raw form — only the hex digest reaches AEGIS.

curl https://gateway.mnemom.ai/v1/messages \
  -H "X-Mnemom-Api-Key: $MNEMOM_KEY" \
  -H "X-Mnemom-Lockfile-Hash: sha256:9f3b…" \
  -H "Content-Type: application/json" \
  -d @payload.json

La detección entre tenants atribuida al substrato no es algo que la categoría actual de seguridad de IA pueda adaptar a posteriori. Las razones son arquitectónicas, no de roadmap de producto.

Mnemom complementa estas herramientas. Los clientes que ejecutan Lakera Guard, NeMo Guardrails, Cloudflare WAF, AWS Bedrock Guardrails o Cisco AI Defense pueden ejecutar AEGIS en paralelo; el substrate fingerprint es la señal de red que nada más en la categoría produce.

Los indicadores substrate-fingerprint aparecen en el feed IoC público STIX 2.1 bajo el filtro type=substrate_fingerprint. En GA el feed está vacío por diseño — el calm-at-GA contract en /trust/iocs lo refleja. Los indicadores se publican cuando AEGIS cierra una campaña y se distribuye un advisory firmado en /trust/advisories.

# Subscribe to the substrate-fingerprint slice of the public IoC feed.
# STIX 2.1 Bundle; empty by design at GA per the calm-at-GA contract.

curl -sS 'https://api.mnemom.ai/v1/trust/iocs?type=substrate_fingerprint' \
  | jq '.objects[] | select(.type=="indicator")'