Vaara

El decorador impulsa el mismo motor que puedes llamar directamente cuando quieres el objeto de decisión en la mano.

from vaara.pipeline import InterceptionPipeline

pipeline = InterceptionPipeline()
result = pipeline.intercept(
    agent_id="agent-007",
    tool_name="fs.write_file",
    parameters={"path": "/etc/service.yaml", "content": "..."},
    agent_confidence=0.8,
)
if result.allowed:
    pipeline.report_outcome(result.action_id, outcome_severity=0.0)
else:
    print(result.reason)

Cada llamada recibe una puntuación de riesgo y una decisión de permitir / bloquear / escalar contra tu política, luego la llamada, la decisión y el resultado real se escriben en el registro de auditoría. report_outcome cierra el ciclo: el puntuador re-pondera según qué señales realmente predijeron el resultado. Las versiones incluyen procedencia SLSA Build Level 3, verificable con slsa-verifier verify-artifact. Clasificador ML opcional: pip install 'vaara[ml]'.

Escribir un registro es la mitad fácil. La mitad que importa es permitir que alguien que no confía en ti lo verifique, sin clave, sin acceso y sin ninguno de tu código. Cada registro de Vaara está direccionado por contenido y cierra en fallo en autenticidad, y se envía con vectores de conformidad públicos más un verificador independiente que no importa código de Vaara, por lo que una parte independiente reproduce cada veredicto sin conexión.

vaara verify-bundle evidence-bundle.json

ok solo cuando una firma está realmente establecida, no meramente presente en un registro. La misma propiedad impulsa el trabajo de estándares detrás del Vaara Receipt Internet-Draft: evidencia que se sostiene para alguien que no ejecuta ninguno de tu software. El conjunto completo de verificadores, el modelo de confianza para cada verbo y de dónde proviene la confianza en cada caso están en docs/verifying-evidence.md.

Para verificar esa afirmación tú mismo, sin instalar Vaara, ejecuta el verificador independiente contra los vectores publicados. Sus únicas dependencias son cryptography y rfc8785:

git clone https://github.com/vaaraio/vaara
cd vaara
pip install cryptography rfc8785        # the checker's only dependencies
python tests/vectors/external_evidence_v0/_check_independent.py

Re-deriva cada veredicto a partir de los bytes del recibo y la clave pública solamente. La salida muestra la propiedad para la que está construido el registro: un recibo eliminado de dentro de un límite declarado es una brecha demostrable del conjunto mantenido, sin acceso al emisor y sin testigo externo.

Para el ciclo completo en un solo archivo ejecutable, produce un registro firmado, verifícalo tú mismo y luego observa cómo se detecta un solo byte falsificado, consulta examples/prove-it-yourself/. El argumento de registros versus evidencia detrás de esto está en docs/logs-vs-evidence.md.

vaara compliance report --format json contra un registro real produce un registro de evidencia a nivel de artículo que un auditor lee directamente. Los artículos sin eventos registrados devuelven evidence_insufficient, no un sello de goma.

{
  "system_name": "Acme HR Assistant",
  "overall_status": "evidence_insufficient",
  "trail_integrity": {"size": 105, "chain_intact": true},
  "articles": [
    {"article": "Article 12(1)", "title": "Record-Keeping (Logging)",
     "status": "evidence_sufficient", "strength": "strong", "evidence_count": 105},
    {"article": "Article 15(1)", "title": "Accuracy, Robustness and Cybersecurity",
     "status": "evidence_insufficient", "strength": "absent", "evidence_count": 0}
  ]
}

Cada veredicto lleva la instantánea de umbral versus observado, la justificación y los registros subyacentes, por lo que un revisor rastrea status hasta un evento concreto. Los mismos datos se renderizan como un PDF de organismo notificado, un panel HTML estático o un sobre de entrega firmado con Sigstore. Consulta docs/COMPLIANCE.md.

• Controla cada llamada de herramienta que enrutes a través de él contra tu propia política: permitir, bloquear o escalar. La cobertura es lo que envuelvas; cada adaptador documenta la superficie que ve, y el plugin de Claude Code establece sus cuatro explícitamente.
• Un registro a prueba de manipulaciones que una parte externa verifica sin confiar en tu stack, con el encabezado de la cadena anclable a una marca de tiempo externa RFC 3161 / eIDAS para que su existencia sea demostrable contra un reloj que no controlas.
• Evidencia a nivel de artículo de la Ley de IA de la UE, honesta sobre las brechas en lugar de encubrirlas.
• Gobernanza de la llamada al modelo en sí, no solo de las herramientas a su alrededor: un recibo de inferencia con raíz en hardware que un segundo modelo local diferente verifica de forma cruzada. Este es el arnés de inferencia soberana, nuevo en v1.0.
• Aplicación, no solo un registro (v1.1.0): un intermediario de credenciales acuña una credencial firmada de corta duración vinculada al digesto de atestación y limitada a una herramienta, su compromiso de argumento y tenant, con ámbitos de capacidad tipados que limitan lo que una llamada puede hacer. Una puerta de enlace frente a una herramienta protegida rechaza cualquier llamada sin una concesión válida vinculada a la atestación, por lo que una evasión deja de ser silenciosa. Desactivado por defecto.
• Completitud con evidencia de brechas (v1.4.0): cada recibo de autorización puede llevar una secuencia firmada por límite y un conteo continuo, por lo que un recibo eliminado dentro de un límite declarado es una brecha demostrable solo con los recibos mantenidos, sin acceso al emisor y sin testigo externo (vaara verify-contiguity). Desactivado por defecto.
• Re-acuñación independiente (v1.14.0): un segundo generador en cada conjunto de vectores público reproduce el portador firmado byte por byte exacto solo desde la canonicalización declarada, sin importación de Vaara. Un verificador que nunca ha ejecutado software de Vaara reproduce los mismos bytes.

Los adaptadores nativos enrutan los principales frameworks de agentes de Python a través del mismo pipeline, cada uno a través del hook propio del framework, emitiendo eventos de auditoría idénticos:

Para poner Vaara delante de un servidor MCP, ejecútalo como proxy. Cada tools/call se enruta a través del pipeline antes de llegar al upstream; las llamadas permitidas se reenvían de forma transparente, las llamadas bloqueadas devuelven un error MCP.

vaara-mcp-proxy \
  --upstream npx --upstream-arg -y --upstream-arg @sap/mdk-mcp-server \
  --db ./mcp_audit.db --shadow

Comienza con --shadow: cada llamada se clasifica, puntúa y registra, nada se bloquea. Después de unos días, vaara trail shadow-report --db ./mcp_audit.db muestra qué habría hecho la aplicación; luego elimina la bandera y aplica, comenzando desde un perímetro listo para servidores MCP comunes en examples/policies/mcp-starters/. Apunta tu cliente MCP (Claude Code, Cursor, cualquier host) al proxy en lugar del upstream. También hay una API HTTP (pip install 'vaara[server]', vaara serve) y un cliente TypeScript de primera parte en npm (@vaara/client) para agentes que no son de Python. Los detalles del framework, los adaptadores de salvaguarda en la nube y OSS (Bedrock, Azure, GCP, NeMo, Guardrails AI, LLM Guard, Rebuff) y el proxy multi-tenant están en docs/adapters.md.

Una política es código, por lo que pertenece a la solicitud de extracción que la cambia. La acción valida la política, ejecuta sus casos y falla la compilación en una política que no se analiza, un caso que falla o un registro cuya cadena o firma no se sostiene.

- uses: vaaraio/vaara@v1
  with:
    policy: policies/production.yaml
    cases: policies/production.cases.yaml

Apunta trail a un zip firmado para verificar uno que un trabajo produjo. Sin una pubkey que verifica que el registro está internamente intacto; pasa una clave que obtuviste por separado para vincular también al firmante, y la ejecución dice cuál de los dos hizo. Entradas, salidas y fijación están en docs/github-action.md.

Esto verifica artefactos. Controlar al agente es el trabajo del runtime, en el momento de la llamada a la herramienta.

• Corpus adversarial de 25,556 entradas (250 seleccionadas a mano + 25,306 generadas por LLM). La división v0.40 asigna 24,619 de ellas sin fugas por celda (categoría, lote de generación): 15,114 de entrenamiento, 2,921 de validación, 2,980 de prueba, 3,604 de reserva.
• Clasificador v11 (236 características manuales + embeddings MiniLM de 384 dimensiones) con umbral 0.8800 en TEST reservado n=1,827: recall 85.6% [83.4, 87.6] con FPR 5.1% [3.8, 6.9]. El recall sube 0.9 puntos respecto a v9 y la tasa de falsos positivos sube 1.0. Ese intercambio es deliberado y el resto de esta sección explica por qué.
• Recall reservado entre modelos del 86.3% sobre n=5,600, contra ataques escritos por Qwen2.5-72B, un modelo ausente de TRAIN. v9 lee 67.4% en el mismo conjunto. La cifra publicada anteriormente aquí era 66.8% [64.9, 68.7], medida en v8 contra la superficie v0.37; que v9 la reproduzca dentro de un punto en una familia de atacantes diferente y con datos recién generados es la razón por la que ese número sobrevivió dos versiones sin cambios. Este sigue siendo el peor caso honesto, y el número dentro de la distribución anterior es el denominador más fácil.
• En cuatro categorías de ataque que el corpus apenas había cubierto hasta v0.40, medido en 5,600 entradas generadas después de fijar el punto de operación de v11: recall del 63.1% al 87.0% y falsos positivos del 6.6% al 2.5% frente a v9. Solo la exfiltración de credenciales pasa del 45.9% al 80.3% con FPR del 10.0% al 3.9%. Registro completo en bench/V11-CANDIDATE.md, incluido el candidato anterior que fue rechazado y por qué.
• FPR bajo presión BIPIA en llamadas de herramientas benignas: 0.0% [0.0, 1.6] en cuatro backends de agentes (Claude Haiku 4.5, Llama-3.1-8B, Mistral-7B, Qwen-2.5-7B). Baja del 1.2% en v9 y del 35.2% en v8.
• Robustez PAIR multi-atacante: 0/25 éxitos por atacante en Qwen2.5-32B, Qwen2.5-72B, Llama-3.3-70B con semillas idénticas, límite superior de Wilson 13.3%.
• Cobertura conforme libre de distribución en la puntuación; límite de arrepentimiento MWU O(sqrt(T log N)).
• Cadena de custodia: corpus, división, commit de entrenamiento y SHAs de paquetes bloqueados e impresos por cada script.

Método y desglose por celda: docs/architecture.md y bench/.

• vaara.receipt/v1 es la especificación principal canónica para el formato de recibo firmado: encadenado por hash, canonizado con JCS (RFC 8785), verificable sin conexión desde una clave pública. El enlace de liquidación x402 y un perfil de sello de tiempo cualificado eIDAS son perfiles posteriores que se anclan a él en lugar de formatos competidores. Los recibos pueden llevar un sello de tiempo RFC 3161 autoalojado que Vaara emite sin conexión.
• SEP-2828 registros de ejecución firmados, trasladados como el Internet-Draft de la IETF draft-sirkkavaara-vaara-receipt. Una segunda implementación independiente ha reproducido los vectores de conformidad SEP-2828 desde una copia limpia sin código compartido. Los corpus publicados con verificadores independientes cubren la ruta de enlace de respaldo (tests/vectors/fallback_projection_v0/) y las decisiones de gobernanza de CrewAI (tests/vectors/governance_decision_v0/).
• OVERT 1.0 (overt.is): Vaara es el Árbitro y emite Sobres Base del Perfil de Protocolo 1.0 (CBOR canónico, Ed25519) junto con cada registro cuando la atestación está activada.
• Post-cuántico: una firma paralela opcional ML-DSA-65 / FIPS 204 sobre la misma preimagen, de modo que una firma post-cuántica eliminada sea una degradación detectable en lugar de una pérdida silenciosa.
• Evidencia independiente de la raíz: el mismo registro del Artículo 12 es demostrable con o sin TEE de hardware y reexpresable en afirmaciones EAR de IETF RATS (vector AR4SI), ya sea anclado en un host TPM 2.0, una VM confidencial AMD SEV-SNP, o sin TEE en absoluto.
• Arnés de inferencia soberana (v1.0): un modelo local detrás de un proxy de firma que emite un recibo de inferencia anclado en hardware que un segundo modelo local verifica de forma cruzada. Desarrollado de forma privada, publicado aquí bajo AGPL-3.0.

Detalles y los verificadores sin conexión para cada uno: docs/standards.md.

La superficie pública está fijada: el sobre firmado (vaara.receipt/v1), las restricciones de capacidad, la concesión y puerta de enlace de credenciales, y el punto de entrada @vaara.govern. No se planean nuevas primitivas. El nuevo comportamiento se distribuye como perfiles que se anclan a vaara.receipt/v1, no como nuevos tipos centrales, y no se añadirán nuevos enlaces de formato (el último fue v1.13.0). A partir de aquí el trabajo es endurecimiento y sustracción dentro de esta superficie, de modo que cualquiera que construya sobre ella tenga un objetivo estable.