Modelo de amenazas

kovra está construida alrededor de un solo trabajo: dejar que las herramientas y agentes de IA usen secretos sin ver los sensibles. Esta página lo dice claramente — los activos que protege, los adversarios contra los que está diseñada y los límites que no cruza. Una herramienta de seguridad que exagera sus garantías es peor que una que es honesta sobre ellas.

Activos

• Valores de secretos — literales, las mitades privadas de los keypairs, y las semillas TOTP.
• La master key — la raíz de confianza que cifra todo el vault.
• La integridad del registro de auditoría — un registro fiel de lo que pasó.

Lo que kovra está diseñada para detener

• Un agente de IA con prompt-injection o secuestrado exfiltrando secretos. Un agente corre bajo un scope y nunca recibe el texto plano de un secreto high, prod o inject-only. Las coordenadas fuera de scope son no direccionables — no existen para esa sesión, así que un agente manipulado no puede alcanzar lo que nunca se le otorgó.
• Un programa leyendo de vuelta un valor que se le dio. Enviar un valor high/prod a un programa que el propio agente escribió frustraría el propósito, así que esas inyecciones solo se permiten hacia un ejecutable revisado y allowlisted. La allowlist fija el contenido del programa — una edición lo saca de la lista — y rechaza los intérpretes y lanzadores genéricos (sh, bash, env, python, node, make, …), que ejecutarían cualquier script que se les pase. Esa ejecución recibe además un entorno saneado: un PATH fijo y ninguna de las variables que hacen que un shell, un intérprete o el cargador dinámico ejecuten código adicional.
• Texto plano filtrándose a los lugares donde suele filtrarse. Los valores nunca aterrizan en un log, en disco, en argv, en el historial del shell ni en la ventana de contexto de un modelo.
• Un secreto commiteado por accidente. Un pre-commit hook escanea los cambios staged y bloquea el commit.
• Una laptop perdida o robada, o una inspección casual del disco. Cada registro está cifrado en reposo bajo la master key (custodiada en el keyring del SO, o derivada con Argon2id), y las coordenadas no se exponen como nombres de archivo en texto plano.

Garantías dentro de alcance

• Los reveals e inyecciones sensibles requieren un bioProve deliberado — nunca ocurren por su cuenta, y nunca a pedido de un agente para high/prod.
• El prompt de confirmación lo construye kovra a partir de la solicitud real, de modo que no puede ser falsificado por un llamador. Muestra el entorno, el secreto y quién lo pide antes del comando, y todo valor en el que un llamador puede influir se muestra escapado, de modo que ninguno puede agregar una línea propia ni sacar de la vista los campos reales. Los comandos, rutas y referencias largos se muestran completos, en varias líneas que kovra marca como continuación (una sangría y ↪). Los espacios que podrían empujar un valor fuera de la vista se muestran visibles: una secuencia de tres o más espacios como un marcador con su largo ([␣×120]), y cualquier otro espacio escapado. En una Mac toda aprobación se lee en la ventana de kovra, que muestra cada campo completo por largo que sea y se desplaza, de modo que nada se muestra cortado y solo se rechaza por su largo una solicitud de más de 1 MiB de texto o de 1 000 secretos, que ningún comando que pueda arrancar alcanza (para que no congele la pantalla); donde el aviso es un diálogo del sistema con lugar para pocas líneas (Windows Hello), lo que es demasiado largo para mostrarse completo se rechaza, con el motivo.
• El registro de auditoría registra cada resultado sin almacenar un valor o un fingerprint completo.
• Los valores críticos — high, inject-only y todo valor de prod — no muestran fingerprint, de modo que ni siquiera uno truncado puede confirmar una conjetura.
• Una master key sustituida se detecta: la bóveda guarda una comprobación de la clave, y kovra se niega a leer o sellar con una clave que no la abre.

Fuera de alcance — los límites honestos

• La última milla. Una vez que un valor se entrega al proceso que lo necesita, vive en la memoria de ese proceso bajo las reglas de ese programa. kovra asegura la custodia y la entrega, no lo que un programa hace con un valor después de tenerlo.
• Un host comprometido. kovra confía en el keyring del sistema operativo, en su subsistema biométrico y en la integridad de la propia máquina. Un compromiso a nivel de root, un keylogger de kernel o malware leyendo la memoria de otro proceso queda fuera de lo que una herramienta de userspace puede defender.
• Un humano (o programa) que el usuario autoriza. kovra hace que una acción sensible sea deliberada y atribuible — no la hace imposible. Si se hace un bioProve de una acción mala, o se allowlista un programa malicioso, kovra la llevará a cabo y la registrará.
• Subir la sensibilidad después. Pasar un secreto a high o inject-only lo protege desde ese momento; no recupera un valor que ya se mostró o se entregó. Si pudo quedar expuesto, rótelo.
• Los archivos de la bóveda. kovra no guarda copias anteriores de un registro, pero un programa que corre con su usuario todavía puede copiar, borrar o reponer los archivos de la bóveda con el shell. Es un límite del sistema de archivos, no algo que una aplicación pueda impedir; un respaldo de la bóveda guarda la sensibilidad que cada secreto tenía al hacerlo.
• Confianza en el proveedor cloud. Una referencia cloud se resuelve bajo la identidad de proveedor del usuario; el proveedor sigue viendo lo que siempre vería.
• La sesión de su CLI cloud. Una referencia se resuelve con la propia sesión del usuario en el proveedor (az, aws). Un agente que corre con su usuario, con esa CLI con sesión iniciada, puede leer el secreto del proveedor directamente: high en una referencia gobierna lo que entrega kovra, no lo que permite su sesión cloud.
• El ítem del Llavero. En macOS, cualquier programa que corre con su usuario puede borrar o reescribir el ítem del Llavero que guarda la master key, sin ningún prompt. Es un límite del sistema operativo. kovra no puede impedirlo, pero lo detecta: una clave sustituida detiene a kovra en lugar de sellar secretos nuevos bajo una clave que el agente conoce, y una clave borrada deja la bóveda ilegible hasta que se restaure con kovra key import — una denegación de servicio, no una divulgación.
• Lo que lee un programa de la allowlist. La allowlist fija el archivo que usted revisó, no los archivos que este lee (un script que incluye, un archivo de configuración). Un programa que corre con su usuario y sustituye el archivo entre la última comprobación de kovra y el lanzamiento es, otra vez, un límite del sistema de archivos.

Supuestos de confianza

kovra asume: que la máquina y el SO no están ya comprometidos; que el keyring del SO y el prompt biométrico se comportan como la plataforma pretende; y que las bibliotecas criptográficas verificadas sobre las que se construye son sólidas. No implementa criptografía propia — ver Criptografía.