El proceso de decisión

Cada solicitud de tocar un secreto — venga del usuario en la terminal, del Dashboard o de un agente de IA — pasa por una decisión. Esa decisión se toma en un solo lugar y es la misma para cada canal; ninguna interfaz puede inventar sus propias reglas. Esta página recorre esa decisión en detalle, pero conceptualmente — qué se sopesa y en qué orden, no cómo está codificado.

La visión general “cómo funciona” muestra los flujos cotidianos; esta es la comprobación que se asienta debajo de todos ellos.

Los cuatro resultados posibles

Cada solicitud se resuelve a exactamente uno de estos:

• Permitir — proceder, sin prompt.
• Confirmar, luego permitir — proceder solo después de un bioProve.
• Denegar — rechazada, con una razón registrada para auditoría (nunca el valor).
• No direccionable — el secreto no existe para este canal. Esto no es una denegación a posteriori; la solicitud nunca llega siquiera a resolverse a un secreto real.

El orden de evaluación

El orden importa, porque las comprobaciones más baratas y fuertes vienen primero.

1. ¿Está siquiera en scope?

Antes que nada, kovra pregunta: ¿están esta coordenada, y esta operación, dentro del scope del canal que pregunta? Si no, la respuesta es no direccionable — el secreto nunca se expone, nunca se resuelve, nunca queda “casi entregado”. Esto es defensa en profundidad deliberada: a un canal no se lo puede engañar para que filtre algo que nunca tuvo permitido alcanzar, porque para ese canal el secreto simplemente no existe. Un agente que ha sido manipulado todavía no puede pedir lo que su scope excluye.

2. ¿Qué clase de operación es esta?

Hay tres cosas que se pueden hacer con un secreto, y conllevan riesgos muy distintos:

• Leer metadatos — listarlo, comprobar su estado, ver su fingerprint. Ningún valor se toca jamás, así que si es direccionable, está permitido.
• Inyectar — enviar el valor a través de una operación a un proceso que lo necesita. El valor fluye a través; nunca vuelve al llamador.
• Revelar — traer el texto plano de vuelta a las manos del llamador. Este es el único camino donde un valor aterriza en algún lugar que un humano o un modelo pueden leer, así que es el más resguardado.

3. Para un reveal — ¿quién pregunta, y cuán sensible es?

Los reveals se juzgan por cuatro cosas en conjunto: la sensibilidad del secreto, su entorno, el canal que pregunta y el origen (un humano actuando deliberadamente, o un agente). Las reglas, en términos llanos:

• Los secretos más protegidos (inject-only) nunca se revelan — a nadie, en ningún canal. Solo pueden inyectarse.
• El canal de agente nunca recibe el texto plano de un secreto high, un prod o un inject-only. Lo único que puede leer de vuelta es un secreto ordinario, no de producción, que se haya marcado explícitamente como revelable — y nada más.
• El Dashboard nunca muestra el texto plano de los secretos más sensibles; los muestra enmascarados, solo con metadatos.
• El texto plano de producción puede llegar al contexto de un agente solo a través de un reveal que un humano inicia a propósito, confirmado con biometría — nunca uno que un agente pueda iniciar, y nunca por defecto.
• Un reveal ordinario en la propia terminal procede; uno de sensibilidad high primero pide hacer bioProve.

4. Para una inyección — ¿necesita confirmación?

La inyección es más segura que revelar, porque el valor pasa a través hacia un proceso en vez de volver al llamador. Que se pause para una confirmación depende de la sensibilidad sola: un secreto high pide un bioProve antes de inyectarse; los secretos ordinarios (e inject-only, cuya única entrega es la inyección) fluyen a través sin prompt. El entorno no cambia esta parte.

5. Para una inyección high o de producción — ¿a dónde tiene permitido ir?

Hay un segundo guard independiente sobre las inyecciones más riesgosas. Enviar un valor high o prod a un programa que el propio agente escribió frustraría el propósito — ese programa podría simplemente imprimir el valor de vuelta. Así que esas inyecciones solo se permiten hacia un ejecutable que ha sido revisado y allowlisted. Esto es separado del prompt de confirmación: trata de a dónde puede ir el valor, no de si se preguntó. Un secreto de producción deliberadamente bajado de nivel puede por lo tanto inyectarse sin prompt, pero aun así solo hacia un programa allowlisted.

6. Cuando se necesita una confirmación, el prompt no puede falsificarse

Si la decisión es “confirmar primero”, el texto que se ve lo construye kovra misma a partir de los hechos reales de la solicitud — el comando exacto, la coordenada, la sensibilidad — y nunca de quien hizo la solicitud. Un atacante (o un agente manipulado) no puede entregar un prompt de apariencia tranquilizadora que oculte lo que en realidad se está aprobando. Cualquier descripción de formato libre provista por un llamador se mantiene separada y claramente marcada como no confiable.

7. Todo queda registrado

Sea cual sea el resultado, kovra lo escribe en el registro de auditoría: la acción, la coordenada, el resultado y quién lo inició. El registro nunca contiene un valor de secreto, y nunca un fingerprint lo bastante completo como para confirmar una conjetura. Se puede ver qué pasó sin que nada de ello se convierta en un nuevo lugar donde un secreto podría filtrarse.

Juntándolo todo — algunos recorridos

• Un agente corre la suite de tests, que necesita una contraseña de base de datos dev. ¿En scope? Sí. ¿Operación? Inyectar. ¿Sensibilidad? Ordinaria. → Permitido, sin prompt; el valor fluye al proceso de test, nunca al contexto del agente.
• Un agente pide leer una API key de prod. ¿Operación? Revelar. ¿Canal? Agente. → Denegado — el texto plano de producción nunca entra al contexto de un agente, punto.
• Se pide, en la terminal, inyectar un secreto prod en la herramienta de despliegue. La sensibilidad es high (producción nace high), así que kovra pide confirmar; y como es producción, la herramienta de despliegue debe ser un ejecutable allowlisted. Confirmado y allowlisted → se ejecuta.
• Un agente lista los secretos en un proyecto que no tiene en scope. → No direccionable — esos secretos no existen para esa sesión en absoluto.