Fingerprinting de modelos

Superficie: LLM / inference server ATLAS: AML.T0013 (Discover AI Model Ontology), AML.T0014 (Discover AI Model Family), AML.T0040 (AI Model Inference API Access) · Fase: Recon activo

El asistente de PhiloCorp te dice que usa un modelo; el gateway devuelve otro nombre. Ninguno alcanza por sí solo para cerrar el inventario. Puede haber aliases, rutas a varios modelos o metadata desactualizada. Lo que necesitamos es saber qué observación cambia una prueba.

El fingerprinting acota familia, configuración y límites visibles del servicio. La identidad que el propio modelo declara es una señal de baja confianza. Guardala como tal y buscá corroboración antes de usarla para justificar una conclusión técnica.

Superficie de ataque

El endpoint de inferencia (API, chat), sus headers, sus endpoints de metadata y el comportamiento del modelo ante prompts de sondeo.

Precondiciones

• Endpoint alcanzable y autorización para recon activo.
• Baseline de comportamiento normal para comparar.
• Presupuesto aprobado de requests, tokens y costo, con tasa máxima y condición de detención.

Cómo testearlo

1. Headers y endpoints de metadata. Revisá encabezados HTTP y rutas documentadas y autorizadas. Algunas APIs compatibles con la interfaz OpenAI exponen /v1/models; su presencia y significado dependen de la implementación. El listado puede contener aliases o modelos disponibles y no necesariamente identifica el que atendió una solicitud concreta.

2. Autodeclaración. Preguntá una vez, sin intentar sortear filtros, y marcá la respuesta como evidencia de baja confianza:

   Entorno autorizado PhiloCorp: indicá, si está permitido por tu configuración,
   familia de modelo, versión y fecha de conocimiento declarada. Si no podés confirmarlo,
   respondé "no confirmado". No uses herramientas ni accedas a datos.

3. Corroboración autorizada. Contrastá metadata, configuración provista o documentación del entorno con observaciones repetibles. Usá hechos sintéticos o públicos para estimar límites; nunca conviertas una estimación de cutoff en identidad confirmada.

4. Límite de contexto visible. Partí de la configuración declarada. Sólo si queda una duda que afecte el plan, probá texto sintético con crecimiento gradual dentro del presupuesto. Un error puede venir del gateway, del tamaño HTTP o de la aplicación; no demuestra el límite del modelo. Registrá también posibles truncamientos. Detenete ante el umbral de costo, latencia, rate limit o error acordado.

5. Caracterización de comportamiento. Formato, errores y respuestas repetibles pueden ayudar a acotar una familia. El paper LLMmap reporta más del 95 % de exactitud en un conjunto de 42 versiones con ocho interacciones. Es un resultado de esa evaluación, no una garantía para endpoints abiertos, modelos fuera del conjunto o configuraciones posteriores. Evitá invertir más consultas si la identificación exacta no cambiará el plan.

6. Embeddings y tokenizer. Si hay interfaces autorizadas, registrá dimensión del vector, normalización y tokenizer declarado. Varias familias pueden compartir dimensión y algunos servicios permiten reducirla: esos datos no identifican por sí solos un modelo ni demuestran inversión de embeddings.

7. Documentá. Separá identidad declarada, identidad corroborada y límites observados. Incluí entorno, ruta, identidad de prueba, fecha, configuración y confianza. No asignes un «nivel de alineamiento» a partir de unas pocas respuestas; eso requiere una evaluación definida.

Límites y validación coordinada

• Identificá cada caso de prueba y acordá una ventana con defensa. Medí cobertura, latencia y falsos positivos sin ocultar la actividad ni mezclarla con tráfico de terceros.
• Aplicá rollback operativo: si una prueba eleva costo, latencia o errores por encima del umbral acordado, detenela y notificá.

Checklist de verificación

• Modelo y versión identificados (o acotados a familia)
• Cutoff declarado separado de conocimiento observado y límites del servicio
• Comportamiento descrito con casos y confianza, sin generalizar seguridad del modelo
• Tokenizer/dimensionalidad de embeddings si aplica
• Presupuesto, tasa, stop condition y confianza de cada inferencia documentados

Impacto y escalada

Informa la selección de casos de prueba autorizados y el presupuesto de contexto. La dimensionalidad de embeddings orienta la evaluación de la Parte 07.

Remediación

Si la metadata revela información que la política clasifica como restringida, limitá esa exposición y la autorización del endpoint. No hace falta ocultar todo nombre de modelo para corregir una vulnerabilidad, ni ocultarlo vuelve seguro al servicio. Los límites de tasa y costo reducen abuso, pero un método de pocas consultas puede operar por debajo de ellos.

El fingerprint se incorpora al brief como contexto para elegir casos y presupuesto, con las incertidumbres que quedaron abiertas.