Vaara mapping to OVERT 1.0 Part 3 (Agentic AI Controls)

May 31, 2026 · View on GitHub

OVERT 1.0 Part 3 (Sections 11-16) defines the agentic-specific execution controls: tool-call governance, MCP server trust, multi-agent boundaries, capability mediation, agent disclosure, human-in-the-loop attestation, and behavioural drift governance.

The mapping below states, control by control, whether Vaara satisfies the requirement today (✅), partially satisfies it (◐), or leaves it as explicit gap-to-deployer or future work (◯). This mapping does not establish legal compliance with any regulation. It records technical correspondence.

The companion mapping to the OWASP Top 10 for Agentic Applications 2026 lives in OWASP_AGENTIC.md. The two documents address overlapping concerns from different framings: OVERT 1.0 Part 3 names enforcement controls, OWASP names threat classes. The longer architectural context (Position relative to open runtime-attestation standards, S3P, OVERT envelope binding to a hardware-rooted measurement) lives in COMPLIANCE.md.

Source

OVERT 1.0 (Glacis Technologies). Project page: overt.is. The "Part 3 (Agentic AI Controls)" designation covers Sections 11 through 16 plus the S3P measurement primitive in Section 9, MEA-2.

Section 11 - Tool-Call Governance

  • TOOL-1.1 (intercept all tool calls before execution) - ✅. InterceptionPipeline.intercept() is the enforcement boundary. No tool call proceeds without a governance decision.
  • TOOL-1.2 (evaluate against capability policy) - ✅. The policy DSL declares permitted tools, parameter ranges, destinations, and approval gates. policy.evaluate returns the verdict carried in the per-call receipt.
  • TOOL-1.3 (denial receipt with policy reference and violation type) - ✅. Denials emit a DENY event on the hash chain with policy id and violation reason.
  • TOOL-1.4 (provisional receipt before execution, upgrade to full attestation after notary validation) - ✅ structurally at AAL-3, with the AAL-3 to AAL-4 path now implementable in-tree. The Article 12 commit-prove receipt pair (shipped v0.10.0) is the Phase 2 Provisional Receipt. The v0.11.0 OVERT Base Envelope is the attested form. v0.13.0 ships a reference Phase 3 IAP (vaara.attestation.iap.emit_phase3_attestation) that notary-signs the Provisional Receipt and anchors it in a transparency log. Reaching AAL-4 still requires the notary keys to live with an independent operator.
  • TOOL-2.1 (explicit function allowlist with hash in policy attestation) - ✅. Policy hash flows into encoder_binary_identity in the Base Envelope (v0.11.0).
  • TOOL-2.2 (parameter schema validation before execution) - ✅ for declared parameter shapes. ◐ for arbitrary deep schemas (the policy DSL is intentionally bounded).
  • TOOL-2.3 (rejection receipt with parameter violation detail) - ✅.
  • TOOL-3.1 (per-tool rate limits with attested enforcement) - ◐. The adaptive scorer applies velocity-aware risk signals. Explicit per-tool calls-per-epoch counters are not yet emitted as standalone receipts.
  • TOOL-3.2 (per-session / per-user velocity caps) - ◐ via the agent profile in scorer/adaptive.py.
  • TOOL-3.3 (circuit breakers on error / violation rate) - ◐ in policy DSL. Circuit-breaker receipt not yet a first-class artefact.
  • TOOL-3.4 (recursion-depth termination per trace_id) - ◯. Not implemented. Agent-loop termination is currently the deployer's responsibility.
  • TOOL-4 (human approval gates) - ◐. The SQLite-backed review queue (vaara.audit.review_queue) routes ESCALATE verdicts to human reviewers and records ESCALATION_RESOLVED events with reviewer identity, timestamp, and decision. TOOL-4.4 approval- velocity caps are not enforced.
  • TOOL-5 (tamper-evident tool-call log with epoch attestation) - ✅ for TOOL-5.1 and TOOL-5.2 (hash-chained AuditTrail, Article 12 commit-prove receipt pair). TOOL-5.3 epoch notary attestation is satisfied by the v0.13.0 reference IAP (vaara.attestation.iap) paired with the in-process transparency log. A sigstore Rekor-backed log can substitute at the same call sites.

Section 11.5 - MCP Server Trust Governance

Vaara ships an MCP server (vaara.integrations.mcp_server) that exposes governance tools to MCP clients. It does not currently act as an MCP client governing tools hosted on third-party MCP servers. The MCP-1/2/3 control set therefore applies to Vaara only in the custom (operator-hosted) mode (MCP-2): the operator runs the Vaara MCP server in their own environment.

  • MCP-2.1 (server binary identity in co-epoch binding) - ◐ at v0.12.0: arbiter binary identity is captured in encoder_binary_identity. A dedicated MCP-server binary identity field is future work.
  • MCP-2.2 (network topology attestation) - ◯. Deployer concern. Vaara does not measure its own network position.
  • MCP-2.3 (per-call authorization at the MCP server boundary) - ✅. Every MCP tool invocation passes through intercept().
  • MCP-2.4 (configuration change detection within an epoch) - ◯. Future work.
  • MCP-1 and MCP-3 (managed-vendor and external-third-party MCP servers) - outside Vaara's current surface. An operator using Vaara as the governor in front of a third-party MCP server would need adapter work. The architecture admits it but no implementation ships today.

Section 12 - Multi-Agent System Controls

  • MULTI-1 (inter-agent trust boundaries) - ◯. Per-agent policy evaluation works today (each intercept() call carries an agent_id), but agent-vs-agent trust separation is not enforced beyond what the deployment policy declares.
  • MULTI-2 (agent composition / topology attestation) - ◯. Deployer-side documentation. No Vaara-emitted topology receipt.

Section 13 - Capability-Based Access Control

  • CAP-1 (data provenance tracking) - ◐. The taxonomy and policy DSL accept provenance tags on actions. Transformation propagation (CAP-1.2) is the deployer's responsibility because Vaara intercepts tool calls, not arbitrary data transformations inside the agent process.
  • CAP-2 (architectural separation of planning from untrusted data) - ◯. AAL-2 documentation at most. This is a deployer-side architecture choice that Vaara records but does not enforce.

Section 14 - Agent Disclosure and Transparency

  • DISC-1.1 (capability documentation) - ◐ via the deployer's policy file + vaara compliance report.
  • DISC-1.2 (AIBOM in CycloneDX-AI or SPDX 3.0) - ◯. Future work. The auditor-facing evidence export (v0.10.0) is a candidate surface to embed AIBOM references.
  • DISC-1.3 (attestation summary with coverage ratio, S3P signals, override frequency) - ◐ from v0.12.0: Vaara emits S3P attestations (vaara.attestation.s3p) carrying coverage ratio and binomial CI. The deployer aggregates these for disclosure.

Section 15 - Human-in-the-Loop Attestation

  • HITL-1 (consent attestation) - ◯. Deployer-side concern. Vaara does not collect end-user consent.
  • HITL-2 (human review attestation) - ◐. Review-queue resolution events on the audit chain carry reviewer identity (when supplied by the deployer), timestamp, decision, and reference to the original ESCALATE verdict by action_id. AAL-4 identity binding is the deployer's responsibility.
  • HITL-3 (human correction and override) - ◐ via report_outcome and the review-queue resolution event.
  • HITL-4 (policy and configuration approval with separation of duties) - ◯ at the receipt level. Policy-change approval is currently a git-history artefact, not an attested OVERT event.
  • SESS-1..5 (session-scoped attestation) - ◯.
  • STATE-1, STATE-2 (durable state sealing and prompt artifact binding) - ◯.
  • IDENT-1 (federated identity / token provenance chain) - ◐. vaara.auth accepts authenticated caller identity into the audit record. Full delegation-chain attestation per IDENT-1.2 is future work.

Section 16 - Behavioural Drift Governance

  • DRIFT-1 (baseline intent declaration) - ◯. Future work. The policy DSL is the candidate surface for machine-readable behavioural bounds.
  • DRIFT-2 and downstream drift controls - ◐ in spirit. The adaptive scorer tracks coverage error via FACI (scorer/adaptive.py) and emits drift signals through audit events, but these are not yet packaged as DRIFT-* receipts.

S3P (Section 9, MEA-2) statistical safety signal

S3P sits in Domain 5 (MEASURE), not Part 3, but it is the agentic- relevant measurement primitive that ties everything above together.

  • MEA-1 (deterministic sampling infrastructure) - ◯. Vaara evaluates every intercepted action. Sampling-rate-based measurement is opt-in. A deployer who wants S3P sampling provides the PRF tag and threshold.
  • MEA-2.1 (epoch nonce commitment) - ✅ via vaara.attestation.s3p.make_epoch_nonce_commitment.
  • MEA-2.4 (exact binomial CI) - ✅. Pure-Python Clopper-Pearson via the regularized incomplete beta function. No scipy dependency.
  • MEA-2.6 (closed-schema S3P attestation, Ed25519-signed, canonical CBOR per Protocol Profile 1.0) - ✅ via emit_s3p_attestation.
  • Vaara conformal extension (proposed Protocol Profile extension): the ConformalExtension field reports aggregate statistics over Vaara's per-action conformal prediction intervals alongside the standard Clopper-Pearson CI. The conformal aggregates carry the same non-parametric coverage guarantee with no distributional assumption, exactly the property MEA-2.4 requires from a method offered as an alternative to (or complement of) Clopper-Pearson. The extension rides in a single field in the signed metadata. Standard OVERT verifiers ignore it.