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

Most AI governance conversations still start in the wrong place.

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 the product promise is intentionally plain: PCAA decides who holds final governance authority. CAVA turns agent activity into a governable action object. BAF turns approval into a bounded action lease. AREG turns agent, runtime, action, and system relationships into a runtime security map.

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.

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, prevents that pattern. It turns approval into an Action Gate Lease. The lease is valid only for the canonical action, policy version, actor identity, runtime session, destination scope, time window, and proof receipt it was issued for.

The invariant is simple: if the consequence changes, the approval no longer applies.

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.

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 makes blast radius visible. It helps an operator see which agents touch production, which actions cross external boundaries, which runtimes are unverified, which approvals are reusable or expired, and which systems would be affected by a failure.

This is not only an incident feature. It is also a readiness feature. Before scaling agents across a business unit, a customer can see whether the runtime map is narrow and controlled or wide and ambiguous.

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 the canonical action object. BAF enforces bounded, non-reusable approval leases. AREG makes the runtime security map visible. Decision Score v2.1 and the policy profile sit across the middle so the customer can tune how the system routes actions.

The research matters because it gives the product a spine. The product matters because it turns the research into a path a customer can use on Monday morning.

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.