Una herramienta de seguridad que exagera lo que sabe es peor que no tener herramienta: te da una falsa sensación de seguridad. Por eso cada arista del mapa de accesos lleva dos etiquetas de fidelidad independientes, y el producto las representa con honestidad — nunca disfraza una arista apenas conocida como una arista probada.
Los dos ejes responden a dos preguntas distintas:
- Cobertura — hasta qué punto la fuente puede probar si este acceso fue una lectura o una escritura.
- Atribución — con qué firmeza el acceso se vincula a un único agente, frente a una identidad compartida.
Se mueven de forma independiente. Un warehouse con auditoría nativa ofrece una cobertura limpia; si todos los agentes comparten una sola cuenta de servicio contra él, la atribución sigue siendo solo aproximada. Ninguno de los dos ejes se infiere del otro.
Cobertura: lectura frente a escritura
La cobertura describe qué puede decirnos el almacén subyacente sobre la naturaleza de lectura/escritura de un acceso. Es una propiedad de la fuente, no del agente.
clean— el almacén emite auditoría nativa y autoritativa, así que la lectura frente a escritura se clasifica de forma literal. Este es el caso de Postgres mediante pgAudit, el almacenamiento de objetos mediante CloudTrail (s3.readOnly), y los warehouses y lakes (Snowflake, BigQuery, Redshift, Databricks, MSSQL, Oracle), además del ground truth de eBPF a nivel de kernel.lossy— el almacén produce aristas, pero burdas. Los almacenes de documentos (por ejemplo MongoDB) caen aquí: existe una arista, pero la separación entre lectura y escritura es aproximada.opaque— el almacén no da ninguna señal pasiva de lectura/escritura. Redis, SQLite y D1 no pueden reconstruirse observándolos, así que elmodede la arista se marca comounknownen lugar de adivinarse.
También existe un nivel mixed para señales cooperativas o a nivel de herramienta — herramientas MCP, APIs HTTP, tareas de agentes — que no están atadas a una clase de almacén.
La regla cardinal: donde un almacén es opaque, la clasificación de lectura/escritura es unknown, nunca inventada. Y una arista ausente en una fuente lossy u opaque no es prueba de que un acceso no ocurriera — solo de que la fuente no pudo probar que sí. Esa es la diferencia entre permitido y observado.
Atribución: qué agente
La atribución describe con qué firmeza un acceso observado se vincula de vuelta a un agente concreto. Los logs de auditoría atribuyen la actividad a una credencial o a un rol, no inherentemente a un agente — así que este eje es más estricto que la mera confianza en la señal, y es deny-closed: sin una señal firme por agente, se mantiene bajo.
firm— el acceso se resuelve sin ambigüedad a un único agente. Esto requiere una señal de identidad real por agente: un SVID de workload SPIFFE, una cuenta de servicio con federación de identidad de workload, una identidad no humana dedicada acuñada por la gobernanza, o una credencial vinculada a exactamente un agente.approximate— se conoce una identidad, pero no se puede fijar un único agente. Una cuenta de servicio compartida o agrupada detrás de un pool de conexiones, una credencial ambigua, o un vínculo por agente que sigue pendiente aterrizan todos aquí.unknown— no es posible ninguna atribución por identidad en absoluto. Este es el suelo para un almacénopaquevisto por un backstop no cooperativo, o para un acceso que no se vincula a ninguna identidad. Nunca un agente fabricado.
Como la atribución es deny-closed, una señal posterior y más débil nunca puede degradar una arista atribuida con firmeza — pero una señal fuerte sí puede elevar una débil. Los dos ejes también interactúan en una única dirección: en un almacén opaque, cualquier atribución que no llegue a firm se rebaja al suelo de unknown, en lugar de hacerse pasar por una conjetura de cuenta compartida disfrazada de approximate.
La identidad por agente es, por tanto, una dependencia dura para el mapa de alta fidelidad. Gobernar bien significa emitir identidad por agente — véase Identidad y el modelo de gobernanza.
Por qué esto importa
El sentido de etiquetar ambos ejes es la contención. El producto no destacará una arista lossy/approximate como una infracción de la misma manera que lo haría con una clean/firm, y expone unknown y approximate abiertamente en lugar de ocultarlos. Un hallazgo de drift que el sistema todavía no puede atribuir con firmeza se marca como pendiente de reconciliación, no se representa como una brecha confirmada.
Por eso se puede confiar en el mapa de accesos como evidencia y no como una conjetura: cada arista dice, en dos dimensiones, exactamente cuánto sabe. Donde sabe poco, lo dice.
Dónde aparecen estas etiquetas
Ambas etiquetas viajan en cada arista de la API de grafo y de la capa superpuesta de la UI, junto con la fuente de señal que produjo la arista. Leer el grafo de accesos es una acción privilegiada, con ámbito de tenant y completamente auditada.
Las formas exactas a nivel de campo para el grafo del mapa de accesos y para el drift viven en las interfaces tipadas del producto y deliberadamente no forman parte del contrato OpenAPI servido — véase los módulos de referencia y la página de honestidad y límites para conocer el límite completo de lo que está probado frente a lo inferido.
Relacionado
- El mapa de accesos — qué es una arista y cómo se construye.
- Permitido frente a observado — el drift de mínimo privilegio que estas etiquetas matizan.
- Honestidad y límites — el contrato completo sobre qué se ejecuta, qué está en fase de diseño y qué el producto deliberadamente no hace.