CAVA: Canonical Action Verification and Attestation for Runtime Governance of Agentic AI Systems Zexun Wang∗ Ond Holdings Inc. June 2026
arXiv:2607.13716v1 [cs.AI] 15 Jul 2026
Abstract Agentic AI systems increasingly act through heterogeneous runtimes: local coding hooks, SDK tools, browser automation, managed-agent traces, API gateways, and workflow engines. A single operational act such as publishing code, changing identity state, moving money, or exporting data may therefore be represented by many incompatible runtime records. This makes a basic governance question difficult to answer: what action was actually approved, what evidence binds the approval to execution, and can an independent verifier reproduce the same action identity later? This paper presents Canonical Action Verification and Attestation (CAVA), a runtimesemantics layer for converting heterogeneous agent activity into canonical runtime action objects. CAVA is positioned below Proof-Carrying Agent Actions (PCAA): PCAA defines the deployerowned route-review-prove governance process, while CAVA defines the stable action object that process governs. The paper formalizes canonical action identity, semantic pattern detection, approval binding, receipt integrity, runtime-portable projection, and optional attestation substrates. We study a reference implementation through a 96-seed, 384-variant benchmark covering semantic equivalence, semantic separation, wrapper bypass, false-positive control, approval binding, receipt reproducibility, attestation tamper detection, runtime portability, semantic pattern detection, policy degradation, and Azure deployment drills. We further include a system-card appendix with ablations, red-team cases, comparative boundaries, deployment evidence, and residual-risk disclosures. In this representative corpus, CAVA preserves canonical action identity across rewritten runtime forms while raw-text and first-token baselines fail under wrappers, policy-addressable pattern detection, and approval drift. The contribution is a systems formulation of action-level canonicalization and policy-addressable semantic patterns as a necessary substrate for deployer-side AI governance.
Part I
Main Research Manuscript 1
Introduction
The operational risk of an agentic AI system is rarely realized at the point where a model emits prose. Risk becomes concrete when the runtime acts: a command is executed, a tool is invoked, ∗
Correspondence: [email protected]
1
a browser submits a form, a workflow mutates state, an identity boundary changes, a payment is triggered, a deployment leaves the workspace, or data crosses an organizational boundary. Enterprise governance therefore needs more than model-side policy, chat logs, or post-hoc traces. It needs a stable object that identifies the action being decided. Today, that object is not stable. The same high-impact action may appear as a shell command in a local coding agent, an SDK method inside an agent framework, an MCP tool call, a browser automation event, a CI/CD API request, or a managed-agent session transition. Each representation may be useful for debugging, but none is guaranteed to be the governance object. If approval binds to raw text, an equivalent rewrite may bypass the approval. If audit binds to a runtime-native trace, a different runtime may make the same action incomparable. If policy binds to a first token, wrappers such as env, sudo, bash -c, aliases, SDK helpers, or tool indirection can change the surface without changing the consequence. This paper studies CAVA as a runtime-semantics substrate for this problem. CAVA transforms raw runtime events into a canonical runtime action: a versioned, hashable, and receipt-bearing action object. It is not a model-alignment method, a general observability product, or a replacement for enterprise policy. Instead, it addresses a narrower prerequisite: Before a deployer can decide whether an agent action should proceed, the deployer needs a reproducible representation of what action is being decided. CAVA is designed to compose with PCAA [16]. PCAA defines the governance loop: route the action, review when needed, and prove closure. CAVA supplies the canonical action object that can travel through that loop. In short, PCAA answers who has authority and what proof must close the action; CAVA answers what exactly the authority decision refers to. The paper makes five contributions: 1. a formalization of canonical runtime action identity for heterogeneous agent systems; 2. a CAVA protocol that binds policy outcomes, approvals, receipts, and attestations to canonical action fingerprints rather than raw text; 3. a Semantic Pattern Layer inside CAVA that maps canonical actions and externality context into policy-addressable patterns rather than customer-specific rules; 4. a threat model for semantic bypass, wrapper bypass, approval drift, evidence laundering, and parser capture; 5. a reference open-core implementation boundary separating portable schema and receipt verification from managed parser packs and enterprise evidence operations; 6. a reproducible benchmark harness with 96 representative seeds and 384 runtime variants that compares CAVA with raw-text and first-token baselines across action semantics, semantic pattern detection, policy degradation, cloud-action drills, ablations, and red-team cases.
2
Related Work
2.1
Agent evaluation and tool-use risk
AgentBench frames agent evaluation as an interactive-environment problem rather than only a static-response problem [6]. SWE-bench similarly treats real software repositories as a practical 2
testbed for evaluating autonomous coding behavior [3]. ToolEmu focuses on risk discovery for tool-augmented language-model agents through emulated tool execution [13]. CAVA is aligned with the same premise that agent behavior must be evaluated at the action layer. Its target, however, is not task success or scenario discovery. Its target is governance-grade action identity: whether a runtime event can be canonicalized, approved, replayed, and attested under heterogeneous execution surfaces.
2.2
Runtime governance, telemetry, and observability
Runtime-control specifications and managed-agent systems increasingly expose sessions, tool calls, execution state, and enterprise controls. Microsoft Agent Control Specification emphasizes portable runtime governance contracts for agents [7]. OpenTelemetry GenAI semantic conventions standardize telemetry fields for LLM and agent systems [11]. Langfuse and similar platforms expose tracing, prompt management, evaluations, and observability workflows [5]. These systems make adjacent records legible. CAVA differs in the object it treats as primary: not a span, session, prompt, or trace, but a canonical action object suitable for approval binding and receipt verification.
2.3
Proof, receipts, and attestations
Proof-carrying code established the idea that an executable artifact can travel with a machinecheckable proof object [9]. Modern software supply-chain systems such as in-toto and Sigstore provide signed provenance and attestation patterns for build and release workflows [2, 14]. Verifiable Credentials provide portable claim structures for cross-party verification [15]. Dapr Verifiable Execution contributes signed workflow history and execution attestation [1]. CAVA is complementary: it defines what runtime action those receipts or attestations should bind to.
2.4
Governance frameworks
Frontier-governance frameworks increasingly document risk identification, risk analysis, mitigations, incident response, model reporting, expert input, responsibility allocation, and change management [10]. CAVA adopts the same operational seriousness but applies it to deployer-side runtime action semantics rather than frontier model release. The distinction matters because model providers can report capability and mitigation posture, but deployers still own production systems, customer data, enterprise identity boundaries, and business authority.
3
Problem Formulation
3.1
Runtime heterogeneity
Let R denote the set of runtime families through which an agent may act. Examples include shell hooks, SDK tools, API gateways, MCP servers, browser automation, managed-agent platforms, workflow engines, and Web3 signing lanes. A raw runtime event is denoted a ∈ Ar
for runtime r ∈ R.
The deployer-facing question is not merely whether a contains a suspicious string. The question is whether a represents a business action that should be allowed, warned, approval-gated, blocked, or later audited. 3
Definition 1 (Canonical runtime action). For a raw runtime event a, a CAVA canonicalizer maps a to a canonical runtime action C(a) = (v, r, e, o, k, S, τ, u, m), where v is schema version, r is runtime family, e is executable or tool identity, o is normalized operation, k is risk category, S is the set of touched systems, τ is reversibility, u is target or subject context, and m is bounded adapter metadata. Definition 2 (Canonical fingerprint). Let canon(·) denote deterministic serialization over selected canonical fields. The CAVA fingerprint is F (a) = H(canon(C(a))), where H is a collision-resistant hash function. Policy decisions, approval receipts, and audit evidence bind to F (a) rather than to raw runtime text.
3.2
Desired properties
CAVA is designed around six properties: 1. Semantic equivalence. Equivalent expressions of the same action should converge to the same canonical identity. 2. Semantic separation. Materially different actions should not collapse into the same governance object. 3. Wrapper robustness. Shell wrappers, SDK helpers, tool aliases, and runtime indirection should not hide high-impact actions. 4. Approval binding. Approval must bind to canonical action meaning, not to a display string. 5. Receipt reproducibility. Independent verifiers should be able to recompute receipt hashes from the published object. 6. Runtime portability. Different runtime families should project comparable action semantics without pretending that all runtimes expose equal enforcement depth.
3.3
Threat model
The threat model includes both malicious and accidental failures: • Equivalent syntax bypass: the same action is rewritten so a raw-string policy no longer matches. • Wrapper bypass: the action is placed behind env, sudo, bash -c, aliases, helper scripts, SDK calls, or tool indirection. • Approval drift: an operator approves one surface description while a different semantic action executes. • Trace ambiguity: observability records exist but do not prove what was authorized. 4
• Evidence laundering: a downstream system provides a sanitized after-the-fact record. • Parser capture: a vendor-specific parser becomes the only governance authority. CAVA does not assume that every runtime can provide inline interception. It assumes only that runtime events can be captured, normalized, scored for coverage depth, and attached to explicit receipts. When a runtime is observe-only, CAVA should disclose that limitation rather than overstate enforcement.
4
Canonical Action Verification and Attestation
4.1
Protocol
CAVA can be expressed as a six-stage protocol: 1. Capture: collect the raw runtime event and execution context. 2. Normalize: map the raw event into a canonical runtime action. 3. Interpret: detect policy-addressable semantic patterns from canonical action, boundary, provenance, and data signals. 4. Fingerprint: compute a deterministic hash over canonical action semantics. 5. Bind: attach policy outcomes, approvals, denials, or escalations to the fingerprint. This is approval binding at the action-meaning layer. 6. Close: attach outcome, evidence, exceptions, and side-effect summaries. 7. Attest: optionally sign, credential, ledger-anchor, or externally verify receipt material.
4.2
Canonical action object
Table 1 gives the reference canonical object. The schema is intentionally small. It is not meant to encode every private workflow detail. It is meant to preserve the fields required for governance-grade action identity. Proposition 1 (Raw text is insufficient for approval binding). If a governance decision binds only to a raw string representation s(a), then any alternative representation s′ (a) with the same operational effect but different text may evade a policy keyed on s(a) unless the policy independently reconstructs action semantics. The proposition is not a cryptographic theorem; it is a systems observation. Raw text is a display form. CAVA makes the reconstructed action semantics the governance object.
4.3
Relationship to PCAA
PCAA treats a governed action as a certificate-bearing object with checkpoints for admissibility, action open, assumption capture, approval, and outcome closure [16]. CAVA is the lower layer that makes the object stable enough to govern. A PCAA certificate can contain route decisions and 5
Capture raw event
Normalize action
Interpret patterns
Fingerprint semantics
Bind approval
Receipt hash and verifier
Close evidence
Optional signer, VC, or ledger anchor
Figure 1: CAVA protocol: raw runtime events are converted into canonical action objects, interpreted into policy-addressable semantic patterns, and bound to fingerprints before approval, closure, and optional attestation. Table 1: Reference CAVA canonical action fields. Field
Example
Role in governance
schema_version runtime adapter
osuite.cava...v1 bash, mcp, browser codex-hook, hosted-agent git, stripe, kubectl push, payment_trigger deployment, payment github, postgres false branch, account, tenant, wallet
Versioned interoperability boundary Runtime family and coverage context Capture mechanism and trust depth
executable operation category systems_touched reversible target/subject
Tool or executable identity Normalized operation Risk taxonomy input Blast-radius input Approval and rollback input Affected object or boundary
proof bundles, but those decisions need a canonical action identity to avoid ambiguity. Conversely, a CAVA fingerprint alone does not decide authority. It becomes operationally meaningful when a PCAA or equivalent deployer-owned governance loop routes, reviews, and closes it.
4.4
Semantic Pattern Layer
Canonical action identity is necessary but not sufficient. Enterprise policy rarely says only “block this executable.” It says things like: do not create public links for sensitive material, do not weaken endpoint controls, do not let an agent exercise authority outside the user’s delegated scope, and do not let workflow sinks move data into public channels. These are not vendor-specific commands; they are reusable agentic risk patterns. CAVA therefore includes a Semantic Pattern Layer that sits after canonicalization but before policy routing. The pattern layer is not a new product and not a second governance authority. It is an internal CAVA interpretation pass. CAVA owns structure; semantic patterns own risk meaning; policy profiles own enterprise posture; PCAA owns final authority and proof. Formally, a pattern detector maps P (C(a), B(a), D(a)) → {p1 , . . . , pn }, where C(a) is the canonical action, B(a) is boundary context such as destination visibility and account provenance, and D(a) is data context such as sensitivity and minimization posture. Each pattern is a versioned evidence object with identifier, label, severity, confidence, profile axis, minimum decision, and evidence tuples. 6
Table 2: Reference CAVA semantic patterns. Pattern
Policy axis
Meaning
Hidden externality
External sharing
Public persistent egress
Public links
A normal-looking task creates an external side effect such as an upload, share, vendor handoff, or public URL. Data moves to a public or link-accessible destination that may persist outside the workspace. The action disables or weakens endpoint, firewall, audit, EDR, runtime, or governance controls. Secret, token, credential, or key material may leave a trusted boundary. The agent exercises identity, OAuth, service-account, or delegated authority beyond the visible task boundary. A graph or workflow sends data to a public, external, or weakly governed sink. The action changes prompts, rules, managed settings, policy files, or hook behavior that shape future actions.
Security-control weakening Production changes Credential exposure
External sharing
Delegated authority mismatch
Identity admin
Workflow sink risk
External sharing
Prompt or rule tampering Production changes
This distinction prevents the system from becoming a pile of customer-specific exceptions. For example, a public file handoff should not be encoded as “block one named file host.” It should be encoded as public persistent egress with evidence: destination type, visibility, persistence, account provenance, and payload sensitivity. A policy profile can then route the same pattern differently for a startup sandbox, an incident-response workspace, or a regulated enterprise deployment. The pattern layer also aligns CAVA with emerging agentic-risk taxonomies without reducing CAVA to a checklist. OWASP’s agentic AI work emphasizes risks such as tool misuse, excessive agency, insecure execution, and memory or context abuse, while NIST’s generative AI profile frames risk management as a context-sensitive governance activity rather than a single universal rule set [8, 12]. CAVA’s role is narrower: convert runtime behavior into evidence-bearing patterns that policy profiles can address.
4.5
Bounded Action Firewall and runtime exposure graph
Recent implementation work separates two higher-level primitives from CAVA while keeping them dependent on CAVA’s canonical action object. The first is a Bounded Action Firewall: a runtime gate that returns allow, ask, block, or observe only after binding the decision to a canonical fingerprint, policy version, actor identity, runtime session, destination scope, proof receipt, and time window. In this model, a human approval is not a broad permission attached to a chat session. It is an action gate lease for a specific semantic action. If the target, policy, actor, runtime session, or proof digest changes, the lease must expire or require re-approval. The second is an Agent Runtime Exposure Graph: a graph projection that connects agents, runtime adapters, sessions, canonical actions, policy profiles, final-authority decisions, destinations, data boundaries, proof receipts, and incident events. CAVA supplies the action nodes and fingerprints; PCAA supplies the authority and closure edges; the bounded firewall supplies gate outcomes; the exposure graph supplies reachability, blast-radius, incident reconstruction, and framework-mapping queries. 7
Table 3: How CAVA composes with BAF and AREG inside OSuite. Layer
Primary object
Responsibility
CAVA
Canonical action fingerprint
Policy profile
Enterprise posture
Decision Score
Risk feature vector
PCAA
Final authority and proof loop Action gate lease
Reconstruct action meaning from heterogeneous runtime events. Decide how semantic patterns should route in this workspace. Rank impact, exposure, control weakness, and evidence confidence. Decide who may approve and what proof closes the action. Enforce allow, ask, block, or observe with replayresistant approval binding. Map blast radius, boundary drift, framework coverage, and incident evidence.
Bounded Action Firewall AREG
Runtime exposure graph
These primitives are deliberately not defined as new product lines. They are productized consequences of the CAVA/PCAA stack. CAVA remains the semantic action layer. The bounded firewall is the enforcement layer that makes approval replay-resistant. The exposure graph is the security-operations layer that makes blast radius and evidence legible to CISOs. This separation avoids overloading CAVA with every downstream product concern while preserving the scientific claim that canonical action identity is the object on which runtime governance depends.
4.6
Attestation substrates
CAVA receipts can remain local hash receipts, or they can be extended with stronger substrates: • local deterministic SHA-256 receipt hashes; • workspace, runtime, or operator signatures; • verifiable credentials for external procurement and auditor review; • in-toto or Sigstore-style supply-chain attestations; • permissioned or public ledger anchoring of receipt digests; • smart-account policies for wallet, relayer, or settlement lanes. The design intentionally treats blockchain and Web3 components as optional attestation substrates, not as the definition of CAVA. Public ledgers may provide timestamping, non-repudiation, or settlement finality, but confidential enterprise action contents should not be forced on-chain.
5
Reference Implementation
The current reference implementation has two layers. The OSuite implementation contains production-facing CAVA parsing, PCAA policy integration, approval workflow binding, evidence graph projection, and enterprise assurance surfaces. The open CAVA package exposes a smaller skeleton: schema constants, deterministic hashing, receipt creation and verification, profile normalization, and runtime-adapter contracts. 8
Table 4: Open-core boundary in the reference implementation. Layer
Contents
Open CAVA skeleton
Schema, deterministic fingerprints, receipt build/verify helpers, adapter contracts, local examples Production parser packs, PCAA policy routing, approval binding workflows, evidence graph, replay, exports, enterprise signers, KMS/HSM, optional VC or ledger anchoring
OSuite managed layer
This split is deliberate. The open package should be sufficient for researchers and developers to reproduce the core semantics and test adapters. It should not replicate OSuite’s managed parser packs, enterprise policy routing, buyer-ready evidence graph, signer orchestration, private KMS/HSM integration, or managed connectors. This open-core boundary reduces lock-in while preserving a commercial reason to buy the managed product.
6
Evaluation
6.1
Benchmark design
We evaluate CAVA with a disclosure-safe benchmark harness included with the manuscript artifacts. The public harness contains 96 representative seed scenarios and expands them into 384 runtime variants across four runtime families: shell hooks, MCP-style tools, browser automation, and managed-agent traces. Production parser packs, enterprise policy thresholds, customer connector rules, and the managed OSuite evidence graph are withheld. The benchmark tests nine properties: 1. semantic equivalence across rewritten action forms; 2. semantic separation across materially different operations; 3. wrapper-bypass catch rate; 4. false-positive control for benign text containing high-impact strings; 5. approval binding correctness; 6. receipt reproducibility; 7. attestation tamper detection; 8. runtime portability convergence; 9. semantic pattern detection and policy-profile routing. The baselines are intentionally simple but operationally common: • Raw-text policy: binds to the literal runtime string. • First-token rules: classifies actions using the first executable and neighboring token. • CAVA runtime: normalizes wrappers, aliases, categories, and receipt material before decision binding. 9
Table 5: Aggregate benchmark results on the 96-seed, 384-variant CAVA corpus. Metric
Raw text First-token CAVA
Semantic equivalence recall Semantic separation precision Wrapper-bypass catch rate False-positive control Approval binding correctness Receipt reproducibility Attestation tamper detection Runtime portability convergence Semantic pattern detection
0.000 1.000 0.000 0.500 0.000 0.000 0.000 0.000 0.000
0.000 0.750 0.000 0.500 0.000 0.000 0.000 0.000 0.333
Raw text
1.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000
First-token
CAVA
CAVA vs. Raw-Text and First-Token Baselines 1
Score
0.8
0.6
0.4
0.2
0 Equivalence
Wrapper
False Positive
Patterns
Approval
Attestation
Figure 2: Representative benchmark slices. CAVA’s advantage comes from binding decisions to canonical action semantics rather than display text or first-token heuristics.
6.2
Results
Table 5 reports aggregate results from the current harness. The numbers should be read as regression evidence for the representative corpus, not as a universal claim over all future enterprise runtimes. The public benchmark deliberately separates two layers: scored executable checks for canonicalization and receipt integrity, and structured system-card material for policy degradation, cloud-action drills, ablations, and red-team case analysis.
7
Expanded Evaluation Matrix
The benchmark is intentionally not a single score. A single aggregate number would hide the failure modes that matter to buyers and reviewers: whether wrappers are handled, whether benign text is over-blocked, whether approvals bind to the executed action, whether receipts are reproducible, 10
whether runtime families converge, and whether governance itself can be weakened. Table 6 reports the evaluation matrix used by the artifact package. Table 6: Expanded CAVA evaluation matrix. The support column includes scored checks and structured system-card cases in the public artifact. Suite
What is challenged
Public support
Semantic equivalence
Primary metric
Same operational action rewrit- 12 scored vari- Equivalence reten through flags, environment ants call variables, command wrappers, or helper forms. Semantic separaMaterially different actions that 8 pairwise Separation precition share words, tools, or nearby checks sion context. High-impact action hidden be- 14 checks includ- Bypass catch Wrapper bypass hind env, sudo, command, bash ing ablations rate -c, or nested shells. Benign contamina- Read-only commands contain- 7 checks includ- False-positive tion ing high-impact strings such as ing ablations control git push, kubectl delete, or payment events. Approval drift Receipt replay or approval reuse 8 checks includ- Approval-binding after canonical fields change. ing ablations correctness Receipt tampering Modified policy outcomes, al8 checks Hash reprotered receipt fields, or orderducibility and dependent serialization. tamper detection Runtime portabil- Shell, MCP, browser, and 16 runtime pro- Portability conity managed-agent records describ- jections vergence ing comparable operational actions. Semantic pattern Canonical actions plus bound- 6 scored cases Pattern detecdetection ary context mapped to reusable tion and profile patterns such as public egress, routing security-control weakening, delegated authority mismatch, and workflow sink risk. Policy degradation Signature disabling, permissive 8 structured Degradation covpolicy changes, trust-boundary cases erage broadening, and evidence retention weakening. Azure deployment Azure CLI actions across what- 6 structured Cloud-action prodrill if, deployment, role assignment, cases jection coverage Key Vault, SQL firewall, and ACR read paths.
11
Suite
What is challenged
Public support
Red-team casebook Attacker-style narratives linking 24 cases bypass method, baseline failure, expected CAVA behavior, and residual risk.
Primary metric Qualitative coverage
This matrix is the paper’s answer to a common objection against governance components: that they look good only when evaluated on the exact examples used to explain them. The CAVA harness separates seed scenario, runtime variant, suite, and evidence type. A seed may be scored directly, used as an ablation probe, or carried into the red-team casebook. The public corpus is still small compared with enterprise reality, but it is structured so that new runtime adapters and customer-approved traces can be added without changing the metric vocabulary.
8
Ablation Study
Table 7 reports the ablation study used in the system-card artifact. These ablations are not meant to claim that the exact implementation is optimal. They identify the components that are necessary for the CAVA claim to be true. If any of these layers is removed, CAVA collapses into either ordinary logging, brittle guardrails, or a product-specific approval workflow. Table 7: CAVA ablation study. Retained score is the expected retained capability for the affected suite under the public harness. Ablation
Affected suites
Expected failure
Remove wrapper parsing
Retained score
Wrapper bypass, semantic env, sudo, bash -c, and 0.00 equivalence nested shells remain surface text; high-impact action can hide behind the wrapper. Remove profile Payment, Web3, customer Domain-specific operations 0.50 aliases private tools such as Stripe triggers or wallet sends collapse to unknown or low-confidence actions. Remove canonical Approval drift, runtime Approval binds to display text 0.00 fingerprint portability or runtime-native IDs rather than action meaning. Remove receipt veri- Receipt tampering, exter- Changed decisions and receipt 0.00 fier nal assurance payloads become log entries instead of verifier failures. Remove PCAA bind- Policy degradation, apCanonical fingerprints exist, 0.25 ing proval drift, outcome clo- but no deployer-owned routesure review-prove loop decides authority or closure.
12
The harshest ablations are canonical fingerprint removal and receipt-verifier removal. Without a canonical fingerprint, there is no stable object for approval. Without verifier logic, the receipt becomes decorative evidence. This is why CAVA should not be marketed as merely an observability schema. Observability can tell a team that something happened. CAVA must help a team prove what was authorized, what actually happened, and whether the evidence survived replay.
9
Interpretation
The benchmark demonstrates three points. First, raw-text governance has no stable notion of semantic equivalence: git push origin main, git -c push.default=simple push origin main, env ... git push origin main, and bash -c "git push origin main" are different strings but the same governed action. Second, first-token rules do not survive wrappers and are prone to false positives when high-impact strings appear in search, documentation, or echo commands. Third, canonical receipts allow approval and attestation checks that raw strings do not provide. The most important result is not that CAVA scores 1.0 on a controlled corpus. The important result is that the benchmark exposes the failure modes that a serious market-facing component must survive. Future versions should expand the corpus with third-party runtime traces, customerapproved anonymized examples, and adversarial parser challenges.
10
Discussion
10.1
Why CAVA should not be only a product feature
CAVA is more credible as a portable component than as a hidden OSuite feature. A public schema and verifier allow the ecosystem to inspect the core claim, reproduce hashes, and write adapters. OSuite can still monetize the hard parts: maintained parser coverage, enterprise approvals, evidence graph operations, assurance exports, support, signer orchestration, and managed integrations. This is the right open-core boundary for both adoption and revenue.
10.2
Where Web3 belongs
Web3 should be used carefully. If CAVA is defined as blockchain, it becomes narrower and less enterprise-friendly. If CAVA treats ledgers, verifiable credentials, smart accounts, and decentralized identity as optional attestation lanes, it gains stronger integrity options without forcing every deployer into a settlement substrate. The principle is simple: canonical action semantics first; attestation substrate second.
10.3
Market testability
For CAVA to survive market scrutiny, the benchmark must be uncomfortable. It should include not only clean examples but wrappers, nested shells, alias abuse, SDK indirection, browser-side mutations, MCP tool calls, hosted traces, benign commands containing dangerous strings, and tampered receipts. This paper introduces that test direction, but the component should be judged by ongoing benchmark expansion rather than by a static whitepaper.
13
11
Threats to Validity
Representative corpus. The current benchmark is a representative public corpus, not a complete distribution of enterprise actions. It is useful for regression and public explanation, but future evidence should include broader traces. Parser coverage. Canonicalization is only as strong as adapter coverage. Private enterprise systems may need custom parser packs, and parser failures can produce either missed escalations or unnecessary review. Disclosure boundary. Production parser packs and customer connector rules are withheld. This protects commercial and security-sensitive implementation details, but it limits full third-party reproduction of OSuite’s managed behavior. Attestation scope. Receipt hashes and signatures prove integrity and binding, not business wisdom. A correctly attested action can still be a bad decision. Runtime depth. Some runtimes allow inline blocking. Others only provide observer-mode traces. CAVA must disclose that difference rather than claim uniform enforcement.
12
Conclusion
This paper argues that agent governance needs a stable action-semantics layer. Without it, approvals bind to strings, traces bind to runtime-specific records, and evidence becomes difficult to replay across changing execution surfaces. CAVA provides a canonical runtime action object, deterministic fingerprint, receipt path, and optional attestation architecture that can sit below PCAA or a similar deployer-owned governance loop. The current reference implementation and benchmark are early but concrete. They show how CAVA can collapse equivalent runtime forms, separate materially different actions, resist wrappers, bind approvals to fingerprints, reproduce receipts, detect tampering, and project comparable semantics across runtime families. The next research step is to expand the public corpus, invite adversarial parser challenges, and evaluate CAVA against real third-party agent traces. The product step is equally clear: keep the schema open, keep the managed evidence layer worth paying for, and make runtime action governance measurable rather than rhetorical.
Part II
CAVA System Card and Technical Appendix A
System Scope and Release Posture
This appendix uses a system-card style to document CAVA as an evaluable governance component rather than as a finished safety guarantee. The system under study is the CAVA runtime-semantics layer and the surrounding OSuite reference implementation. The public open-core package exposes schema, deterministic hashing, receipts, profile normalization, and runtime adapter contracts. The managed OSuite layer adds production parser packs, PCAA policy routing, approval workflows, evidence graph construction, replay, exports, enterprise signers, private key-management integrations, verifiable credential issuance, optional ledger anchoring, and managed connectors. 14
The release posture is intentionally split. The open package is suitable for experimentation, adapter prototypes, reproducible benchmark execution, and third-party inspection of core hash and receipt semantics. It is not intended to replace a managed runtime governance system. The managed layer is intended for production deployments where parser maintenance, evidence retention, operator workflow, tenant security, and buyer-facing assurance matter.
B
Observed Runtime Governance Challenges
The reference implementation and benchmark are organized around observed failure modes in agent runtimes. These are not model-output categories such as toxicity or hallucination. They are operational governance failures that occur when an action crosses a runtime boundary. Challenge
Failure pattern
CAVA evaluation slice
Equivalent syntax
The same operation is rewritten Semantic equivalence recall through flags, environment variables, shell wrappers, or helper commands. Semantic separation A benign action contains a highSemantic separation preimpact string or shares an execision and false-positive cutable with a high-impact action. control Wrapper bypass The high-impact operation hides be- Wrapper-bypass catch rate hind env, sudo, command, bash -c, SDK indirection, or tool aliasing. Approval drift The operator approves display text Approval binding correctwhile execution binds to a different ness action. Receipt reproducibility Receipt drift A receipt is recomputed under a different field order, profile, or decision payload. Attestation tampering A receipt or policy outcome is mod- Attestation tamper detecified after approval. tion Runtime fragmenta- Shell hooks, MCP tools, browser ac- Runtime portability contion tions, and managed traces describe vergence the same action differently.
C
Risk Taxonomy
CAVA classifies runtime action risk by operational consequence rather than by model intent. The taxonomy is intended to remain small enough to be portable and large enough to support enterprise routing. Risk class
Examples
Governance implication
Observation
Search, list, inspect, read-only query
Usually allow or log, unless sensitive data boundary is crossed.
15
Build and prepa- Build, dry run, plan, simulation Often allow or simulate-first; useful ration for reducing unnecessary review. Deployment Push, release, publish, migrate Requires canonical identity, approval binding, and outcome closure. Infrastructure Terraform, Kubernetes, Helm, Requires high-integrity receipts and change Pulumi, firewall change rollback evidence. Database muta- Insert, update, delete, truncate, Requires target clarity, reversibility tion migration disclosure, and approval binding. Identity and au- Key rotation, permission grant, Requires authority lineage and dualthority user creation control in high-impact cases. Payment and Charge, refund, invoice, transfer Requires receipt integrity and obligation financial-system boundary disclosure. Export, upload, email, public Requires destination visibility and Data boundary share account provenance. Web3 settlement Sign, send, bridge, swap, spon- Requires cryptographic intent bindsor, relay ing and optional ledger anchoring.
D
Capability Taxonomy
The system-card posture for CAVA is capability-based rather than vendor-based. A deployment should not claim that “CAVA is enabled” as a binary statement. It should disclose what classes of runtime action can be captured, normalized, verified, and enforced. Table 10 defines the capability taxonomy used by the current paper and artifact package. Table 10: CAVA capability taxonomy for deployment disclosure. Capability
Minimum evidence
Failure if absent
Capture
Raw event, runtime family, adapter ID, timestamp, actor or session handle. Canonical action fields and schema version.
The action may occur out- Observe side the evidence boundary.
Normalization
Typical release posture
Similar actions remain in- Observe or warn comparable across runtime surfaces. Semantic separa- Evidence that benign False positives erode opera- Warn tion lookalikes do not collapse tor trust and produce alert into high-impact actions. fatigue. Wrapper reEvidence that common High-impact actions hide Approval-gate silience wrappers are stripped or behind shell or SDK indidecomposed. rection.
16
Capability
Minimum evidence
Failure if absent
Typical release posture
Approval binding Receipt connecting deci- The operator may approve Approval-gate sion, policy, and canonical one thing while another fingerprint. executes. Receipt reproDeterministic serialization Evidence cannot be inde- Approval-gate ducibility and verifier output. pendently replayed. Approval-gate Outcome closure Execution result, excep- Governance ends at aption, or partial-coverage proval and loses operamarker. tional truth. Coverage disclo- Enforcement depth, Observe-only traces are Warn or sure adapter confidence, and confused with blocking approval-gate unknown-field posture. controls. Policy degrada- Canonical treatment of Governance controls can Dual control tion detection policy, signature, retenbe weakened under the tion, and trust changes. language of configuration. External attesta- Signature, verifiable cre- Buyer-facing assurance External assurtion dential, supply-chain depends on local logs only. ance attestation, or optional ledger anchor. This taxonomy is important for sales as much as for science. Buyers do not merely ask whether an AI governance product has policies. They ask whether the product can explain what it actually sees, what it can block, what it can only record, and what evidence survives after a disputed event. CAVA therefore treats capability claims as auditable objects. A SaaS deployment may expose managed coverage and standard policies. A self-hosted enterprise deployment may add private parser packs, internal connectors, custom signer policies, and higher-friction approval routes. The open-core package can validate receipts and fingerprints, but it should not imply that a user has reproduced OSuite’s managed parser, policy, evidence, or assurance layer.
E
Safeguard Design
CAVA safeguards are layered so that deployments can increase assurance without redefining the base object. 1. Normalization safeguards: adapters strip common wrappers, resolve aliases, and project runtime-specific fields into stable canonical fields. 2. Binding safeguards: policy outcomes and approvals attach to canonical fingerprints rather than raw strings. 3. Receipt safeguards: receipt hashes are deterministic and can be recomputed by independent verifiers. 4. Coverage safeguards: runtime family, adapter mode, and enforcement depth remain explicit so observer-only coverage is not presented as inline blocking. 17
5. Attestation safeguards: selected receipt digests can be signed, credentialed, or ledger-anchored without publishing confidential action contents. 6. Commercial-boundary safeguards: the open package exposes verification primitives, while managed OSuite holds production parser maintenance, evidence operations, and enterprise connector depth.
F
Red-Team and Adversarial Evaluation Plan
The benchmark should evolve from representative examples into an adversarial corpus. The red-team plan is divided into six tracks: 1. Syntax rewriting: equivalent operations are rewritten through flags, environment variables, shells, aliases, and scripts. 2. Benign contamination: low-risk commands intentionally contain dangerous substrings such as git push, kubectl delete, or DROP TABLE. 3. Runtime projection: the same action is represented as shell, MCP, browser, managed-agent, and API-gateway events. 4. Approval mismatch: approval receipts are replayed against altered fingerprints or changed policy payloads. 5. Evidence tampering: receipt fields are changed after closure to test verifier detection. 6. Parser miss discovery: unknown tools, nested commands, customer-specific scripts, and private runtime events are used to identify coverage gaps. This plan is intentionally uncomfortable. A useful CAVA benchmark should make bypass attempts cheap to write, deterministic to reproduce, and hard for the canonicalizer to pass accidentally.
G
Red-Team Casebook
Table 11 is a disclosure-safe red-team casebook extracted from the benchmark harness. The cases are intentionally concrete because vague safety prose is cheap; runtime governance becomes meaningful only when the attempted bypass can be reproduced. Each row records an attack pattern, a representative event, the baseline failure, the expected CAVA behavior, and residual risk. The casebook is not exhaustive. It is a forcing function for reviewers, customers, and future contributors to add uncomfortable examples rather than only success stories. Table 11: Disclosure-safe CAVA red-team casebook. ID
Attack
Representative event
Baseline failure
CAVA expected behavior
RT-001
Nested shell deploy
bash -lc npm-deploy
First-token rules see bash, not deploy.
Unwrap nested shell and classify deployment.
18
ID
Attack
Representative event
Baseline failure
CAVA expected behavior
RT-002
Benign documentation search
rg "kubectl delete namespace prod"
Substring policy escalates read-only search.
RT-003
Approval replay git push origin against changed release-candidate branch SDK payment indi- mcp.stripe.refund(...) rection Browser release browser button publish-release Managed trace field agent github.push drift trace receipt.decision = Receipt decision tamper "allow" Policy loosening osuite policy update after import –mode allow-all Signature mode osuite signature off disable
Classify observation and suppress false positive. Reject receipt if fingerprint differs.
RT-004 RT-005 RT-006 RT-007 RT-008 RT-009
RT-010
Azure role escalation Azure destructive Key Vault operation Database mutation through MCP query Wallet settlement action
az role create Contributor az keyvault purge –name prod-vault mcp.postgres delete
Read-only wallet call Open firewall range
cast call 0xabc balanceOf az sql firewall open-all
RT-016
Deployment docs false positive
curl docs/git-push
RT-017
Approval TTL expansion Public share through browser Receipt order mutation Unknown private script Environment policy bypass
osuite approvals configure –ttl 30d browser share public
Managed data export Kubernetes delete echoed Attestation anchor unavailable
agent crm.export trace
RT-011 RT-012 RT-013
RT-014 RT-015
RT-018 RT-019 RT-020 RT-021
RT-022 RT-023 RT-024
cast send 0xabc 1ether
Same receipt fields serialized differently. ./release-prod.sh env policy-off deploy
echo "kubectl delete namespace prod" Ledger anchor timeout after local receipt.
19
Display resembles approved push. No shell token exists to match. Trace only says click.
Project MCP call into payment category. Bind UI action to deployment semantics. Runtime-native trace Project managed trace misses shell policy. into deployment class. Log-only systems may Detect receipt-hash not recompute integrity. mismatch. Configuration looks ad- Classify as policy ministrative. degradation. Verifier disappears with- Mark trust degradaout side-effect label. tion and refuse proof claims. Generic CLI command Require identityhides authority change. authority review. Irreversibility may be Mark destructive and unknown. non-reversible. Generic query hides Parse SQL operation mutation. and classify mutation. Enterprise-only policy Classify Web3 transacmisses settlement finaltion and bind signing ity. intent. Token match overSeparate observation escalates all wallet use. from settlement. Infrastructure write lacks Classify infrastructure blast-radius semantics. and boundary expansion. Substring policy sees git Classify network read push. or documentation lookup. Policy drift is not a diRoute as governance rect side effect. degradation. UI trace omits dataClassify data-boundary boundary semantics. expansion. Non-deterministic reCanonical serialization ceipts fail replay. reproduces the hash. Script name may be Downgrade coverage or trusted blindly. require parser pack. Deployment and override Classify deployment blend together. and policy degradation. Export looks like a work- Classify data-boundary flow step. action. Dangerous substring Classify echo as benign creates false positive. text emission. External anchor failure Preserve local receipt is confused with no evi- and mark external dence. attestation failed.
The strongest cases are not the ones where CAVA blocks an obviously dangerous command. The stronger test is whether it refuses to be fooled by nearby language: dangerous strings in benign searches, harmless wallet reads next to irreversible sends, clicks that need business meaning, and cloud commands whose risk depends on the exact operation. This is also where CAVA’s commercial boundary becomes defensible. The open artifact can show the schema and verifier. The managed product earns revenue by maintaining parser coverage, connector enrichment, evidence workflows, and customer-specific governance packs.
H
Failure Modes and Incident Classes
CAVA should treat failures as first-class operational incidents: Incident class
Description
Parser miss
A high-impact action is classified Add regression seed, docuas low risk or unknown. ment adapter gap, update parser pack. A benign action is escalated be- Add false-positive seed, refine cause of string contamination or semantic separation. weak context. Materially different actions con- Treat as critical schema or verge to the same governance canonicalization defect. identity. Approval binds to a fingerprint Block closure, require operadifferent from the executed actor review, preserve mismatch tion. receipt. Execution proceeds without reMark partial coverage and quired receipt material. prevent buyer-facing proof claims. A runtime stops emitting required Downgrade coverage posfields or changes event shape. ture until adapter verification passes. Signature, credential, or ledger Preserve local receipt and anchor cannot verify. mark external attestation failed.
Parser overreach
Fingerprint collision
Approval mismatch
Receipt gap
Adapter degradation
Attestation failure
I
Required response
Comparative System Boundary
CAVA is intentionally narrower than model safety frameworks and broader than runtime traces. Table 13 summarizes the distinction.
20
Table 13: CAVA compared with adjacent system families. System family
Primary object
Model system cards
Model family, safety evaluation, deployment safe- CAVA governs guards deployer-side runtime actions, not model release. Task success, tool-use ability, scenario risk CAVA evaluates action identity, approval binding, and receipt integrity. Spans, traces, attributes, observability fields CAVA creates enforcement-grade canonical action fingerprints. Signed execution history and provenance CAVA defines the action object being attested. Prompt, content, policy, validator output CAVA binds runtime side effects to canonical governance objects. Evidence graph, approval workflow, buyer assurance OSuite operationalizes CAVA but does not make the open core proprietary.
Agent benchmarks Telemetry standards
Workflow attestation Guardrails and filters OSuite managed layer
J
CAVA distinction
Comparative Evaluation
Adjacent systems are moving in the same broad direction: runtime controls, telemetry conventions, workflow attestations, and LLM observability are becoming part of the AI infrastructure stack. This is good news for CAVA rather than a reason for CAVA to disappear. The market signal is that action-level governance is becoming legible. The remaining question is which object should be treated as the unit of authority. Table 14 compares CAVA against representative adjacent families. The comparison is intentionally narrow. It does not claim that CAVA replaces control-plane standards, workflow engines, telemetry, or observability. It claims that those systems still need a stable action object when a deployer asks whether an agent was allowed to perform a concrete business side effect. Recent interoperability analysis reaches a compatible conclusion from the protocol side. Kang and Diponegoro evaluate MCP, A2A, ACP, ANP, and ERC-8004 against governance dimensions including membership, deliberation, voting, dissent preservation, human escalation, and audit or replay, and find that connection protocols do not by themselves encode the full governance loop [4]. CAVA therefore treats protocol events as runtime projections rather than authority. An MCP tool call or A2A handoff can become evidence, but it still must be canonicalized, scored, routed, approved, bounded, and replayed before OSuite can claim action governance.
21
Table 14: Comparative evaluation against adjacent public system families. System family
Primary object
Strength
Microsoft Agent Control Specification [7]
Runtime governance Portable governance lancontract guage across agent runtimes and policy engines.
CAVA claim
CAVA can supply the canonical action fingerprint and receipt semantics that such contracts need at decision time. Dapr Verifiable Signed workflow his- Strong provenance and CAVA defines the Execution [1] tory tamper evidence for work- action identity beflow execution. fore the workflow history is signed or attested. OpenTelemetry Spans, events, met- Shared observability lan- CAVA turns action GenAI [11] rics, semantic atguage for GenAI systems. semantics into an tributes approval and receipt object, not merely a trace attribute. Langfuse [5] LLM application Developer-friendly observ- CAVA focuses on traces, prompts, eval- ability and debugging for authority binding, uations LLM applications. replayable proof, and deployer-side closure. Supply-chain attes- Build provenance, Mature patterns for build CAVA extends the tation signing, release meta- and artifact integrity. proof target from data software artifacts to agent runtime actions. Prompt guardrails Prompt, output, val- Useful first line for content CAVA governs side and content filters idator result and instruction control. effects after the model has chosen or attempted an action. OSuite managed Evidence graph, ap- Productized operations, OSuite operationallayer proval workflow, ex- connectors, signers, buyer izes CAVA without ports assurance. making the open verifier meaningless. The competitive bar is therefore not “can CAVA produce another trace.” The bar is whether CAVA can remain useful when all serious platforms already have traces. Its answer is to sit one level closer to consequence: normalize the runtime action, bind authority to its fingerprint, preserve 22
receipt integrity, disclose coverage depth, and let the deployer rather than the frontier provider own the final governance loop.
K
Azure and OSuite Deployment Evidence
The current artifact records a low-risk Azure verification path rather than live mutating cloud execution. Local Azure CLI authentication was verified with az account show –output json, and the benchmark includes Azure deployment-drill cases for az deployment group what-if, az containerapp update, az role assignment create, az keyvault purge, az sql server firewall-rule create, and az acr repository show-tags. These cases are semantic drill cases; the artifact does not execute mutating cloud commands by default. This conservative choice is deliberate. A governance benchmark should not spend money or mutate production resources merely to look dramatic. The relevant scientific question in this paper is whether CAVA can classify, fingerprint, route, and bind cloud-action semantics. Live cloud execution is valuable for later external validation, but it belongs in a disposable subscription with a cleanup plan, synthetic identities, and explicitly bounded blast radius. The OSuite deployment evidence is also staged. The local Codex hook is configured in observe mode for normal development ergonomics, while the benchmark still exercises approval binding, receipt generation, and runtime-action projection. In production, OSuite can increase posture from observe to warn, approval-gate, dual control, quarantine, and external assurance. The paper treats these as separate claims. Observe-mode coverage can produce evidence; it should not be described as equivalent to inline blocking.
L
Implementation Lessons From OSuite Rollout
The OSuite rollout changed CAVA from a parser idea into a runtime governance primitive. Four implementation lessons are now part of the claim. These lessons also explain why Decision Score v2.1 and Policy-to-runtime are not presented as standalone research primitives in this paper. They are important, but their current scientific role is to make CAVA and PCAA operationally legible: policy becomes a runtime route, and score becomes an explanation of why a canonical action was treated as routine, reviewable, blocked, or observe-only. A separate paper would be justified only after the score is calibrated against external reviewer labels, longitudinal incident outcomes, or cross-organization policy corpora.
23
Table 15: CAVA rollout lessons and product corrections. Lesson
Failure observed
Correction
Raw command text was not enough
Similar terminal actions looked Canonical action fingerprints include operidentical even when one stayed ation, target, effect, externality, and policylocal and another crossed a produc- relevant context. tion or public boundary Policy-to-runtime needed Policy profiles could read like gov- Each action envelope carries policy version, to be explicit ernance documents rather than route, review posture, and enforcementruntime controls depth disclosure. Scores required decomposi- A single score made shell actions Decision Score v2.1 decomposes action risk tion look suspiciously uniform to opera- into impact, exposure, control weakness, tors and evidence confidence. Approval needed bounded Human review could be confused CAVA fingerprints feed Action Gate Leases reuse with durable permission so approval is bound to the exact action context. Setup friction delayed Customers had to understand The one-command installer makes first evievidence hooks before seeing any governed dence visible quickly, while advanced configaction uration remains available after connection.
M
External Validation Roadmap
CAVA will become more credible as soon as the corpus stops being authored only by its creator. The next validation roadmap has five tracks: 1. Third-party runtime traces: collect customer-approved anonymized traces from coding agents, browser agents, MCP tools, and managed-agent platforms. 2. Cloud drill lab: run Azure, GitHub, Stripe sandbox, database, and Kubernetes test cases in disposable environments with automated cleanup. 3. Independent parser challenge: publish a red-team input format where external reviewers submit bypass attempts and false-positive traps. 4. Buyer-facing proof review: give security leaders a receipt bundle and ask whether it answers procurement and audit questions. 5. Open-core compatibility: keep the public verifier stable enough that third parties can validate receipts without receiving the managed OSuite parser layer. The roadmap is intentionally product-facing. Academic benchmarks are necessary, but enterprise adoption also depends on whether CISOs, platform teams, procurement teams, and auditors can understand the evidence. A component that only impresses researchers but cannot answer a buyer’s incident question is incomplete. A product that only impresses buyers but cannot survive adversarial review is also incomplete.
N
Known Gaps and Residual Risk
CAVA is not finished, and the paper should not pretend otherwise. 24
Table 16: Known gaps and residual risks for current CAVA. Gap
Why it matters
Current mitigation
Opaque private scripts
A single script name can hide many side effects.
Downgrade coverage and require parser pack, sandbox run, or human review. Multi-action comOne raw event can contain a Treat decomposition as a remands deploy, policy bypass, and data quired parser capability for movement together. high-risk lanes. Vendor schema drift Managed-agent or MCP event Version adapters and include shapes may change. adapter degradation incidents. Business-context de- Severity depends on tenant, Enrich with OSuite connectors pendence branch, role, account, data label, and disclose when context is or environment. missing. External attestation Ledger, signer, or credential ser- Preserve local receipts and availability vices can fail. mark external attestation status separately. Benchmark satura- A fixed public corpus can be over- Expand with third-party traces tion fit. and adversarial submissions. Commercial disclo- Withholding parser packs limits Keep schema, hashes, receipts, sure boundary full reproduction. and representative cases public. Operator misuse A valid receipt can approve a bad Bind to PCAA routes, dual business decision. control, and outcome closure rather than claiming moral correctness. The most important residual risk is not that CAVA sometimes escalates too much or too little. Those are engineering defects that can be found by better tests. The deeper risk is overclaiming: selling observer-mode logs as enforcement, selling receipt hashes as judgment, or selling a public skeleton as if it reproduces the managed product. The paper’s boundary is therefore part of the technical contribution. Honest limits make the system stronger.
O
Operational Scenario Cards
The following scenario cards translate the benchmark into enterprise language. They are written as operational cards rather than as product marketing because security reviewers usually do not buy claims; they buy inspectable failure handling.
25
Table 17: Operational scenario cards for CAVA deployment review. Scenario
Runtime action
Evidence CAVA must pro- Reviewer quesduce tion
Production release
Agent pushes code, upCanonical deployment Can the buyer dates a container image, fingerprint, approval reprove which reor clicks a release button. ceipt, actor/session, target lease action was branch or service, outcome approved? closure. Cloud authority Agent grants a role, Identity-authority category, Could the agent change changes a managed iden- touched tenant or scope, silently make tity, rotates a secret, or non-reversibility marker, itself more powermodifies a trust boundary. dual-control route. ful? Database muta- Agent runs SQL, migra- Database mutation cateIs a read-only tion tion tooling, or an ORM gory, target database, oper- query clearly deploy step. ation class, approval bind- separated from ing, rollback or irreversible mutation? marker. Browser admin- Agent operates an admin DOM-to-business-action Does a click istration console through UI aumapping, page identity, mean anything tomation. control label, canonical auditable? action projection, coverage disclosure. MCP tool execu- Agent calls a tool server Tool namespace, method, Does governance tion rather than a shell com- normalized operation, sys- survive tool indimand. tem touched, adapter confi- rection? dence. Payment or obli- Agent triggers a charge, Payment category, amount Can finance disgation refund, invoice, subscrip- or obligation class when pute or replay tion update, or external available, approval receipt, the decision? obligation. finance-system boundary. Data boundary Agent exports, uploads, Destination, data bound- Can the cusexpansion shares, emails, or pubary category, sensitivity tomer idenlishes data. context when available, tify where data outcome closure. moved? Web3 settleAgent signs, sends, spon- Signing intent, chain or Is read-only inment sors, bridges, swaps, or settlement lane, target, spection separelays a transaction. value class, optional ledger rated from irreor credential anchor. versible settlement? These cards also clarify where CAVA should be strict. The strictness is not about blocking everything. It is about refusing to downgrade semantic uncertainty into a false allow. If the runtime cannot tell whether a browser click changes production, CAVA should mark the action as lower-confidence and route it accordingly. If a private script is opaque, the system should not 26
pretend that the script is safe because the name looks familiar. If an external signer or ledger anchor fails, the local receipt should remain valid while external attestation status is marked as incomplete.
P
Benchmark Dataset Schema
The benchmark schema is intentionally small enough to audit by hand. Each scenario is a seed with tags, an expected behavior, and an optional suite-specific payload. The harness expands seeds into runtime variants, measures scored suites, and publishes a disclosure-safe profile. Table 18 documents the fields used by the public artifact. Table 18: Benchmark dataset schema used by the CAVA artifact. Field
Example
id
Stable scenario identifier used in tests, reports, and future regression tracking. az role assignment Representative raw runtime surface. It may create ... be shell text, MCP method notation, browser notation, or trace notation. policy_degradation, Suite membership and risk shape. Tags make wrapper_bypass the corpus composable without duplicating examples. Expected normalized action operation when push, payment the case is scored. deployment, payment Expected risk category for routing and aggregate metric calculation. approval Expected governance route for approvalbinding tests. true Marks cases that challenge portability across shell, MCP, browser, and managed-agent forms. false Prevents cloud drill cases from being confused with commands that should be executed by default. Nested shell deploy Human-readable red-team label. Reject changed finger- System-card behavior claim for qualitative print cases.
command
tags
expected. operation expected. category expected. decision runtime_ projection live_execution
attack expected_ behavior
Purpose
azure-role
The schema separates what can be public from what should remain commercial or securitysensitive. Public seeds can reveal that a parser must handle shell wrappers, policy degradation, and cloud authority changes. They do not need to reveal the full production parser grammar, customer connector rules, private policy thresholds, or tenant-specific evidence graph. This is the open-core balance: enough reproducibility for trust, enough withholding to preserve a business and avoid handing attackers the full bypass surface.
27
Q
Metric Definitions
The benchmark metrics are deliberately simple. The paper is not trying to hide behind a complicated scoring function. Each metric corresponds to a failure mode that an operator, reviewer, or buyer can understand. Table 19: Metric definitions for the CAVA benchmark. Metric
Definition
Interpretation
Semantic equivalence Fraction of equivalent rewrit- Low recall means approval can be recall ten actions that converge to bypassed by rewriting the same the baseline canonical finger- operation. print. Semantic separation Fraction of materially differ- Low precision means different conseprecision ent action pairs that do not quences become indistinguishable. collapse into the same canonical fingerprint. Wrapper-bypass Fraction of wrapped highLow catch rate means wrappers can catch rate impact actions still classified hide side effects. as high impact. Low control means the system punFalse-positive control Fraction of benign contaminated examples that avoid ishes harmless reading, search, or high-impact classification. documentation work. Approval-binding Fraction of approvals that Low correctness means approval correctness verify only against the canon- can drift from execution. ical fingerprint originally approved. Receipt reproducibil- Fraction of receipts that reLow reproducibility means evidence ity compute to the same digest cannot be independently replayed. under deterministic serialization. Attestation tamper Fraction of changed receipt Low detection means logs can be detection payloads rejected by the veri- edited after the fact. fier. Runtime portability Fraction of equivalent runLow convergence means each runconvergence time projections that preserve time becomes its own governance comparable action semantics. island. Semantic pattern Fraction of semantic-pattern Low detection means CAVA can detection cases where the expected name an action but not explain pattern set is detected and why the enterprise should care. routed through the selected policy profile. Policy-degradation Fraction of signature, trust, Low coverage means the governance coverage approval, retention, and pol- system can be weakened without icy weakening actions repre- itself being governed. sented as governed actions.
28
Metric
Definition
Interpretation
Cloud-action projec- Fraction of cloud drill cases tion coverage assigned an action class, risk posture, and live-execution boundary.
Low coverage means cloud controlplane actions remain opaque to deployer governance.
The metric definitions also define what CAVA is not measuring. CAVA does not measure model intelligence, task success, factuality, or general helpfulness. It measures whether runtime actions can be made governable. This narrower scope is a strength. The system can be wrong, tested, patched, and re-tested at the action layer without pretending to solve all of AI safety.
R
Claim Register
System cards are useful because they force claims to become inspectable. Table 20 records the current claim register for CAVA. Future versions should update this table whenever the benchmark, deployment posture, or commercial boundary changes. Table 20: CAVA claim register. ID
Claim
C1
CAVA can collapse equivalent shell Scored semanticforms for representative deployment, equivalence suite. infrastructure, payment, and Web3 actions. CAVA can separate benign text contain- False-positiveing dangerous substrings from actual control suite and high-impact actions. red-team cases.
C2
C3
C4
C5
C6
Current evidence
Limitation Public corpus is representative, not exhaustive.
Dataflow through pipes and scripts needs more coverage. CAVA can bind approvals to canonical Approval-binding Business approval fingerprints rather than display strings. tests and receipt quality remains verifier. outside the hash. CAVA receipts can detect changed re- Tamper-detection External storage ceipt payloads. tests. integrity depends on deployment controls. CAVA can project comparable action Runtime-portability Adapter coverage semantics across shell, MCP, browser, suite. varies by runtime and managed-agent records. and product integration depth. CAVA can represent governance weak- Policy-degradation Break-glass workening as a governed action. cases. flows require careful enterprise design.
29
ID
Claim
C7
CAVA can include Azure CLI actions Azure drill cases in semantic deployment drills without and CLI accountmutating resources by default. state evidence. The open package can support external Open-core package receipt verification without exposing and commercialOSuite production parser packs. boundary docs.
C8
C9
C10
C11
Current evidence
Optional Web3 and ledger substrates Attestationcan strengthen attestation without substrate design defining the whole system. and Web3 cases. CAVA composes with PCAA by provid- PCAA relationship ing the action identity PCAA governs. section and routereview-prove framing. CAVA semantic patterns turn canonical Semantic-pattern actions into policy-addressable mean- suite, policy-profile ings without becoming a separate prod- routing tests, and uct or authority layer. decision-detail evidence.
Limitation Live validation still requires a disposable cloud lab. Full managed behavior is not reproduced by the public skeleton. Ledger anchoring can leak metadata if used carelessly. PCAA itself must be implemented correctly by the deployment. Pattern definitions need continuous review as enterprise runtimes and attacker behavior change.
The claim register is intentionally conservative. A stronger-looking claim that cannot be tested is weaker in practice. The current version should be read as a foundation for adversarial review, not as a declaration that every runtime action in every enterprise will already be canonicalized perfectly.
S
Misuse and Abuse Analysis
Governance components can be misused. A deployer can use action verification to block legitimate work, surveil operators without consent, create brittle bureaucracy, or claim safety that the runtime cannot support. Table 21 records the current misuse analysis for CAVA. Table 21: Misuse and abuse analysis. Misuse pattern
Risk
Mitigation posture
Compliance theater Receipts are generated but never reviewed, creating false assurance. Overblocking Benign work is routed through unnecessary approvals, causing operators to bypass the system. Silent surveillance Runtime traces collect sensitive operator behavior without governance. 30
Require outcome closure, coverage disclosure, and buyer-facing proof bundles that expose gaps. Maintain false-positive controls and distinguish observation, simulation, mutation, and settlement. Scope collection to action evidence, minimize raw payload retention, and document tenant retention settings.
Misuse pattern
Risk
Mitigation posture
Authority laundering
A manager approves broad Treat policy weakening as a govpolicy degradation and later erned action with explicit dualclaims the system allowed it. control routes. A proprietary parser becomes Keep schema, fingerprints, receipts, Vendor lock-in the only way to verify eviand public verifier open. dence. Blockchain overPublic ledger anchoring leaks Treat ledgers as optional digest anreach metadata or becomes a gim- chors, not as the definition of CAVA. mick. Observer-mode over- A runtime that can only ob- Carry enforcement depth in evidence claim serve is marketed as if it can and product UI. block. Parser overfitting Public benchmark examples Add external traces, independent become memorized without red-team submissions, and private improving real coverage. regression suites. This analysis is included because a strong governance product should be able to criticize itself. The point of CAVA is not to centralize power in OSuite. The point is to make deployer authority inspectable. If CAVA ever becomes a tool for opaque vendor control, it has failed the philosophy that motivated it.
T
Evaluator Checklist
The checklist below is intended for reviewers who want to challenge CAVA before accepting it as a serious component. A future external artifact review can use this checklist directly. Table 22: Evaluator checklist for CAVA review. No.
Check
Evidence expected
1
Does an equivalent deployment action converge across direct shell, env, command, and nested shell forms? Does a benign search containing a dangerous string avoid escalation? Does an approval receipt fail when the fingerprint changes? Does a receipt hash reproduce when field order changes but semantics remain stable? Does a managed-agent trace project into the same action class as a shell action? Does a browser click carry business semantics rather than only UI coordinates?
Same canonical fingerprint or documented decomposition.
2 3 4 5 6
31
Observation category and falsepositive-control metric. Verifier rejects altered receipt. Deterministic hash match. Runtime portability result. Adapter mapping or coverage downgrade.
No.
Check
7
Does an MCP tool call avoid disappearing be- Tool namespace and method hind generic tool notation? projection. Does CAVA detect signature-mode or trustPolicy-degradation route. boundary degradation as a governed action? Does the system disclose observe-only coverage Enforcement-depth field or UI honestly? posture. Can an external verifier validate the open rePublic verifier and disclosureceipt without OSuite secrets? safe receipt. Are customer parser packs separated from the Commercial-boundary documenpublic open-core skeleton? tation. Are Azure or cloud drill commands clearly live_execution=false and marked as semantic cases, not commands to reproduction notes. execute? Does the system separate read-only wallet calls Web3 category and reversibility from wallet sends? marker. Does the system downgrade opaque private Coverage downgrade or required scripts instead of trusting names? parser pack. Does outcome closure record whether the action Closure event and receipt stasucceeded, failed, or partially executed? tus. Does the benchmark include red-team cases that Casebook with baseline failure the authors would rather not see? and residual risk.
8 9 10 11 12
13 14 15 16
Evidence expected
This checklist is deliberately practical. It gives a CISO, reviewer, or engineer a path to say “show me” rather than “tell me.” That is how CAVA should be sold and reviewed.
U
Open-Core and Commercial Boundary
CAVA should not be trapped inside OSuite so tightly that the ecosystem cannot trust it. At the same time, OSuite should not give away the entire managed product in a way that destroys the company’s ability to maintain the component. The recommended boundary is: • Open: schema, canonical serialization rules, hash and receipt verification, adapter interfaces, representative benchmark seeds, disclosure-safe red-team casebook, and publication profiles. • Managed: production parser packs, private connector enrichment, tenant policy thresholds, evidence graph, approval UI, export workflows, enterprise signer orchestration, customer-specific routing, retention controls, and support. • Self-host enterprise: custom parser pack installation, private signer configuration, internal connectors, offline verification, and integration with a customer’s existing security operations workflow. This boundary lets CAVA become a recognizable technical primitive while OSuite remains the production-grade operating layer. The open package should let a skeptical engineer verify that receipts are not magic. The paid product should make it unnecessary for an enterprise to build and maintain every parser, approval path, evidence graph, and assurance export alone. 32
V
Deployment Safeguards
Production deployment should follow a staged posture: 1. Observe: record CAVA fingerprints and receipts without blocking. 2. Warn: surface risk and coverage gaps to operators. 3. Approval-gate: bind high-impact actions to canonical fingerprints before release. 4. Dual control: require separate approval actors for identity, payment, production, or settlement lanes. 5. Quarantine: degrade or block high-impact action release when trust posture, signature mode, or receipt completeness fails. 6. External assurance: export selected proof bundles and attestations for buyer, auditor, or partner review. The important safety principle is not maximal blocking. It is honest binding and honest coverage disclosure. A runtime that only observes cannot be marketed as equivalent to a runtime that can enforce before side effects.
Part III
Artifact and Benchmark Package W
Benchmark Provenance
The benchmark harness is implemented as source-benchmark.mjs in the manuscript’s benchmark directory. It publishes representative scenarios, aggregate metrics, evaluation-suite metadata, ablation definitions, a red-team casebook, a comparative matrix, and Azure CLI deployment-drill evidence while withholding production parser packs, exact enterprise thresholds, customer connector rules, and managed evidence-graph internals.
X
Artifact Manifest
The paper ships a small artifact package under docs/research/papers/cava. The package contains: • main.tex and references.bib, the manuscript source; • main.pdf, the compiled paper; • benchmarks/source-benchmark.mjs, the executable benchmark harness; • benchmarks/latest.json, the latest full benchmark output; • benchmarks/publication-latest.json, the disclosure-safe publication profile; 33
• benchmark-embedded red-team casebook and ablation study definitions; • artifacts/MANIFEST.md, a human-readable artifact inventory; • artifacts/REPRODUCE.md, commands for rerunning tests and benchmark outputs.
Y
Reproducibility Protocol
The minimum reproduction protocol is: 1. run npm run cava:benchmark from the repository root; 2. run the CAVA benchmark unit tests; 3. rebuild the manuscript with latexmk -pdf main.tex; 4. compare the generated aggregate metrics with benchmarks/latest.json; 5. optionally confirm Azure CLI authentication with az account show –output json; do not execute mutating Azure drill commands outside a disposable test environment. This protocol is intentionally small enough to run locally. A larger artifact-evaluation track should add containerized execution, third-party runtime traces, and adversarial parser challenges.
Z
Disclosure Boundary
The public CAVA skeleton includes schema, hashing, receipts, and adapter contracts. The managed OSuite layer includes production parser packs, PCAA routing, approval workflows, evidence graph, replay, buyer exports, enterprise signers, KMS/HSM integrations, verifiable credential issuance, optional ledger anchoring, and managed connectors.
References [1] Cloud Native Computing Foundation. Introducing verifiable execution in dapr 1.18. https: //www.cncf.io/blog/2026/06/11/introducing-verifiable-execution-in-dapr-1-18/, 2026. [2] in-toto project. in-toto: A framework for securing the integrity of software supply chains. https://in-toto.io/, 2023. [3] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. Swe-bench: Can language models resolve real-world github issues? In International Conference on Learning Representations, 2024. [4] Richard Kang and Yudho Diponegoro. Governance gaps in agent interoperability protocols: What mcp, a2a, and acp cannot express. https://arxiv.org/abs/2606.31498, 2026. [5] Langfuse. Llm observability and application tracing. https://langfuse.com/docs/observab ility/overview, 2026. 34
[6] Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, Shudan Zhang, Xiang Deng, Aohan Zeng, Zhengxiao Du, Chenhui Zhang, Sheng Shen, Tianjun Zhang, Yu Su, Huan Sun, Minlie Huang, Yuxiao Dong, and Jie Tang. Agentbench: Evaluating llms as agents. In International Conference on Learning Representations, 2024. [7] Microsoft. Agent control specification: Portable runtime governance for ai agents. https: //commandline.microsoft.com/agent-control-specification-runtime-governance/, 2026. [8] National Institute of Standards and Technology. Artificial intelligence risk management framework: Generative artificial intelligence profile. https://www.nist.gov/publications/ artificial-intelligence-risk-management-framework-generative-artificial-intel ligence, 2024. [9] George C. Necula. Proof-carrying code. In Proceedings of the 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 106–119, 1997. [10] OpenAI. Frontier governance framework. https://cdn.openai.com/pdf/e37d949b-8c9f-4 d76-b99e-4272f4631a7e/openai-frontier-governance-framework.pdf, 2026. [11] OpenTelemetry. Semantic conventions for generative ai. https://github.com/open-telemet ry/semantic-conventions-genai, 2026. [12] OWASP GenAI Security Project. Owasp top 10 for agentic applications for 2026. https: //genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/, 2026. [13] Yangjun Ruan, Qingxiu Dong, Andrew Wang, Silviu Pitis, Yongchao Zhou, Jimmy Ba, Yann Dubois, Chris J. Maddison, and Tatsunori Hashimoto. Identifying the risks of lm agents with an lm-emulated sandbox. In International Conference on Learning Representations, 2024. [14] Sigstore. Sigstore documentation. https://docs.sigstore.dev/, 2024. [15] W3C. Verifiable credentials data model v2.0. https://www.w3.org/TR/vc-data-model-2.0/, 2025. [16] Zexun Wang. Proof-carrying agent actions: Model-agnostic runtime governance for heterogeneous agent systems. https://arxiv.org/abs/2606.04104, 2026.
35