{"slug": "why-openworkproof-returns-unknown-for-a-signed-soc-review", "title": "Why OpenWorkProof returns UNKNOWN for a signed SOC review", "summary": "The OpenWorkProof project released version 1.6.1, which packages a reference SOC alert-review workflow exposed through an MCP server with 32 tools, including three for the review loop: owp_soc_sample_alerts, owp_soc_analyze_slips, and owp_soc_verify_bundle. The workflow reviews synthetic Slips alerts, produces review cases, human-review flags, and a serialized evidence bundle, and returns UNKNOWN from verification when the recipient lacks independent trust inputs. The release is a reference implementation with simulated action effects, and the project notes that a production SOC, real host remediation, and OS isolation require separate deployment.", "body_md": "Run a synthetic alert review, export its evidence, and ask a verifier to check it. If the result is `UNKNOWN`, has the workflow failed?\n\nWith 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.\n\nThe 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.\n\nOpenWorkProof 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.\n\nThree names describe different responsibilities:\n\n| Component | What it does in the reference workflow | \n|---|---|\n| AI-SOC | Reviews supplied alert records and preserves uncertainty that needs further investigation or human review. | \n| AI Sandbox | Provides a reference path for checking requested actions before simulated execution. | \n| OWP | Records the workflow and supports verification of the exported evidence. | \n\nThe user-visible flow is:\n\n```\nSynthetic or authorized alert input\n             |\n             v\nReview summary and evidence bundle\n             |\n             v\nRecipient verification\n             |\n             v\nFindings for the human reviewer\n```\n\nThis 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.\n\nFor 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.\n\nYou need Python 3.10+, `uv`/` uvx`, and an MCP-capable client. For a client using the common `mcpServers` configuration shape:\n\n```\n{\n  \"mcpServers\": {\n    \"openworkproof\": {\n      \"command\": \"uvx\",\n      \"args\": [\"--from\", \"openworkproof==1.6.1\", \"owp-mcp\"]\n    }\n  }\n}\n```\n\nUse 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](https://github.com/dengyier/OpenWorkProof/blob/ee60496e8ac28e82fe415c32c7bdb4278d8f4072/MCP_SERVER.md) covers the client-specific setup.\n\nThe local server exposes 32 tools. These three form the SOC review loop:\n\n| Tool | Purpose | \n|---|---|\n| `owp_soc_sample_alerts` | Obtain the bundled synthetic alert example. | \n| `owp_soc_analyze_slips` | Review supplied alerts and return cases with an evidence bundle. | \n| `owp_soc_verify_bundle` | Check the serialized evidence bundle under the supplied trust inputs. | \n\nThe 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.\n\nStart with the synthetic sample. It does not require access to a production system. After connecting MCP, give your agent a concrete task:\n\nCall `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.\n\nFor a repeatable procedure, the optional SOC Review Skill documents the same workflow:\n\n```\nnpx skills add dengyier/OpenWorkProof --skill openworkproof-soc-review\n```\n\nThe Skill provides instructions for using the tools. Configure MCP separately. Installing either one does not activate the separate Codex Guard integration.\n\nBefore 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](https://github.com/dengyier/OpenWorkProof/blob/ee60496e8ac28e82fe415c32c7bdb4278d8f4072/docs/integrations/soc-reference.md) for the supported input format and size limits.\n\nThe verification result answers a narrower question than whether a security decision is correct.\n\n| Result | Interpretation | \n|---|---|\n| `UNKNOWN` | The available inputs do not establish everything required for the stated verification scope. Read the accompanying findings. | \n| `FAILED` | The verifier found invalid or inconsistent evidence within its checks. | \n| `VERIFIED` | The specified checks passed under the supplied trust inputs. A human still decides whether to accept the result. | \n\nThe 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.\n\nThe 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.\n\nThere 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.\n\nOWP 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.\n\nThe 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](https://github.com/dengyier/OpenWorkProof/blob/ee60496e8ac28e82fe415c32c7bdb4278d8f4072/docs/integrations/agent-guard-onboarding.en.md) 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.\n\nThe 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.\n\nFor the documentation and attribution update in [PR #13](https://github.com/dengyier/OpenWorkProof/pull/13), the [portable CI run](https://github.com/dengyier/OpenWorkProof/actions/runs/42535935246/job/128900107548) 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.\n\nThe [public repository](https://github.com/dengyier/OpenWorkProof) 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.\n\nProject contributors: **dengyier & Tim Shing（成孝添）**. Tim's GitHub handle is `alphatin123`. OWP Core uses Apache-2.0; Tim's contributed `aisoc` component uses MIT.\n\n*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.*\n\nSee you in Beijing on November 14 for the finals of the “全球人工智能·创新·治理·安全大赛” (Global Artificial Intelligence Innovation, Governance & Safety Competition)!", "url": "https://wpnews.pro/news/why-openworkproof-returns-unknown-for-a-signed-soc-review", "canonical_source": "https://dev.to/dengyier/why-openworkproof-returns-unknown-for-a-signed-soc-review-552f", "published_at": "2026-11-09 02:16:26+00:00", "updated_at": "2026-11-09 02:24:25.136877+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "agent-protocols", "ai-safety", "developer-tools"], "entities": ["OpenWorkProof", "AI-SOC", "AI Sandbox", "OWP", "Slips", "VS Code", "Codex Guard"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/why-openworkproof-returns-unknown-for-a-signed-soc-review", "markdown": "https://wpnews.pro/news/why-openworkproof-returns-unknown-for-a-signed-soc-review.md", "text": "https://wpnews.pro/news/why-openworkproof-returns-unknown-for-a-signed-soc-review.txt", "jsonld": "https://wpnews.pro/news/why-openworkproof-returns-unknown-for-a-signed-soc-review.jsonld"}}