PCAA: Proof-Carrying Agent Actions

We are publishing PCAA because the enterprise AI governance problem is moving from model behavior to action authority. Once agents can deploy code, update records, call tools, initiate payments, or change production state, the old pattern of "human oversight" becomes too vague to operate. A human cannot meaningfully approve an action unless the system can prove which action will run.

PCAA, short for Proof-Carrying Agent Actions, is the governance kernel behind OSuite. It defines a way to transform runtime-specific agent activity into a canonical action object, bind approval to that object, and preserve a replayable proof trail that survives retries, wrappers, and provider changes.

The problem: approval drift

Most approval systems still treat the review screen as the source of truth. The reviewer sees a command, a tool call, or a natural-language summary. They click approve. The runtime then executes something that may have been normalized, retried, wrapped, translated, or partially rewritten.

That gap is approval drift. The organization believes a human approved the action. In reality, the human approved a representation of an action.

PCAA is designed around a stricter requirement: if the consequence changes, the approval must no longer apply.

The canonical action object

PCAA represents an agent action as a structured object with the minimum fields required for governance. The exact schema can evolve by runtime, but the object needs to preserve the semantics that matter to the deployer.

Once the action is canonicalized, approval binds to its fingerprint. A later runtime event can only inherit approval if it still matches the approved consequence.

Why this is deployer-side governance

Model providers can and should maintain safety policies for frontier systems. But the final operational decision often belongs closer to the environment where the action happens. A model provider does not know whether a given repository branch is production, whether a customer record is regulated, whether a payment beneficiary is approved, or whether a deployment window is frozen.

PCAA places final action authority with the deployer. The model can propose. The runtime can request. OSuite can analyze. But the organization that owns the environment decides whether the action is allowed.

What changes in product

In OSuite, PCAA is not a slogan or a compliance label. It changes the control path.

• —A shell command, MCP tool call, SDK call, workflow step, or gateway request becomes a canonical action.
• —Policy and CAVA scoring evaluate that action before it runs.
• —Approval binds to the action fingerprint, not to the UI copy.
• —Closure records whether the action was approved, rejected, blocked, expired, or executed.
• —The result becomes an exportable proof bundle for buyers, auditors, and internal security teams.

Current OSuite path

The deployed product now expresses PCAA as one layer inside a larger runtime path.

PCAA decides who has final governance authority over the action. CAVA turns the attempted agent action into a structured object that policy can judge. BAF turns any approval into a bounded action lease so it cannot be casually reused. AREG maps the resulting agent, runtime, action, and system relationships into a runtime security map.

That product path is what customers feel: what the agent can do, why it can do it, who approved it, whether approval can be reused, and where the impact lands if something goes wrong.

Example

{
  "actor": "coding-agent",
  "intent": "deploy",
  "target": "production/payment-api",
  "privileges": ["repo.write", "ci.deploy"],
  "reversibility": "partial",
  "data_movement": "none",
  "approval_binding": "sha256:canonical-action-fingerprint"
}

This is the level where governance becomes enforceable. Not "the agent wanted to deploy." Not "a human approved something." The object says what was requested, what would change, what authority was used, and what approval applied.

Research status

PCAA is published on arXiv as the first public version of this governance kernel. We expect the schema and runtime adapters to evolve, but the core claim is stable: enterprise agent governance needs approval that binds to canonical consequence.