CAVA: Canonical Action Verification and Attestation for Runtime Governance of Agentic AI Systems

# Canonical Action Verification and Attestation for Runtime Governance of Agentic AI Systems
Source: [https://arxiv.org/html/2607.13716](https://arxiv.org/html/2607.13716)
\(June 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 runtime\-semantics layer for converting heterogeneous agent activity into canonical runtime action objects\. CAVA is positioned below Proof\-Carrying Agent Actions \(PCAA\): PCAA defines the deployer\-owned 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 IMain Research Manuscript

### 1Introduction

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, 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 asenv,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](https://arxiv.org/html/2607.13716#bib.bib16)\]\. 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. 1\.a formalization of canonical runtime action identity for heterogeneous agent systems;
2. 2\.a CAVA protocol that binds policy outcomes, approvals, receipts, and attestations to canonical action fingerprints rather than raw text;
3. 3\.a Semantic Pattern Layer inside CAVA that maps canonical actions and externality context into policy\-addressable patterns rather than customer\-specific rules;
4. 4\.a threat model for semantic bypass, wrapper bypass, approval drift, evidence laundering, and parser capture;
5. 5\.a reference open\-core implementation boundary separating portable schema and receipt verification from managed parser packs and enterprise evidence operations;
6. 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\.

### 2Related Work

#### 2\.1Agent evaluation and tool\-use risk

AgentBench frames agent evaluation as an interactive\-environment problem rather than only a static\-response problem\[[6](https://arxiv.org/html/2607.13716#bib.bib6)\]\. SWE\-bench similarly treats real software repositories as a practical testbed for evaluating autonomous coding behavior\[[3](https://arxiv.org/html/2607.13716#bib.bib3)\]\. ToolEmu focuses on risk discovery for tool\-augmented language\-model agents through emulated tool execution\[[13](https://arxiv.org/html/2607.13716#bib.bib13)\]\. 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\.2Runtime 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](https://arxiv.org/html/2607.13716#bib.bib7)\]\. OpenTelemetry GenAI semantic conventions standardize telemetry fields for LLM and agent systems\[[11](https://arxiv.org/html/2607.13716#bib.bib11)\]\. Langfuse and similar platforms expose tracing, prompt management, evaluations, and observability workflows\[[5](https://arxiv.org/html/2607.13716#bib.bib5)\]\. 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\.3Proof, receipts, and attestations

Proof\-carrying code established the idea that an executable artifact can travel with a machine\-checkable proof object\[[9](https://arxiv.org/html/2607.13716#bib.bib9)\]\. Modern software supply\-chain systems such as in\-toto and Sigstore provide signed provenance and attestation patterns for build and release workflows\[[2](https://arxiv.org/html/2607.13716#bib.bib2),[14](https://arxiv.org/html/2607.13716#bib.bib14)\]\. Verifiable Credentials provide portable claim structures for cross\-party verification\[[15](https://arxiv.org/html/2607.13716#bib.bib15)\]\. Dapr Verifiable Execution contributes signed workflow history and execution attestation\[[1](https://arxiv.org/html/2607.13716#bib.bib1)\]\. CAVA is complementary: it defines what runtime action those receipts or attestations should bind to\.

#### 2\.4Governance frameworks

Frontier\-governance frameworks increasingly document risk identification, risk analysis, mitigations, incident response, model reporting, expert input, responsibility allocation, and change management\[[10](https://arxiv.org/html/2607.13716#bib.bib10)\]\. 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\.

### 3Problem Formulation

#### 3\.1Runtime heterogeneity

Letℛ\\mathcal\{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∈𝒜rfor runtime​r∈ℛ\.a\\in\\mathcal\{A\}\_\{r\}\\quad\\text\{for runtime \}r\\in\\mathcal\{R\}\.The deployer\-facing question is not merely whetheraacontains a suspicious string\. The question is whetheraarepresents a business action that should be allowed, warned, approval\-gated, blocked, or later audited\.

###### Definition 1\(Canonical runtime action\)\.

For a raw runtime eventaa, a CAVA canonicalizer mapsaato a canonical runtime action

C​\(a\)=\(v,r,e,o,k,S,τ,u,m\),C\(a\)=\(v,r,e,o,k,S,\\tau,u,m\),wherevvis schema version,rris runtime family,eeis executable or tool identity,oois normalized operation,kkis risk category,SSis the set of touched systems,τ\\tauis reversibility,uuis target or subject context, andmmis bounded adapter metadata\.

###### Definition 2\(Canonical fingerprint\)\.

Letcanon​\(⋅\)\\mathrm\{canon\}\(\\cdot\)denote deterministic serialization over selected canonical fields\. The CAVA fingerprint is

F​\(a\)=H​\(canon​\(C​\(a\)\)\),F\(a\)=H\(\\mathrm\{canon\}\(C\(a\)\)\),whereHHis a collision\-resistant hash function\. Policy decisions, approval receipts, and audit evidence bind toF​\(a\)F\(a\)rather than to raw runtime text\.

#### 3\.2Desired properties

CAVA is designed around six properties:

1. 1\.Semantic equivalence\.Equivalent expressions of the same action should converge to the same canonical identity\.
2. 2\.Semantic separation\.Materially different actions should not collapse into the same governance object\.
3. 3\.Wrapper robustness\.Shell wrappers, SDK helpers, tool aliases, and runtime indirection should not hide high\-impact actions\.
4. 4\.Approval binding\.Approval must bind to canonical action meaning, not to a display string\.
5. 5\.Receipt reproducibility\.Independent verifiers should be able to recompute receipt hashes from the published object\.
6. 6\.Runtime portability\.Different runtime families should project comparable action semantics without pretending that all runtimes expose equal enforcement depth\.

#### 3\.3Threat 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 behindenv,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\.
- •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\.

### 4Canonical Action Verification and Attestation

#### 4\.1Protocol

CAVA can be expressed as a six\-stage protocol:

1. 1\.Capture: collect the raw runtime event and execution context\.
2. 2\.Normalize: map the raw event into a canonical runtime action\.
3. 3\.Interpret: detect policy\-addressable semantic patterns from canonical action, boundary, provenance, and data signals\.
4. 4\.Fingerprint: compute a deterministic hash over canonical action semantics\.
5. 5\.Bind: attach policy outcomes, approvals, denials, or escalations to the fingerprint\. This is approval binding at the action\-meaning layer\.
6. 6\.Close: attach outcome, evidence, exceptions, and side\-effect summaries\.
7. 7\.Attest: optionally sign, credential, ledger\-anchor, or externally verify receipt material\.

Captureraw eventNormalizeactionInterpretpatternsFingerprintsemanticsBindapprovalCloseevidenceReceipt hashand verifierOptional 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\.
#### 4\.2Canonical action object

Table[1](https://arxiv.org/html/2607.13716#S4.T1)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\.

Table 1:Reference CAVA canonical action fields\.###### Proposition 1\(Raw text is insufficient for approval binding\)\.

If a governance decision binds only to a raw string representations​\(a\)s\(a\), then any alternative representations′​\(a\)s^\{\\prime\}\(a\)with the same operational effect but different text may evade a policy keyed ons​\(a\)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\.3Relationship 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](https://arxiv.org/html/2607.13716#bib.bib16)\]\. CAVA is the lower layer that makes the object stable enough to govern\. A PCAA certificate can contain route decisions and 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\.4Semantic 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\},P\(C\(a\),B\(a\),D\(a\)\)\\rightarrow\\\{p\_\{1\},\\ldots,p\_\{n\}\\\},whereC​\(a\)C\(a\)is the canonical action,B​\(a\)B\(a\)is boundary context such as destination visibility and account provenance, andD​\(a\)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\.

Table 2:Reference CAVA semantic patterns\.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\[[12](https://arxiv.org/html/2607.13716#bib.bib12),[8](https://arxiv.org/html/2607.13716#bib.bib8)\]\. CAVA’s role is narrower: convert runtime behavior into evidence\-bearing patterns that policy profiles can address\.

#### 4\.5Bounded 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\.

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\.

Table 3:How CAVA composes with BAF and AREG inside OSuite\.
#### 4\.6Attestation 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\.

### 5Reference 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\.

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\.

Table 4:Open\-core boundary in the reference implementation\.
### 6Evaluation

#### 6\.1Benchmark 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. 1\.semantic equivalence across rewritten action forms;
2. 2\.semantic separation across materially different operations;
3. 3\.wrapper\-bypass catch rate;
4. 4\.false\-positive control for benign text containing high\-impact strings;
5. 5\.approval binding correctness;
6. 6\.receipt reproducibility;
7. 7\.attestation tamper detection;
8. 8\.runtime portability convergence;
9. 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\.

#### 6\.2Results

Table[5](https://arxiv.org/html/2607.13716#S6.T5)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\.

Table 5:Aggregate benchmark results on the 96\-seed, 384\-variant CAVA corpus\.EquivalenceWrapperFalse PositivePatternsApprovalAttestation00\.50\.511ScoreCAVA vs\. Raw\-Text and First\-Token BaselinesRaw textFirst\-tokenCAVAFigure 2:Representative benchmark slices\. CAVA’s advantage comes from binding decisions to canonical action semantics rather than display text or first\-token heuristics\.

### 7Expanded 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, whether runtime families converge, and whether governance itself can be weakened\. TableLABEL:tab:evaluation\-matrixreports 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\.SuiteWhat is challengedPublic supportPrimary metricSemantic equivalenceSame operational action rewritten through flags, environment variables, command wrappers, or helper forms\.12 scored variantsEquivalence recallSemantic separationMaterially different actions that share words, tools, or nearby context\.8 pairwise checksSeparation precisionWrapper bypassHigh\-impact action hidden behindenv,sudo,command,bash \-c, or nested shells\.14 checks including ablationsBypass catch rateBenign contaminationRead\-only commands containing high\-impact strings such asgit push,kubectl delete, or payment events\.7 checks including ablationsFalse\-positive controlApproval driftReceipt replay or approval reuse after canonical fields change\.8 checks including ablationsApproval\-binding correctnessReceipt tamperingModified policy outcomes, altered receipt fields, or order\-dependent serialization\.8 checksHash reproducibility and tamper detectionRuntime portabilityShell, MCP, browser, and managed\-agent records describing comparable operational actions\.16 runtime projectionsPortability convergenceSemantic pattern detectionCanonical actions plus boundary context mapped to reusable patterns such as public egress, security\-control weakening, delegated authority mismatch, and workflow sink risk\.6 scored casesPattern detection and profile routingPolicy degradationSignature disabling, permissive policy changes, trust\-boundary broadening, and evidence retention weakening\.8 structured casesDegradation coverageAzure deployment drillAzure CLI actions across what\-if, deployment, role assignment, Key Vault, SQL firewall, and ACR read paths\.6 structured casesCloud\-action projection coverageRed\-team casebookAttacker\-style narratives linking bypass method, baseline failure, expected CAVA behavior, and residual risk\.24 casesQualitative coverageThis 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\.

### 8Ablation Study

TableLABEL:tab:ablation\-studyreports 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\.AblationAffected suitesExpected failureRetained scoreRemove wrapper parsingWrapper bypass, semantic equivalenceenv,sudo,bash \-c, and nested shells remain surface text; high\-impact action can hide behind the wrapper\.0\.00Remove profile aliasesPayment, Web3, customer private toolsDomain\-specific operations such as Stripe triggers or wallet sends collapse to unknown or low\-confidence actions\.0\.50Remove canonical fingerprintApproval drift, runtime portabilityApproval binds to display text or runtime\-native IDs rather than action meaning\.0\.00Remove receipt verifierReceipt tampering, external assuranceChanged decisions and receipt payloads become log entries instead of verifier failures\.0\.00Remove PCAA bindingPolicy degradation, approval drift, outcome closureCanonical fingerprints exist, but no deployer\-owned route\-review\-prove loop decides authority or closure\.0\.25The 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\.

### 9Interpretation

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, andbash \-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, customer\-approved anonymized examples, and adversarial parser challenges\.

### 10Discussion

#### 10\.1Why 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\.2Where 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\.3Market 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\.

### 11Threats 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\.

### 12Conclusion

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 IICAVA System Card and Technical Appendix

### Appendix ASystem 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\.

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\.

### Appendix BObserved 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\.

ChallengeFailure patternCAVA evaluation sliceEquivalent syntaxThe same operation is rewritten through flags, environment variables, shell wrappers, or helper commands\.Semantic equivalence recallSemantic separationA benign action contains a high\-impact string or shares an executable with a high\-impact action\.Semantic separation precision and false\-positive controlWrapper bypassThe high\-impact operation hides behindenv,sudo,command,bash \-c, SDK indirection, or tool aliasing\.Wrapper\-bypass catch rateApproval driftThe operator approves display text while execution binds to a different action\.Approval binding correctnessReceipt driftA receipt is recomputed under a different field order, profile, or decision payload\.Receipt reproducibilityAttestation tamperingA receipt or policy outcome is modified after approval\.Attestation tamper detectionRuntime fragmentationShell hooks, MCP tools, browser actions, and managed traces describe the same action differently\.Runtime portability convergence
### Appendix CRisk 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 classExamplesGovernance implicationObservationSearch, list, inspect, read\-only queryUsually allow or log, unless sensitive data boundary is crossed\.Build and preparationBuild, dry run, plan, simulationOften allow or simulate\-first; useful for reducing unnecessary review\.DeploymentPush, release, publish, migrateRequires canonical identity, approval binding, and outcome closure\.Infrastructure changeTerraform, Kubernetes, Helm, Pulumi, firewall changeRequires high\-integrity receipts and rollback evidence\.Database mutationInsert, update, delete, truncate, migrationRequires target clarity, reversibility disclosure, and approval binding\.Identity and authorityKey rotation, permission grant, user creationRequires authority lineage and dual\-control in high\-impact cases\.Payment and obligationCharge, refund, invoice, transferRequires receipt integrity and financial\-system boundary disclosure\.Data boundaryExport, upload, email, public shareRequires destination visibility and account provenance\.Web3 settlementSign, send, bridge, swap, sponsor, relayRequires cryptographic intent binding and optional ledger anchoring\.
### Appendix DCapability 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\. TableLABEL:tab:capability\-taxonomydefines the capability taxonomy used by the current paper and artifact package\.

Table 10:CAVA capability taxonomy for deployment disclosure\.CapabilityMinimum evidenceFailure if absentTypical release postureCaptureRaw event, runtime family, adapter ID, timestamp, actor or session handle\.The action may occur outside the evidence boundary\.ObserveNormalizationCanonical action fields and schema version\.Similar actions remain incomparable across runtime surfaces\.Observe or warnSemantic separationEvidence that benign lookalikes do not collapse into high\-impact actions\.False positives erode operator trust and produce alert fatigue\.WarnWrapper resilienceEvidence that common wrappers are stripped or decomposed\.High\-impact actions hide behind shell or SDK indirection\.Approval\-gateApproval bindingReceipt connecting decision, policy, and canonical fingerprint\.The operator may approve one thing while another executes\.Approval\-gateReceipt reproducibilityDeterministic serialization and verifier output\.Evidence cannot be independently replayed\.Approval\-gateOutcome closureExecution result, exception, or partial\-coverage marker\.Governance ends at approval and loses operational truth\.Approval\-gateCoverage disclosureEnforcement depth, adapter confidence, and unknown\-field posture\.Observe\-only traces are confused with blocking controls\.Warn or approval\-gatePolicy degradation detectionCanonical treatment of policy, signature, retention, and trust changes\.Governance controls can be weakened under the language of configuration\.Dual controlExternal attestationSignature, verifiable credential, supply\-chain attestation, or optional ledger anchor\.Buyer\-facing assurance depends on local logs only\.External assuranceThis 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\.

### Appendix ESafeguard Design

CAVA safeguards are layered so that deployments can increase assurance without redefining the base object\.

1. 1\.Normalization safeguards: adapters strip common wrappers, resolve aliases, and project runtime\-specific fields into stable canonical fields\.
2. 2\.Binding safeguards: policy outcomes and approvals attach to canonical fingerprints rather than raw strings\.
3. 3\.Receipt safeguards: receipt hashes are deterministic and can be recomputed by independent verifiers\.
4. 4\.Coverage safeguards: runtime family, adapter mode, and enforcement depth remain explicit so observer\-only coverage is not presented as inline blocking\.
5. 5\.Attestation safeguards: selected receipt digests can be signed, credentialed, or ledger\-anchored without publishing confidential action contents\.
6. 6\.Commercial\-boundary safeguards: the open package exposes verification primitives, while managed OSuite holds production parser maintenance, evidence operations, and enterprise connector depth\.

### Appendix FRed\-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. 1\.Syntax rewriting: equivalent operations are rewritten through flags, environment variables, shells, aliases, and scripts\.
2. 2\.Benign contamination: low\-risk commands intentionally contain dangerous substrings such asgit push,kubectl delete, orDROP TABLE\.
3. 3\.Runtime projection: the same action is represented as shell, MCP, browser, managed\-agent, and API\-gateway events\.
4. 4\.Approval mismatch: approval receipts are replayed against altered fingerprints or changed policy payloads\.
5. 5\.Evidence tampering: receipt fields are changed after closure to test verifier detection\.
6. 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\.

### Appendix GRed\-Team Casebook

TableLABEL:tab:red\-team\-casebookis 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\.IDAttackRepresentative eventBaseline failureCAVA expected behaviorRT\-001Nested shell deploybash \-lc npm\-deployFirst\-token rules seebash, not deploy\.Unwrap nested shell and classify deployment\.RT\-002Benign documentation searchrg "kubectl delete namespace prod"Substring policy escalates read\-only search\.Classify observation and suppress false positive\.RT\-003Approval replay against changed branchgit push origin release\-candidateDisplay resembles approved push\.Reject receipt if fingerprint differs\.RT\-004SDK payment indirectionmcp\.stripe\.refund\(\.\.\.\)No shell token exists to match\.Project MCP call into payment category\.RT\-005Browser release buttonbrowser publish\-releaseTrace only says click\.Bind UI action to deployment semantics\.RT\-006Managed trace field driftagent github\.push traceRuntime\-native trace misses shell policy\.Project managed trace into deployment class\.RT\-007Receipt decision tamperreceipt\.decision = "allow"Log\-only systems may not recompute integrity\.Detect receipt\-hash mismatch\.RT\-008Policy loosening after importosuite policy update \-\-mode allow\-allConfiguration looks administrative\.Classify as policy degradation\.RT\-009Signature mode disableosuite signature offVerifier disappears without side\-effect label\.Mark trust degradation and refuse proof claims\.RT\-010Azure role escalationaz role create ContributorGeneric CLI command hides authority change\.Require identity\-authority review\.RT\-011Azure destructive Key Vault operationaz keyvault purge \-\-name prod\-vaultIrreversibility may be unknown\.Mark destructive and non\-reversible\.RT\-012Database mutation through MCP querymcp\.postgres deleteGeneric query hides mutation\.Parse SQL operation and classify mutation\.RT\-013Wallet settlement actioncast send 0xabc 1etherEnterprise\-only policy misses settlement finality\.Classify Web3 transaction and bind signing intent\.RT\-014Read\-only wallet callcast call 0xabc balanceOfToken match over\-escalates all wallet use\.Separate observation from settlement\.RT\-015Open firewall rangeaz sql firewall open\-allInfrastructure write lacks blast\-radius semantics\.Classify infrastructure and boundary expansion\.RT\-016Deployment docs false positivecurl docs/git\-pushSubstring policy sees git push\.Classify network read or documentation lookup\.RT\-017Approval TTL expansionosuite approvals configure \-\-ttl 30dPolicy drift is not a direct side effect\.Route as governance degradation\.RT\-018Public share through browserbrowser share publicUI trace omits data\-boundary semantics\.Classify data\-boundary expansion\.RT\-019Receipt order mutationSame receipt fields serialized differently\.Non\-deterministic receipts fail replay\.Canonical serialization reproduces the hash\.RT\-020Unknown private script\./release\-prod\.shScript name may be trusted blindly\.Downgrade coverage or require parser pack\.RT\-021Environment policy bypassenv policy\-off deployDeployment and override blend together\.Classify deployment and policy degradation\.RT\-022Managed data exportagent crm\.export traceExport looks like a workflow step\.Classify data\-boundary action\.RT\-023Kubernetes delete echoedecho "kubectl delete namespace prod"Dangerous substring creates false positive\.Classify echo as benign text emission\.RT\-024Attestation anchor unavailableLedger anchor timeout after local receipt\.External anchor failure is confused with no evidence\.Preserve local receipt and mark external 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\.

### Appendix HFailure Modes and Incident Classes

CAVA should treat failures as first\-class operational incidents:

Incident classDescriptionRequired responseParser missA high\-impact action is classified as low risk or unknown\.Add regression seed, document adapter gap, update parser pack\.Parser overreachA benign action is escalated because of string contamination or weak context\.Add false\-positive seed, refine semantic separation\.Fingerprint collisionMaterially different actions converge to the same governance identity\.Treat as critical schema or canonicalization defect\.Approval mismatchApproval binds to a fingerprint different from the executed action\.Block closure, require operator review, preserve mismatch receipt\.Receipt gapExecution proceeds without required receipt material\.Mark partial coverage and prevent buyer\-facing proof claims\.Adapter degradationA runtime stops emitting required fields or changes event shape\.Downgrade coverage posture until adapter verification passes\.Attestation failureSignature, credential, or ledger anchor cannot verify\.Preserve local receipt and mark external attestation failed\.
### Appendix IComparative System Boundary

CAVA is intentionally narrower than model safety frameworks and broader than runtime traces\. Table[13](https://arxiv.org/html/2607.13716#A9.T13)summarizes the distinction\.

Table 13:CAVA compared with adjacent system families\.
### Appendix JComparative 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\.

TableLABEL:tab:comparative\-evaluationcompares 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](https://arxiv.org/html/2607.13716#bib.bib4)\]\. 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\.

Table 14:Comparative evaluation against adjacent public system families\.System familyPrimary objectStrengthCAVA claimMicrosoft Agent Control Specification\[[7](https://arxiv.org/html/2607.13716#bib.bib7)\]Runtime governance contractPortable governance language across agent runtimes and policy engines\.CAVA can supply the canonical action fingerprint and receipt semantics that such contracts need at decision time\.Dapr Verifiable Execution\[[1](https://arxiv.org/html/2607.13716#bib.bib1)\]Signed workflow historyStrong provenance and tamper evidence for workflow execution\.CAVA defines the action identity before the workflow history is signed or attested\.OpenTelemetry GenAI\[[11](https://arxiv.org/html/2607.13716#bib.bib11)\]Spans, events, metrics, semantic attributesShared observability language for GenAI systems\.CAVA turns action semantics into an approval and receipt object, not merely a trace attribute\.Langfuse\[[5](https://arxiv.org/html/2607.13716#bib.bib5)\]LLM application traces, prompts, evaluationsDeveloper\-friendly observability and debugging for LLM applications\.CAVA focuses on authority binding, replayable proof, and deployer\-side closure\.Supply\-chain attestationBuild provenance, signing, release metadataMature patterns for build and artifact integrity\.CAVA extends the proof target from software artifacts to agent runtime actions\.Prompt guardrails and content filtersPrompt, output, validator resultUseful first line for content and instruction control\.CAVA governs side effects after the model has chosen or attempted an action\.OSuite managed layerEvidence graph, approval workflow, exportsProductized operations, connectors, signers, buyer assurance\.OSuite operationalizes CAVA without 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 receipt integrity, disclose coverage depth, and let the deployer rather than the frontier provider own the final governance loop\.

### Appendix KAzure 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 withaz account show \-\-output json, and the benchmark includes Azure deployment\-drill cases foraz deployment group what\-if,az containerapp update,az role assignment create,az keyvault purge,az sql server firewall\-rule create, andaz 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\.

### Appendix LImplementation 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\.

Table 15:CAVA rollout lessons and product corrections\.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\.

### Appendix MExternal 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. 1\.Third\-party runtime traces: collect customer\-approved anonymized traces from coding agents, browser agents, MCP tools, and managed\-agent platforms\.
2. 2\.Cloud drill lab: run Azure, GitHub, Stripe sandbox, database, and Kubernetes test cases in disposable environments with automated cleanup\.
3. 3\.Independent parser challenge: publish a red\-team input format where external reviewers submit bypass attempts and false\-positive traps\.
4. 4\.Buyer\-facing proof review: give security leaders a receipt bundle and ask whether it answers procurement and audit questions\.
5. 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\.

### Appendix NKnown Gaps and Residual Risk

CAVA is not finished, and the paper should not pretend otherwise\.

Table 16:Known gaps and residual risks for current CAVA\.GapWhy it mattersCurrent mitigationOpaque private scriptsA single script name can hide many side effects\.Downgrade coverage and require parser pack, sandbox run, or human review\.Multi\-action commandsOne raw event can contain a deploy, policy bypass, and data movement together\.Treat decomposition as a required parser capability for high\-risk lanes\.Vendor schema driftManaged\-agent or MCP event shapes may change\.Version adapters and include adapter degradation incidents\.Business\-context dependenceSeverity depends on tenant, branch, role, account, data label, or environment\.Enrich with OSuite connectors and disclose when context is missing\.External attestation availabilityLedger, signer, or credential services can fail\.Preserve local receipts and mark external attestation status separately\.Benchmark saturationA fixed public corpus can be overfit\.Expand with third\-party traces and adversarial submissions\.Commercial disclosure boundaryWithholding parser packs limits full reproduction\.Keep schema, hashes, receipts, and representative cases public\.Operator misuseA valid receipt can approve a bad business decision\.Bind to PCAA routes, dual 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\.

### Appendix OOperational 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\.

Table 17:Operational scenario cards for CAVA deployment review\.ScenarioRuntime actionEvidence CAVA must produceReviewer questionProduction releaseAgent pushes code, updates a container image, or clicks a release button\.Canonical deployment fingerprint, approval receipt, actor/session, target branch or service, outcome closure\.Can the buyer prove which release action was approved?Cloud authority changeAgent grants a role, changes a managed identity, rotates a secret, or modifies a trust boundary\.Identity\-authority category, touched tenant or scope, non\-reversibility marker, dual\-control route\.Could the agent silently make itself more powerful?Database mutationAgent runs SQL, migration tooling, or an ORM deploy step\.Database mutation category, target database, operation class, approval binding, rollback or irreversible marker\.Is a read\-only query clearly separated from mutation?Browser administrationAgent operates an admin console through UI automation\.DOM\-to\-business\-action mapping, page identity, control label, canonical action projection, coverage disclosure\.Does a click mean anything auditable?MCP tool executionAgent calls a tool server rather than a shell command\.Tool namespace, method, normalized operation, system touched, adapter confidence\.Does governance survive tool indirection?Payment or obligationAgent triggers a charge, refund, invoice, subscription update, or external obligation\.Payment category, amount or obligation class when available, approval receipt, finance\-system boundary\.Can finance dispute or replay the decision?Data boundary expansionAgent exports, uploads, shares, emails, or publishes data\.Destination, data boundary category, sensitivity context when available, outcome closure\.Can the customer identify where data moved?Web3 settlementAgent signs, sends, sponsors, bridges, swaps, or relays a transaction\.Signing intent, chain or settlement lane, target, value class, optional ledger or credential anchor\.Is read\-only inspection separated from irreversible 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 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\.

### Appendix PBenchmark 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\. TableLABEL:tab:dataset\-schemadocuments the fields used by the public artifact\.

Table 18:Benchmark dataset schema used by the CAVA artifact\.FieldExamplePurposeidazure\-roleStable scenario identifier used in tests, reports, and future regression tracking\.commandaz role assignment create \.\.\.Representative raw runtime surface\. It may be shell text, MCP method notation, browser notation, or trace notation\.tagspolicy\_degradation,wrapper\_bypassSuite membership and risk shape\. Tags make the corpus composable without duplicating examples\.expected\.operationpush,paymentExpected normalized action operation when the case is scored\.expected\.categorydeployment,paymentExpected risk category for routing and aggregate metric calculation\.expected\.decisionapprovalExpected governance route for approval\-binding tests\.runtime\_projectiontrueMarks cases that challenge portability across shell, MCP, browser, and managed\-agent forms\.live\_executionfalsePrevents cloud drill cases from being confused with commands that should be executed by default\.attackNested shell deployHuman\-readable red\-team label\.expected\_behaviorReject changed fingerprintSystem\-card behavior claim for qualitative cases\.The schema separates what can be public from what should remain commercial or security\-sensitive\. 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\.

### Appendix QMetric 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\.MetricDefinitionInterpretationSemantic equivalence recallFraction of equivalent rewritten actions that converge to the baseline canonical fingerprint\.Low recall means approval can be bypassed by rewriting the same operation\.Semantic separation precisionFraction of materially different action pairs that do not collapse into the same canonical fingerprint\.Low precision means different consequences become indistinguishable\.Wrapper\-bypass catch rateFraction of wrapped high\-impact actions still classified as high impact\.Low catch rate means wrappers can hide side effects\.False\-positive controlFraction of benign contaminated examples that avoid high\-impact classification\.Low control means the system punishes harmless reading, search, or documentation work\.Approval\-binding correctnessFraction of approvals that verify only against the canonical fingerprint originally approved\.Low correctness means approval can drift from execution\.Receipt reproducibilityFraction of receipts that recompute to the same digest under deterministic serialization\.Low reproducibility means evidence cannot be independently replayed\.Attestation tamper detectionFraction of changed receipt payloads rejected by the verifier\.Low detection means logs can be edited after the fact\.Runtime portability convergenceFraction of equivalent runtime projections that preserve comparable action semantics\.Low convergence means each runtime becomes its own governance island\.Semantic pattern detectionFraction of semantic\-pattern cases where the expected pattern set is detected and routed through the selected policy profile\.Low detection means CAVA can name an action but not explain why the enterprise should care\.Policy\-degradation coverageFraction of signature, trust, approval, retention, and policy weakening actions represented as governed actions\.Low coverage means the governance system can be weakened without itself being governed\.Cloud\-action projection coverageFraction of cloud drill cases assigned an action class, risk posture, and live\-execution boundary\.Low coverage means cloud control\-plane 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\.

### Appendix RClaim Register

System cards are useful because they force claims to become inspectable\. TableLABEL:tab:claim\-registerrecords 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\.IDClaimCurrent evidenceLimitationC1CAVA can collapse equivalent shell forms for representative deployment, infrastructure, payment, and Web3 actions\.Scored semantic\-equivalence suite\.Public corpus is representative, not exhaustive\.C2CAVA can separate benign text containing dangerous substrings from actual high\-impact actions\.False\-positive\-control suite and red\-team cases\.Dataflow through pipes and scripts needs more coverage\.C3CAVA can bind approvals to canonical fingerprints rather than display strings\.Approval\-binding tests and receipt verifier\.Business approval quality remains outside the hash\.C4CAVA receipts can detect changed receipt payloads\.Tamper\-detection tests\.External storage integrity depends on deployment controls\.C5CAVA can project comparable action semantics across shell, MCP, browser, and managed\-agent records\.Runtime\-portability suite\.Adapter coverage varies by runtime and product integration depth\.C6CAVA can represent governance weakening as a governed action\.Policy\-degradation cases\.Break\-glass workflows require careful enterprise design\.C7CAVA can include Azure CLI actions in semantic deployment drills without mutating resources by default\.Azure drill cases and CLI account\-state evidence\.Live validation still requires a disposable cloud lab\.C8The open package can support external receipt verification without exposing OSuite production parser packs\.Open\-core package and commercial\-boundary docs\.Full managed behavior is not reproduced by the public skeleton\.C9Optional Web3 and ledger substrates can strengthen attestation without defining the whole system\.Attestation\-substrate design and Web3 cases\.Ledger anchoring can leak metadata if used carelessly\.C10CAVA composes with PCAA by providing the action identity PCAA governs\.PCAA relationship section and route\-review\-prove framing\.PCAA itself must be implemented correctly by the deployment\.C11CAVA semantic patterns turn canonical actions into policy\-addressable meanings without becoming a separate product or authority layer\.Semantic\-pattern suite, policy\-profile routing tests, and decision\-detail evidence\.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\.

### Appendix SMisuse 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\. TableLABEL:tab:misuse\-analysisrecords the current misuse analysis for CAVA\.

Table 21:Misuse and abuse analysis\.Misuse patternRiskMitigation postureCompliance theaterReceipts are generated but never reviewed, creating false assurance\.Require outcome closure, coverage disclosure, and buyer\-facing proof bundles that expose gaps\.OverblockingBenign work is routed through unnecessary approvals, causing operators to bypass the system\.Maintain false\-positive controls and distinguish observation, simulation, mutation, and settlement\.Silent surveillanceRuntime traces collect sensitive operator behavior without governance\.Scope collection to action evidence, minimize raw payload retention, and document tenant retention settings\.Authority launderingA manager approves broad policy degradation and later claims the system allowed it\.Treat policy weakening as a governed action with explicit dual\-control routes\.Vendor lock\-inA proprietary parser becomes the only way to verify evidence\.Keep schema, fingerprints, receipts, and public verifier open\.Blockchain overreachPublic ledger anchoring leaks metadata or becomes a gimmick\.Treat ledgers as optional digest anchors, not as the definition of CAVA\.Observer\-mode overclaimA runtime that can only observe is marketed as if it can block\.Carry enforcement depth in evidence and product UI\.Parser overfittingPublic benchmark examples become memorized without improving real coverage\.Add external traces, independent red\-team submissions, and private 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\.

### Appendix TEvaluator 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\.CheckEvidence expected1Does an equivalent deployment action converge across direct shell,env,command, and nested shell forms?Same canonical fingerprint or documented decomposition\.2Does a benign search containing a dangerous string avoid escalation?Observation category and false\-positive\-control metric\.3Does an approval receipt fail when the fingerprint changes?Verifier rejects altered receipt\.4Does a receipt hash reproduce when field order changes but semantics remain stable?Deterministic hash match\.5Does a managed\-agent trace project into the same action class as a shell action?Runtime portability result\.6Does a browser click carry business semantics rather than only UI coordinates?Adapter mapping or coverage downgrade\.7Does an MCP tool call avoid disappearing behind generic tool notation?Tool namespace and method projection\.8Does CAVA detect signature\-mode or trust\-boundary degradation as a governed action?Policy\-degradation route\.9Does the system disclose observe\-only coverage honestly?Enforcement\-depth field or UI posture\.10Can an external verifier validate the open receipt without OSuite secrets?Public verifier and disclosure\-safe receipt\.11Are customer parser packs separated from the public open\-core skeleton?Commercial\-boundary documentation\.12Are Azure or cloud drill commands clearly marked as semantic cases, not commands to execute?live\_execution=falseand reproduction notes\.13Does the system separate read\-only wallet calls from wallet sends?Web3 category and reversibility marker\.14Does the system downgrade opaque private scripts instead of trusting names?Coverage downgrade or required parser pack\.15Does outcome closure record whether the action succeeded, failed, or partially executed?Closure event and receipt status\.16Does the benchmark include red\-team cases that the authors would rather not see?Casebook with baseline failure and residual risk\.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\.

### Appendix UOpen\-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\.

### Appendix VDeployment Safeguards

Production deployment should follow a staged posture:

1. 1\.Observe: record CAVA fingerprints and receipts without blocking\.
2. 2\.Warn: surface risk and coverage gaps to operators\.
3. 3\.Approval\-gate: bind high\-impact actions to canonical fingerprints before release\.
4. 4\.Dual control: require separate approval actors for identity, payment, production, or settlement lanes\.
5. 5\.Quarantine: degrade or block high\-impact action release when trust posture, signature mode, or receipt completeness fails\.
6. 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 IIIArtifact and Benchmark Package

### Appendix WBenchmark Provenance

The benchmark harness is implemented assource\-benchmark\.mjsin 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\.

### Appendix XArtifact Manifest

The paper ships a small artifact package underdocs/research/papers/cava\. The package contains:

- •main\.texandreferences\.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;
- •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\.

### Appendix YReproducibility Protocol

The minimum reproduction protocol is:

1. 1\.runnpm run cava:benchmarkfrom the repository root;
2. 2\.run the CAVA benchmark unit tests;
3. 3\.rebuild the manuscript withlatexmk \-pdf main\.tex;
4. 4\.compare the generated aggregate metrics withbenchmarks/latest\.json;
5. 5\.optionally confirm Azure CLI authentication withaz 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\.

### Appendix ZDisclosure 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

- Cloud Native Computing Foundation \[2026\]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/](https://www.cncf.io/blog/2026/06/11/introducing-verifiable-execution-in-dapr-1-18/), 2026\.
- in\-toto project \[2023\]in\-toto project\.in\-toto: A framework for securing the integrity of software supply chains\.[https://in\-toto\.io/](https://in-toto.io/), 2023\.
- Jimenez et al\. \[2024\]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\.
- Kang and Diponegoro \[2026\]Richard Kang and Yudho Diponegoro\.Governance gaps in agent interoperability protocols: What mcp, a2a, and acp cannot express\.[https://arxiv\.org/abs/2606\.31498](https://arxiv.org/abs/2606.31498), 2026\.
- Langfuse \[2026\]Langfuse\.Llm observability and application tracing\.[https://langfuse\.com/docs/observability/overview](https://langfuse.com/docs/observability/overview), 2026\.
- Liu et al\. \[2024\]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\.
- Microsoft \[2026\]Microsoft\.Agent control specification: Portable runtime governance for ai agents\.[https://commandline\.microsoft\.com/agent\-control\-specification\-runtime\-governance/](https://commandline.microsoft.com/agent-control-specification-runtime-governance/), 2026\.
- National Institute of Standards and Technology \[2024\]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\-intelligence](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence), 2024\.
- Necula \[1997\]George C\. Necula\.Proof\-carrying code\.In*Proceedings of the 24th ACM SIGPLAN\-SIGACT Symposium on Principles of Programming Languages*, pages 106–119, 1997\.
- OpenAI \[2026\]OpenAI\.Frontier governance framework\.[https://cdn\.openai\.com/pdf/e37d949b\-8c9f\-4d76\-b99e\-4272f4631a7e/openai\-frontier\-governance\-framework\.pdf](https://cdn.openai.com/pdf/e37d949b-8c9f-4d76-b99e-4272f4631a7e/openai-frontier-governance-framework.pdf), 2026\.
- OpenTelemetry \[2026\]OpenTelemetry\.Semantic conventions for generative ai\.[https://github\.com/open\-telemetry/semantic\-conventions\-genai](https://github.com/open-telemetry/semantic-conventions-genai), 2026\.
- OWASP GenAI Security Project \[2026\]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/](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/), 2026\.
- Ruan et al\. \[2024\]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\.
- Sigstore \[2024\]Sigstore\.Sigstore documentation\.[https://docs\.sigstore\.dev/](https://docs.sigstore.dev/), 2024\.
- W3C \[2025\]W3C\.Verifiable credentials data model v2\.0\.[https://www\.w3\.org/TR/vc\-data\-model\-2\.0/](https://www.w3.org/TR/vc-data-model-2.0/), 2025\.
- Wang \[2026\]Zexun Wang\.Proof\-carrying agent actions: Model\-agnostic runtime governance for heterogeneous agent systems\.[https://arxiv\.org/abs/2606\.04104](https://arxiv.org/abs/2606.04104), 2026\.