When AI Agents Ship Code: A Protocol for Verifiable Execution

Last month I merged a bug fix an AI agent wrote. It looked right. The agent said tests passed. I deployed it. Two hours later, production caught fire. Not because the agent was wrong - because I never verified anything. I just trusted it. The problem isn't "can agents do things." It's "can agents prove what they did." Every multi-agent framework today solves the same problem: make agents talk to each other. MCP connects agents to tools. A2A connects agents to agents. LangChain, CrewAI, AutoGen orchestrate the dance. The tooling is incredible. But here's what nobody solved: when agent #2 says "I reviewed the patch" or "tests passed," there's no protocol-level way to verify that claim. Agent #3 just has to trust agent #2. The middleware just has to trust both. You - the human - just have to trust the pipeline. That works in demos. It doesn't work in production. Three questions that kept me up at night When I started digging into this, I kept coming back to three questions: 1. Was this action even authorized? An agent shouldn't be able to just decide to run rm -rf or push to production. Every tool call should carry machine-checkable proof that a specific role said "yes, within scope, within quota." 2. Is there a causal chain from the patch to the test results? If an agent says "I tested the patch and it passed," you should be able to trace backwards: the test run → the patch it tested → the authorization to apply that patch → the work order that started it all. No gaps. No "I swear, bro." 3. Can a third party verify everything without trusting anyone? This is the acid test. If verifying an agent's work requires logging into the agent's machine, reading its logs, and trusting its middleware, then you haven't really verified anything - you've just moved the trust around. A real verification protocol should let an independent party replay the entire evidence chain offline, with nothing but the evidence bundle and public keys. What I built OpenWorkProof is a protocol layer (not a framework) that sits between agents and their tools. It doesn't replace MCP or A2A - it adds accountability on top of connectivity. Here's what happens for every tool call: Step 1: Authorization before execution Before an agent touches any tool, a PolicyDecision is signed: from openworkproof import policy auth_ctx = policy.derive_authorization_context( work_order=work_order, grants=grants, receipts=receipts, request=signed_request, arguments=args, execution_facts=facts, checkpoint=checkpoint, ) decision = policy.authorize_tool_call(auth_ctx) # decision.allowed == False → deny receipt, don't execute Every decision binds: who authorized it (role + Ed25519 key), what tool they authorized, within what scope and quota, and when the authorization window expires. If the agent wasn't authorized? The tool call never happens. Period. Step 2: Signed execution receipt with causal chain Once the tool runs, it produces an ActionReceipt that chains back to the authorization: - Which PolicyDecision authorized it - What evidence it produced (diff, test report, benchmarks) - What quota it consumed - What its parent receipts are (causal graph, not timeline) You can't skip steps. You can't fabricate history. The causal graph enforces exact parent sets - if step 5 claims step 3 as its parent but step 3 never happened, verification fails at the protocol level. Step 3: Offline third-party verification This is the part I'm most proud of. Any third party can replay the entire chain with zero trust: from openworkproof.acceptance import verify_acceptance_bundle result = verify_acceptance_bundle( work_order=work_order, report=report, effective_grants=grants, receipts=receipts, committed_evidence=evidence, acceptance_receipt=signed, public_keys=keys, ) # Pure function. Zero I/O. Deterministic. No database connections. No access to the agent's machine. No trust in any participant. Just the evidence bundle and the public keys. If the chain is internally consistent, it passes. If not, it fails - and tells you exactly where. The six-role model I settled on six roles after realizing that "agent" is too vague for accountability: | Role | Responsibility | |---|---| | Maintainer | Creates the WorkOrder, issues root CapabilityGrant | | Manager | Issues scoped child grants, composes multi-step proofs | | Developer | Executes authorized tool calls, produces ActionReceipts | | Verifier | Independently re-runs tests, cross-checks results | | Sidecar | Assigns trusted execution facts (container ID, SHA, etc.) | | Acceptor | Signs final accept/reject with an external key | Key constraint: grants only attenuate. When you delegate from Maintainer → Manager → Developer, permissions can only shrink, never expand. A sub-grant can't grant more access than the parent had. This is the principle of no-cloning authority - it prevents privilege escalation at the protocol level. The state machine flows: running → locally_verified → proof_ready → awaiting_human → accepted Does it actually work? Two real bugs. I didn't test this on toy examples. I tested it on two real open-source issues: Bug 1: Rich #4196 - terminal formatting Rich is a popular Python terminal formatting library (50k+ stars). Bug #4196 was a rendering edge case. I built a full 9-step evidence chain: WorkOrder → Grant issuance → PolicyDecision → repo_read → apply_patch → run_tests → evidence publication → acceptance bundle → offline verification Every step signed. Every step traceable. Third-party verifier confirmed the chain without touching any live system. Bug 2: Dify #33013 - LLM application platform Different project type entirely - a TypeError in Dify's QuestionClassifierNode. Same protocol worked without modification. This proves the protocol isn't coupled to one kind of codebase, one kind of bug, or one kind of test suite. 2,283 tests. 0 failures. Apache-2.0. Honest limitations (v1.0) This is a protocol, not a product. Here's what it doesn't do yet: - Only repo_read ,apply_patch , andrun_tests have complete handler implementations - other tool types need handler closures - No formal security audit - The Sidecar role still requires manual execution-fact assignment - No hosted verification dashboard (yet) The protocol core is solid. The implementation proves it. The surface area is limited - intentionally, at this stage. Where this fits in the ecosystem There's an interesting dynamic happening in AI agent infrastructure right now: | Layer | What it solves | Who's building it | |---|---|---| | Identity | "Who is this agent?" | Catena Labs, GenLayer | | Connectivity | "How do agents talk?" | MCP, A2A | | Orchestration | "What should agents do?" | LangChain, CrewAI, AutoGen | | Verification | "Did agents do what they claim?" | OpenWorkProof | The verification layer is the one nobody has cracked yet. And it's about to become non-negotiable - the EU AI Act's high-risk provisions are already in effect, requiring provable authorization, constraint, and accountability for AI systems. An analogy I keep coming back to: OAuth defined how humans authorize applications, and that created the Okta/Auth0 market. OpenWorkProof defines how humans authorize AI agents - and verify what they did. Same pattern, different domain. What I'd love feedback on I'm posting this because I want to know if I'm solving a real problem or just the one I hit: - Does the six-role model map to your agent setup, or is it overengineered? - Is offline third-party verification actually useful, or is "trust the middleware" good enough for your use case? - What tool call handlers would you need first - beyond repo_read, apply_patch, and run_tests? I'm not here to sell anything. The project is open-source (Apache-2.0), the repo is public, and I'm genuinely interested in whether other teams are hitting the same verification wall. GitHub: dengyier/OpenWorkProof Interactive demo: 9-step evidence chain for Rich #4196 pip install openworkproof Top comments (0)