How OSuite governs agent actions: PCAA, CAVA, BAF, and AREG.

Most AI governance conversations still start in the wrong place.

Research update: 5 October 2026. This working research direction for connecting BAF and AREG is unpublished and not peer-reviewed. This update separates implemented checks from the proposal; the original June publication date is unchanged.

They start with a policy document, a model card, a red-team note, or a dashboard that explains what happened after the fact. Those artifacts matter, but they are not the control path. If an agent is about to push code, update a customer record, export a file, call a payment API, or publish an answer into a production workflow, the useful question is much more direct:

What exactly is the agent trying to do, who has authority over that action, can the approval be reused, and what systems are affected if something goes wrong?

OSuite is built around that path. The research names can sound academic, but their roles are plain: PCAA decides who holds final governance authority. CAVA turns agent activity into a governable action object with canonical identity. BAF turns approval into a bounded action lease. AREG connects runtime exposure evidence and uncertainty rather than promising a complete map of future effects.

The customer does not need to read the papers to get value. They need to see what an agent can do, why it can do it, who approved it, whether that approval can be reused, and where the blast radius lands if the action fails.

The path in one sentence

An agent enters OSuite through a runtime adapter. CAVA canonicalizes the attempted action. The policy profile and Decision Score v2.1 decide whether it can run, should wait, must be escalated, or must be blocked. PCAA assigns final governance authority to the deployer. BAF converts any approval into a non-transferable action lease. AREG maps the action to the runtime, agent, system, boundary, and evidence graph.

That is the difference between an AI dashboard and a control plane. A dashboard shows activity. A control plane changes whether an action can happen.

Why this architecture exists

Enterprise buyers do not struggle because they lack AI principles. They struggle because agent behavior is too close to production state.

A coding agent can modify a repository. A support agent can touch a customer record. A workflow agent can move data between SaaS systems. A procurement agent can draft or trigger external communication. A finance agent can prepare payment steps. Even when the model is safe, the deployment context may not be.

The hard part is that the same action can be low risk in one environment and unacceptable in another. A `git push` into a documentation branch is not the same as a release into a payment service. A file read inside a sandbox is not the same as an export of customer data. A message drafted for internal review is not the same as an outbound statement to a public channel.

Raw action text cannot answer those differences. OSuite therefore treats the action as a structured object with runtime context, policy context, approval context, and proof context.

Layer 1: runtime adapters capture the action before execution

OSuite starts where agents already act. That may be a local shell hook, a Claude Code or Codex workflow, an MCP server, a framework SDK, an API gateway, a managed workflow runner, or a self-hosted automation environment.

The adapter has one job: capture the attempted action before the consequential step executes. Every covered side effect must be mediated before commitment for the control to prevent it. Intercepting only a parent invocation does not establish that its scripts, downstream SaaS calls, or nested-agent actions are mediated. Post hoc detection is not prevention.

It does not need to replace the agent. It does not need to own the model. It does not need to force every customer into one agent framework. Its value is interception and context capture. The adapter sends OSuite enough information to understand who is acting, which runtime lane produced the action, what command or tool call is being attempted, what environment is involved, and what evidence can later be replayed.

That approach matters commercially because customers will mix agent providers. A governance product that only works for one model or one agent runtime becomes obsolete as soon as the customer changes tools. OSuite is meant to sit above that churn.

Layer 2: CAVA turns messy activity into a governable object

CAVA is the semantics layer. It is not a string matcher with better branding.

String matching can be useful as a signal, but it is not enough to govern agent work. CAVA asks what the action means. It separates intent, target, privilege, boundary, reversibility, data movement, runtime identity, policy pattern, and evidence quality.

This is why similar-looking actions should not always receive the same score. CAVA gives policy something real to evaluate.

Layer 3: policy profile and Decision Score v2.1 route the action

The policy profile is the customer's operating boundary. It says what the organization cares about: production releases, regulated data, external messages, customer systems, irreversible operations, money movement, high privilege, or unknown destinations.

Decision Score v2.1 converts that boundary into a product-readable route. It should not feel like a mysterious number. The score is a composed explanation over consequence, authority, reversibility, evidence, and policy match.

The route can be:

• —Allow: the action is low risk, inside the boundary, and evidence-ready.
• —Ask: the action is consequential and needs human approval before execution.
• —Block: the action violates a boundary or lacks enough evidence to run safely.
• —Observe: the action is recorded for posture learning without blocking execution.
• —Escalate: the action touches a sensitive boundary and needs a higher authority path.

This is where OSuite becomes useful to non-engineers. A CISO or operations owner does not want a raw command dump. They want to know why the system thinks the action matters.

Layer 4: PCAA decides final governance authority

PCAA stands for Proof-Carrying Agent Actions. It is the governance kernel behind the product.

The core claim is that approval should bind to the action an agent will actually execute. Not a prompt summary. Not a wrapper string. Not a UI description that can drift from the final command. The action carries proof, and the deployer keeps final authority over actions inside its own environment.

In product terms, PCAA answers:

• —Who is allowed to approve this action?
• —What exactly did they approve?
• —Did the executed action still match the approved action?
• —Can the organization replay the decision later?
• —Does the proof survive provider changes, retries, wrappers, and exports?

PCAA is why OSuite is not just a model-provider safety layer. Model providers can maintain safety policies for their systems. The deployer still owns the production environment, customer records, internal workflow, branch policy, data boundary, and operational risk. OSuite puts final operational authority where the action lands.

Layer 5: BAF turns approval into a bounded action lease

The moment a human approves an action, a new risk appears: reuse.

If approval is just a yes/no flag, the same approval can accidentally cover a changed command, a new destination, a different session, a modified policy version, or a second execution outside the original context. That is how approval drift turns into a security gap.

BAF, the Bounded Action Firewall, rejects invalid approval reuse within a mediated action path. It turns approval into an Action Gate Lease. The lease is valid only within its bound canonical action, policy version, actor identity, runtime session, destination scope, time window, and proof receipt.

The current strict matcher in cava-core's execution-boundary.js checks artifact, configuration, and dependency commitments together with coupled operation, effect, resource, and destination tuples and parameter constraints. It depends on trusted executor observations; it does not discover all possible effects or intercept unmediated ones. Missing or incomplete evidence requires review without dispatch, not an inferred permission.

This is the part a customer can feel. If an agent asks to run a high-risk action and the human approves it, OSuite does not grant a vague power. It grants a bounded lease for that specific action.

An unrelated graph change is not automatically an authorization violation. Safe narrowing is conditional on action identity, lifecycle, authority, and freshness, plus containment within the declared boundary. A narrower effect does not revive an expired, revoked, consumed, or otherwise invalid lease. Changed strict context commitments still fail the equality check; failure to prove a refinement is not itself proof of widening.

Layer 6: AREG makes runtime exposure visible

The Agent Runtime Exposure Graph, or AREG, turns the system from a list of decisions into a security map.

Most organizations eventually ask the same incident question: if this agent goes wrong, where can the damage travel?

AREG connects agents, runtime lanes, actions, tools, systems, accounts, policy boundaries, decision records, leases, and evidence bundles. It helps an operator investigate which agents touch production, which actions cross external boundaries, which runtimes are unverified, and which approvals are reusable or expired. Its exposure claims must stay scoped to the evidence and declared model.

The exposureBounds.js module is research-only: it computes bounds over a finite set of supplied occurrences and declared worlds. Its lower bound can omit certain occurrences; its upper bound can include paths assembled from incompatible candidates. Exactness is conditional on the stated model restrictions, and the module does not establish complete future-program closure.

Missing evidence is not evidence of absence. Receiver-confirmed effects, attempts, admissions, and inferred possibilities remain distinct. A matching fingerprint or receipt association does not establish causal lineage, and an absent graph path does not prove that a physical effect is impossible. These limits matter for both incident review and readiness assessments.

Proposed connection: evidence informs lease validation

PCAA supplies authority, CAVA supplies action identity, BAF supplies bounded authorization, and AREG supplies evidence and uncertainty. The proposed connection would relate state-dependent reachable consequences to lease validation without merging those responsibilities. It is not an implemented complete future-program closure predictor. Prediction never grants permission.

For example, unchanged command text can activate a different downstream workflow when the execution state changes. A future evidence-to-lease connection would need to describe that relevant state, its reachable consequences, and uncertainty, then validate the candidate effect against a still-valid authorization. Neither a prediction nor an observed graph can silently enlarge the lease. Unknown coverage remains a reason to review or constrain execution, not a basis for asserting containment.

The last boundary matters as much as the analysis. A valid admission record does not alone prevent state or authority changes before a receiver commits an effect. Trusted capture, live authority checks, and a final enforcement boundary must cover the actual side effect; otherwise the claim is detection or reconstruction, not prevention.

ZeroGate avoids redundant analysis by preparing an Action Pass earlier, while retaining live revocation checks and durable consumption at admission. Reusing prepared analysis does not mean reusing spent authority or bypassing final validation. This update makes no new performance claim; the ZeroGate reading link above provides the existing measurements and their scope.

Related work already addresses these boundaries

Zhang et al., Section VII already describe Bind-Enforce-Contain, richer labels, and applicability to SaaS and nested-agent settings. Their closure-bound approval work addresses transitive effects beyond the approved invocation; it is not merely an entry-point check.

Formation-Consistent Dispatch (FCD) already addresses typed effects, formation-scoped authority, lifecycle controls, and a final fence connecting the admitted target to execution. These mechanisms provide related-work context for the working proposal.

What the customer sees

OSuite should not ask buyers to care about acronyms first. The acronyms are the machinery. The product surface should answer operational questions.

That is the product path we want customers to remember. OSuite is not another agent UI. It is the runtime governance layer between autonomous action and enterprise consequence.

A concrete example

Imagine a coding agent tries to run:

git push origin main

A basic guardrail might say "git push is high risk" and ask a human to approve it. That is better than nothing, but it is still too blunt.

OSuite asks more:

• —Which repository is this?
• —Is `main` a protected or production-adjacent branch?
• —Does the push trigger deployment?
• —Is the actor a verified agent session?
• —Does the change touch a sensitive service?
• —Is this inside a frozen release window?
• —Can the approval be reused for a later push?
• —Which systems depend on the branch if the action succeeds?

If the action is a harmless docs update, it may be allowed or observed. If it touches production release infrastructure, it may require approval. If the runtime is unsigned, the destination has drifted, or the action cannot be replayed, it may be blocked or escalated.

The important part is that OSuite produces a record the buyer can understand later. The decision is not "bash command was 25/100." The decision is "this production-adjacent write required approval; approval was granted by the deployer for this fingerprint, this session, this policy version, and this time window; the proof receipt closed after execution."

Why this matters for sales and security review

Enterprise security buyers are skeptical for good reasons. They have seen dashboards that look clean but do not stop anything. They have seen policies that sound responsible but do not bind to runtime behavior. They have seen model-provider promises that do not map cleanly onto customer systems.

OSuite should be judged on a stricter standard:

• —Can it intercept consequential actions before execution?
• —Can it explain action meaning without relying on raw strings?
• —Can it route decisions through the customer's authority model?
• —Can it prevent stale approvals from being reused?
• —Can it show blast radius across real runtime relationships?
• —Can it export proof that a buyer, auditor, or internal security team can read?

If the answer is yes, the product has moved beyond AI governance theater. It becomes runtime security infrastructure.

Where the research fits

PCAA, CAVA, BAF, and AREG are not separate products customers must assemble. They are layers in one OSuite path.

PCAA defines final governance authority and proof-carrying approval. CAVA provides canonical action identity. BAF enforces bounded authorization with explicit lifecycle checks. AREG makes exposure evidence and uncertainty visible. Decision Score v2.1 and the policy profile sit across the middle so the customer can tune how the system routes actions, without letting a prediction grant authority.

The research informs the product, but a proposed connection is not a deployed guarantee. Current context/effect checks, finite-world reconstruction results, and future pre-commit integration have different evidence obligations.

That is the standard we are building toward: agent governance that is visible before execution, enforceable at approval time, bounded after approval, and explainable after the fact.