Run a synthetic alert review, export its evidence, and ask a verifier to check it. If the result is UNKNOWN, has the workflow failed?

With OpenWorkProof, the answer depends on what the recipient has supplied for verification. An exported bundle can contain consistent records while the recipient still lacks independent information about whom to trust.

The current OpenWorkProof 1.6.1 package provides a small example of this distinction through MCP. This post uses its published tools and a synthetic sample to explain what a developer can try today and how to read the result.

What is available now

OpenWorkProof helps developers review an agent's recorded work and check exported evidence. The SOC reference workflow extends that to supplied Slips alerts. It produces review cases, human-review flags, and an evidence bundle that can be passed to a verifier.

Three names describe different responsibilities:

Component What it does in the reference workflow
AI-SOC Reviews supplied alert records and preserves uncertainty that needs further investigation or human review.
AI Sandbox Provides a reference path for checking requested actions before simulated execution.
OWP Records the workflow and supports verification of the exported evidence.

The user-visible flow is:

Synthetic or authorized alert input | v Review summary and evidence bundle | v Recipient verification | v Findings for the human reviewer

This release provides a reference implementation with simulated action effects. An actual production SOC, real host remediation, and operating-system isolation require a separate deployment. That scope matters when interpreting a demonstration.

For an engineer evaluating agent-assisted alert review, the useful output is a review artifact another person can inspect. The person receiving it can see which findings need attention and what the verification result supports.

Connect the published MCP server

You need Python 3.10+, uv/uvx, and an MCP-capable client. For a client using the common mcpServers configuration shape:

{ "mcpServers": { "openworkproof": { "command": "uvx", "args": ["--from", "openworkproof==1.6.1", "owp-mcp"] } } }

Use your client's documented configuration file and reconnect after saving. Some clients, including VS Code, use a different top-level configuration key. The MCP setup guide covers the client-specific setup.

The local server exposes 32 tools. These three form the SOC review loop:

Tool Purpose
owp_soc_sample_alerts Obtain the bundled synthetic alert example.
owp_soc_analyze_slips Review supplied alerts and return cases with an evidence bundle.
owp_soc_verify_bundle Check the serialized evidence bundle under the supplied trust inputs.

The SOC tools arrived in 1.6.0 and remain available in 1.6.1. The example here pins the package version so that the instructions have a clear reference point.

Try one complete review

Start with the synthetic sample. It does not require access to a production system. After connecting MCP, give your agent a concrete task:

Call owp_soc_sample_alerts, then review its alerts_jsonl with owp_soc_analyze_slips. Pass the returned serialized bundle to owp_soc_verify_bundle. Explain the cases, human-review flags, simulated actions, and missing trust inputs. Keep UNKNOWN when independent trust information is absent. Do not operate a real host.

For a repeatable procedure, the optional SOC Review Skill documents the same workflow:

npx skills add dengyier/OpenWorkProof --skill openworkproof-soc-review

The Skill provides instructions for using the tools. Configure MCP separately. Installing either one does not activate the separate Codex Guard integration.

Before using your own alert exports, check that you are authorized to share them with the selected MCP client. Alert-derived material can become part of its model conversation. Use the SOC integration guide for the supported input format and size limits.

Read UNKNOWN as a finding

The verification result answers a narrower question than whether a security decision is correct.

Result Interpretation
UNKNOWN The available inputs do not establish everything required for the stated verification scope. Read the accompanying findings.
FAILED The verifier found invalid or inconsistent evidence within its checks.
VERIFIED The specified checks passed under the supplied trust inputs. A human still decides whether to accept the result.

The recipient needs independently obtained trust information. A key supplied inside an untrusted bundle cannot, by itself, establish that the sender is the identity the recipient expected. Making the output green by trusting whatever came in the same bundle defeats that distinction.

The documented first-run example expects UNKNOWN when independent trust inputs are absent. Read that result together with its findings and verification scope. It does not measure production detection accuracy.

There is also a detection case state called UNKNOWN. It concerns uncertainty in the alert assessment. The verifier's UNKNOWN concerns its evidence and trust requirements. Keep the producing component, findings, and human-review flags with the status, so that these two decisions stay distinguishable.

Codex Guard is a separate entry point

OWP Guard is an experimental workflow for supported Codex text edits inside a designated preview directory. It needs its own project setup, personal scope review, a live allow/block probe, and a readiness check before a guarded run.

The recorded real-host baseline is macOS, Python 3.12, and Codex CLI 0.147.0, from the Guard work introduced in 1.5.0. Follow the English first-run guide and check compatibility in your own environment. This workflow covers a bounded preview-editing task; it does not establish whole-computer protection or support for arbitrary deployment actions.

Release and project evidence

The published package is 1.6.1. Recent documentation work makes the English and Chinese entry points clearer, and the source and newly published Skill bundles now carry explicit contributor attribution. The MCPRush Skill revision is 1.0.1; that revision updates attribution without changing the review procedure.

For the documentation and attribution update in PR #13, the portable CI run for commit 8d5ae4d recorded 4,754 tests passed and 23 skipped. A separate GitHub Action fixture smoke check also passed. These are engineering results for that commit, rather than evidence of customer deployment or a security certification.

The public repository contains the implementation, guides, and tests. The next useful check for a developer trying the sample is whether they can explain the returned findings and distinguish verification from a human acceptance decision.

Project contributors: dengyier & Tim Shing（成孝添）. Tim's GitHub handle is alphatin123. OWP Core uses Apache-2.0; Tim's contributed aisoc component uses MIT.

AI disclosure: This article was primarily drafted by an AI agent using public project sources and a local synthetic check of the published package. It is published on behalf of the OpenWorkProof account holder.

See you in Beijing on November 14 for the finals of the “全球人工智能·创新·治理·安全大赛” (Global Artificial Intelligence Innovation, Governance & Safety Competition)!