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@ver, 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 la estratificación L0-L5; véase la migración 217 para la forma del data plane.)

{
  "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 solo cliente puede parecer irrelevante de manera aislada. En todos los clientes que se ejecutan sobre el mismo substrate fingerprint, la misma desviación de comportamiento enciende las estadísticas rodantes del agregador L1. AEGIS atribuye la anomalía al substrato, eleva automáticamente el bucket dentro del techo configurado por el cliente (según el modelo under-attack de ratcheting aditivo) y una Managed Rule firmada llega a cada gateway con P95 ≤ 30 segundos desde la promoción firmada hasta la carga en la gateway. (Véase /trust/slos.)

El substrate fingerprint base (provider + model + sdk@ver) se envía por defecto con cada llamada a la 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», 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")'