Crown jewels y trust boundaries
- Parte
- 02
- Estado
- Revisado
- Edición
- v2 / 01.09.2026
- Tiempo estimado de lectura
- 4 min
Edición del 1 de septiembre de 2026
Las fuentes conservan sus fechas de consulta. El laboratorio identifica la simulación determinística y la integración con modelo por separado.
Tipo: Proceso · Fase: Recon → Explotación
El modelo se lleva todas las miradas en la reunión de PhiloCorp. Sin embargo, el permiso que usa una herramienta para modificar tickets podría tener más impacto que los pesos del modelo. Antes de perseguir la pieza más llamativa, conviene preguntar qué pérdida o cambio le dolería al negocio y qué ruta podría producirlo.
Llamamos crown jewels a esos activos prioritarios y trust boundaries a las fronteras en las que cambia la identidad, el permiso o la confianza concedida a una entrada. El resultado es un mapa de prioridades con decisiones de avance, no una lista de cosas que hay que extraer.
Priorizar los activos
Ordená los activos por impacto, exposición y alcanzabilidad demostrada. Incluí también los controles existentes y la incertidumbre. Una ruta de alto impacto todavía hipotética puede merecer una validación breve antes que una técnica vistosa sobre un activo de poco valor.
En PhiloCorp, este sería un inventario inicial para contrastar con el alcance:
| Activo candidato | Por qué importa | Qué evidencia sintética alcanza para empezar |
|---|---|---|
| Identidades de plataforma y permisos cloud | Pueden conectar el agente con acciones de infraestructura | Política y resultado de autorización sobre un recurso de laboratorio |
| Políticas y reglas de detección | Su exposición o modificación puede debilitar controles | Clasificación de acceso y prueba con una regla sintética |
| Corpus de procedimientos internos | Puede contener conocimiento restringido o influir en decisiones | Documento sintético con ACL conocida y trazabilidad de recuperación |
| Identidades y tokens de agente | Determinan a qué herramientas y datos se accede | Metadatos sanitizados de audiencia, vigencia y permisos, sin copiar tokens |
| Pesos y adaptadores de modelo | Pueden representar propiedad intelectual o contener cambios no aprobados | Integridad, procedencia y autorización sobre un artefacto sintético |
| Catálogo y esquemas de herramientas | Describen capacidades y pueden influir en su selección | Listado autorizado comparado con la política de publicación |
No presupongas dónde están guardados estos activos. Una regla de detección no tiene por qué vivir en una base vectorial, ni una identidad de agente usar JWT o Kubernetes. Esas son preguntas para el registro de supuestos.
Zonas y fronteras de confianza
Una frontera aparece cuando un flujo necesita una nueva decisión de confianza. Puede existir entre servicios o dentro del mismo proceso. Un clasificador que recomienda «aprobar» también participa de esa decisión, pero su salida no equivale a autorización.
El framework CSA MAESTRO ayuda a revisar las capas de la arquitectura. No hay una correspondencia obligatoria de una frontera por capa: varias fronteras pueden estar dentro de una sola capa, y un control puede atravesar varias.
| Frontera de ejemplo | Qué cambia | Control que habría que verificar |
|---|---|---|
| Usuario → orquestador | Identidad y solicitud de entrada | Autenticación y autorización de la operación |
| Orquestador → agente | Delegación de una tarea | Identidad autenticada y alcance explícito de la delegación |
| Agente → recuperación | Acceso a documentos de un tenant | ACL por recurso y filtro aplicado con la identidad correcta |
| Agente → servidor MCP | Propuesta de llamada a herramienta | Permisos sobre herramienta, parámetros y recurso |
| Herramienta → gestor de secretos | Acceso a una credencial de servicio | Autorización mínima y entrega fuera del contexto del modelo |
| Agente de triage → ejecución | Una clasificación pasa a ser una acción | Validación de política y aprobación cuando corresponda |
mTLS puede autenticar extremos y proteger el canal; no decide por sí solo si una acción está permitida. Del mismo modo, un esquema válido no prueba autorización y una clasificación convincente no prueba que haya aprobación. Esas diferencias son las que vamos a seguir en cada cadena.
Escalation paths y go/no-go
Enumerá las rutas de escalada relevantes, incluidas las prohibidas sólo como riesgo documentado, y marcá cada una con: prerrequisitos y su estado de validación, fronteras cruzadas, crown jewels afectados, costo de tiempo/tokens/dinero, radio de impacto, rollback, condición de detención y estado RoE (PERMITIDO / RESTRINGIDO / PROHIBIDO). La matriz permite decidir qué ruta probar, cuál dejar pendiente y cuál cerrar.
Para cada supuesto crítico, nombrá la validación mínima, su costo y la señal que esperás ver. Agrupá las pruebas que requieren coordinación en la ventana acordada. Si el control rechaza una acción y la traza lo confirma, esa ruta puede cerrarse sin buscar otro modo de llegar al activo.
La matriz pasa al brief con una razón para cada decisión: PERMITIDO describe el alcance, pero no obliga a ejecutar una prueba que ya no aporta evidencia.
Checklist
- Activos priorizados por impacto, alcanzabilidad y evidencia disponible
- Fronteras mapeadas, incluidas las decisiones que usan una salida del modelo
- Escalation paths enumerados con estado RoE, costo, rollback y stop condition
- Validaciones baratas antes que ejecución especulativa