OpenWorkProof Update: What We’ve Shipped—and What You Can Verify Today

My last update here was on August 25. Since then, OpenWorkProof Core 1.4.0 and our first DeepSeek Harness plugin have shipped. I owe readers a concrete account of what is available and how to check it.

If you are new to the project, OpenWorkProof connects an agent's work order, delegated authority, execution evidence, verification, and final acceptance. The aim is to let someone outside the originating system inspect the evidence behind a delivery.

For this update, I'll start with the packages, then give you two small checks you can run yourself.

What has shipped

As of September 9, 2026:

The main addition since the 1.3.0 update is a packaged Harness integration. Human Agency profiles and offline evidence verification were already part of the project; the examples below show how to inspect those capabilities with the released Core package.

A documentation correction: some Core documentation still describes the plugin as unpublished. The npm release is now available at the link above.

What the Harness integration adds

Consider a coding task where an agent may read a repository, apply a bounded patch, and run agreed tests. The patch, test result, and final delivery need to refer to the same authorized work.

The plugin brings that workflow into DeepSeek Harness with two operating modes:

• Audit records observations from the tool pipeline. An observation of an action is not retroactive authorization for it.
• Enforce blocks the known native mutation tools and routes consequential work through owp_apply_patch and owp_run_tests, with authorization checks before execution.

The installed plugin starts disabled. After explicit configuration, Audit is the default operating mode; Enforce requires an explicit choice. The tested host version is DeepSeek Harness 0.1.1-rc.2.

The integration also provides commands to inspect evidence, request verification of the correlated patch receipt, and export a package for offline review. The designated Acceptor signs acceptance separately, with their private key outside Harness.

The important distinction remains:

VERIFIED ≠ ACCEPTED

A technical verification result does not give the agent authority to accept its own delivery.

This is a community integration with a specific trust boundary: it depends on the Harness host, plugin, and bridge. It is not an operating-system sandbox. A compromised host or execution outside the observed pipeline needs separate controls and evidence. See the integration documentation for setup and limitations.

Check 1: inspect a signed human authorization boundary

Use Python 3.12 and Git for these examples. The commands below are for a POSIX shell. Pin both the source examples and installed package to the release:

git clone --depth 1 --branch v1.4.0 \
  https://github.com/dengyier/OpenWorkProof.git
cd OpenWorkProof
python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install "openworkproof==1.4.0"

python examples/human_agency_profile_v01.py

Relevant output:

profile verified  : True
resolved status   : active
owp.repo_read     : delegated -> allowed
owp.apply_patch   : reserved -> AGENCY_HUMAN_DECISION_REQUIRED

The example creates temporary keys in memory, signs a work order and a human agency profile, verifies the profile, and distinguishes a delegated read from a patch decision reserved for a human.

It is a small protocol demonstration. It uses a fixed demonstration time and a local classification helper; it does not dispatch a real patch or establish that every route through a runtime is protected. That stronger claim needs integration testing.

Check 2: verify an evidence bundle, then damage a copy

From the same checkout and environment:

python tests/evidence-bundles/verify_evidence_bundle.py \
  tests/evidence-bundles/rich-4196-integrity-v05-delivery-package.json

This uses a project-owned reproduction based on Rich #4196. It is an existing Verification Integrity v0.5 fixture, included here so readers can check it with Core 1.4.0. The fixture version and package version identify different things.

After installation and download, this verification does not require the original live ledger or a model API. It checks the supplied package under the fixture's verification rules. It does not rerun Rich's test suite or establish that the upstream project adopted OpenWorkProof.

Now change one byte in an embedded file, leaving its declared digest unchanged. This writes a separate copy:

python - <<'PY'
import base64
import json
from pathlib import Path

source = Path(
    "tests/evidence-bundles/"
    "rich-4196-integrity-v05-delivery-package.json"
)
bundle = json.loads(source.read_text())
item = bundle["files"][0]
payload = bytearray(base64.b64decode(item["payload_b64"]))
payload[0] ^= 1
item["payload_b64"] = base64.b64encode(payload).decode("ascii")
Path("tampered-bundle.json").write_text(json.dumps(bundle))
PY

python tests/evidence-bundles/verify_evidence_bundle.py \
  tampered-bundle.json

The original should pass. The damaged copy should fail with v0.5 envelope file hash mismatch and exit code 1.

For this article, we reran both examples on September 9 in a fresh Python 3.12 environment with Core 1.4.0 and the release-tagged example files. The profile demonstration passed. The original bundle returned VERIFIED and READY_FOR_ACCEPTANCE, with exit code 0; the damaged copy failed with the error and exit code above.

That is a deliberately narrow negative check: it demonstrates rejection of an altered payload with a stale digest. It does not establish resistance to every forgery or prove that the original business judgment was correct. Further checks need to challenge signatures, authority, causal bindings, and the verifier's assumptions.

Where I want outside help

The next useful step is reproduction by people who did not build the integration. The released packages are available; production adoption and external acceptance need their own evidence.

If you build an agent runtime, an MCP tool server, or a permission-checking component, I'd like to test one bounded execution path together:

• Can the arguments or scope change after authorization?
• Can an alternate path reach the underlying function without the required decision?
• Can an old or unrelated receipt support a new delivery claim?
• Can another person verify the exported evidence without access to the originating system?

There may be useful integration points between an execution-time guard and OpenWorkProof's work contracts and evidence. I'd rather establish those through a working example than assume compatibility from our descriptions.

For a joint test, I'd like us to publish the method and reproducible results, credit each contributor and project, and link the relevant code. Both successful defenses and failures are worth documenting. Vulnerability details should be coordinated privately before publication.

Start with OpenWorkProof or the Harness plugin. If an example fails, an issue with the version, command, and sanitized output would help. For exploitable vulnerabilities, use private security reporting.

Which tool execution path would you bring to a test like this?