30-Second Overview
MCP connects agents to tools. A2A connects agents to agents. AgentTeams orchestrates agent collaboration.
But when an agent says "I'm done," no existing layer answers:
- What authorization backs this work?
- Did every step stay within scope and quota?
- Do tests, patches, and reports form a complete causal chain?
- Who has the authority to accept or reject the outcome?
- In a dispute, can a third party verify all the facts offline, without connecting to any party's system?
OpenWorkProof fills this gap: contracts, authorization, evidence, and acceptance for agent work.
It doesn't try to make agents smarter. It makes their work authorizable, constrainable,
verifiable, and acceptable — and rejectable when the evidence falls short.
A contrarian thesis: the primary bottleneck for multi-agent systems isn't model capability
— it's accountability, authority, evidence, and acceptance. Without these, agents can
generate results, but they can't become delegatable, auditable, billable production actors.
Why OpenWorkProof
Who Needs It
| Role | Pain Point | What OpenWorkProof Provides |
|---|---|---|
| Agent platform / framework builders | Agents can call tools, but can't prove "this call was authorized" | Signed AgentRequest + PolicyDecision pre-authorization — every call carries machine-checkable authorization evidence |
| Enterprise IT / compliance teams | EU AI Act high-risk provisions require proof that agents are authorized, constrained, and auditable | Complete signed authorization chain, quota tracking, offline third-party verification for audit requirements |
| Multi-agent orchestrators | Delegated permissions can't decay or be held accountable | CapabilityGrant with atomic attenuation — child grants can only shrink, never expand |
| Delivery reviewers / acceptors | Agent claims completion but the causal link between tests, patches, and reports is opaque | Causal replay layer + policy replay layer + five-input offline verifier — the full evidence chain is reproducible |
| Dispute arbitrators | Need to review facts without connecting to any party's system |
validate_grant_chain — pure offline signature verification, only needs the evidence bundle + public keys |
Why Now
The market has turned. Gartner predicts 40% of enterprise software will embed AI agents
by end of 2026 (below 5% in 2025). The EU AI Act's high-risk provisions are already in effect
— organizations that can't prove their agents are "authorized, constrained, and auditable"
face real legal risk.
The space is being validated by capital. In H1 2026, over $65M was publicly raised in
the agent trust infrastructure category:
| Project | Funding | Layer |
|---|---|---|
| Catena Labs | $48M (a16z-led) | Agent identity + payment protocol |
| GenLayer | $7.5M | Verifiable judgment + on-chain identity |
| OpenBox AI | $5M | Runtime governance (identity/authorization) |
| t54 Labs | $5M (Franklin Templeton / Ripple) | Agent financial trust layer |
These projects solve "who is acting" and "how money moves" — the identity and payment layers.
OpenWorkProof solves the layer they all leave untouched: what authority backs this work,
why the process is trustworthy, and what makes the outcome acceptable — the work-contract layer.
The two are complementary, not competitive.
An analogy: OAuth defined "how humans authorize apps," spawning a $10B+ market
(Okta / Auth0). OpenWorkProof defines "how humans authorize agent work and accept results."
Core Principles
- Proof-Carrying Work: actions must carry machine-checkable authorization and result evidence
- No-Cloning Authority: child grants can only attenuate or consume — never replicate equivalent or greater permissions
- Multi-Scale Proof Composition: local credentials can only form an acceptable global proof when causality, evidence dimensions, correlation disclosure, and global conditions are simultaneously satisfied
- Fail Closed: unverifiable permissions, signatures, history, state, or evidence must never resolve as success
-
Offline Third-Party Verification:
validate_grant_chainenables third parties to verify the entire signed authorization history without connecting to any party's system
Top comments (7)
The useful boundary is acceptance, not completion. A patch, report, or agent run should ship with the claim it is making, the authority it used, and the evidence that would falsify it. Otherwise the buyer is just purchasing confidence from a black box.
Exactly. "Acceptance, not completion" is the design principle behind OpenWorkProof.
Every agent tool call ships with three things, exactly as you described:
Without all three, you're right: the "buyer" is just purchasing confidence from a black box. We're trying to turn that black box into a glass box.
Glass box is the right ambition. The hard part is deciding who pays the verification cost when the output is cheap and the evidence chain is expensive. My hunch is that it works first where the buyer has a real audit loss, not where the demo only needs to look convincing.
Dean — you nailed the commercial question. The evidence chain is indeed more expensive than the output itself, and that's why the protocol is designed to make verification cost as close to zero as possible.
The signature cost is trivial: Ed25519 signing is a few milliseconds. The real cost is interpretation — someone has to look at the evidence chain and decide if it's valid. That's what kills most audit trails.
The design bet is: the receipts are generated in a canonical format (JCS) so any third party can verify them offline with just a public key. No API calls, no infrastructure, no trust in the execution node. The "expensive" part isn't the bytes — it's the human time of manual audit. If verification becomes a replay that outputs yes/no, the cost collapses.
Your hunch about "real audit loss" aligns perfectly with what I'm seeing. Two scenarios where the buyer's loss is concrete:
Regulatory compliance — EU AI Act high-risk systems require "human oversight and traceability." The penalty isn't just reputational; it's regulatory action. The evidence chain becomes the compliance artifact.
Multi-agent handoffs — When one agent's output is another agent's input, the downstream agent needs to know what it was authorized to do. The "audit loss" is a cascading failure where an unverified upstream action propagates through the chain.
The "demo only needs to look convincing" scenario is the opposite — and you're right that it won't pay. That's where the market signal becomes useful: if a use case doesn't care about provability, OWP adds overhead with no value. The protocol should only be applied where the absence of proof has a cost.
Curious: are you thinking about this from a product or infrastructure angle? Your framing suggests you've seen the gap between "demos that ship" and "systems that get audited."
Great question about authority in agent interactions! It's a key challenge in multi-agent systems. To clarify: MCP standardizes tool access, while A2A handles agent-to-agent communication, but neither fully addresses trust or verification of outputs. In practice, you'd need to define authority through mechanisms like signed outputs, audit trails, or human-in-the-loop approvals. By the way, I build PureHub, a free, open-source collection of tools that includes some agent-related utilities—if you're exploring this space, it might offer some practical examples. But to your point: what specific authority model are you considering for accepting agent-generated results?
Really appreciate the clear breakdown on MCP and A2A — completely agree both solve connectivity without touching verification.
On authority models: I've been approaching it as role-based cryptographic authorization. Each tool call carries an Ed25519-signed decision from a specific role (Manager, Developer, Verifier, etc.), and the execution receipt bundles a causal evidence chain (RFC 8785 JCS) that any third party can replay offline.
The key design bet is that verification should happen at the protocol layer, not just the audit-trail layer. Audit trails are post-hoc — "let's check what happened." Protocol-level verification is "the receipt is the proof." The difference is the cost of running verification: audit trails require manual interpretation; signed evidence chains let you just replay and get a yes/no.
Human-in-the-loop and signed outputs are definitely part of the picture, but the goal is to make the verification itself so cheap that the human's job shrinks to confirming an already-mathematically-valid chain, not manually auditing from scratch.
PureHub sounds like an interesting angle — signed outputs + structured audit is a solid foundation. I'll check it out. Curious: have you explored offline or third-party verification, or is your approach more focused on the in-the-loop approval flow?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.