The core insight behind BGVD-State is that the integrity of review state matters as much as the discovery of new candidate issues. In a typical AI-assisted review, one model may observe a suspicious pattern, another may attach evidence from a scanner, and a third may render a verdict. If the recipient of a handoff only receives a transcript or a summary, they cannot reliably tell which candidate owns which piece of evidence, whether that evidence is still current, which investigation routes have already failed, or which verification decision controls whether the finding can be reported. Stale, incomplete, or contradictory evidence can slip through, or worse, a candidate’s lifecycle can be silently corrupted across handoffs.

BGVD-State, whose historical name stands for Blackboard-Guided Vulnerability Discovery, draws on an idea that predates modern AI by decades: the blackboard architecture, in which independent knowledge sources collaborate by reading and writing to a shared problem-solving state. The Hearsay-II speech understanding system of 1980 popularized the approach, and recent LLM research has revisited blackboards for multi-agent collaboration. What the new software adds is an explicit evidence chain and a reporting gate. Crucially, BGVD-State is not itself a language model. It is deterministic middleware that sits between event producers, such as agents, tool wrappers, parsers, and human analysts, and state consumers, such as stronger models, reviewers, and reporting pipelines.

The architecture works through typed event records. Every tool call, observation, evidence update, invalidation, or review decision is appended to an event store with a unique identifier, preserving submission order. From these ordered records, the EvidenceLifecycle component derives candidate status, evidence binding, verifier currency, and failed paths. A FinalizationGate then decides whether a candidate may enter a report, returning an allow or reject decision with machine-readable reasons. The whole system enforces five invariants: evidence stays bound to its candidate until explicitly invalidated; a candidate requires current material evidence and a current positive verifier result before reporting; the newest verifier result always governs; rejected routes are carried into later handoff packages so successors do not repeat failed paths; and finalization excludes invalidated or superseded evidence.

Because these rules are enforced by deterministic code rather than by prompts, model forgetting, reinterpretation, or prompt-rule violations cannot alter execution after context compression or a provider change. This is a deliberate design choice with significant implications. When the software version, policy configuration, and event sequence are identical, every client obtains the same lifecycle state and gate decision. Replay validates each event’s structure before appending it, and an event rejected by validation leaves the state unchanged. The middleware does not, however, verify the substantive truth of client-supplied observations; that responsibility remains with the producers and verifiers.

The authors demonstrate the system on a third-party review of fixed public revisions of real open-source projects, including TypeScript, Django, and an elliptic-curve cryptography library. A workflow of 22 event records reconstructed six suspected-risk candidates. Five candidates were rejected along paths whose exclusion reasons are fully recorded within those events. The remaining candidate had a locally reproduced technical observation and an initial positive technical review, but a subsequent security-impact review concluded that the available evidence and tests did not establish a privilege or trust-boundary impact sufficient for reporting. That negative decision was appended as a 23rd event, and after replay, BGVD-State generated a handoff package containing the current states, evidence, and review results for all six candidates, with the complete decision trail preserved for audit.

Reproducibility is treated as a first-class concern. Version 1.2.0, released under the MIT license, runs on Python 3.10 through 3.12 with no runtime dependencies, and no-install reviewer kits are available for Windows x64 and macOS on both Apple Silicon and Intel. The regression suite of 130 tests covers legacy-input normalization, rejected-event state snapshots, and artifact-completeness checks, none of which require an API key or a model call. In a historical performance profile cycling through six fixed synthetic candidates across scales from 100 to 100,000 events, each scale produced a single stable state hash and handoff hash across five repetitions, with median replay time rising from under a millisecond to about 1.34 seconds at the largest scale.

The paper is notably candid about where the approach helps and where it does not. In historical memory-representation studies, a schema-guided state format outperformed matched free-form memory on selected high-pressure continuation fixtures, with a valid-output sensitivity analysis showing six wins, no losses, and 23 ties. But under reduced pressure, with information-equivalent prose, and in a cross-family source-audit setting, the advantage disappeared or reversed, and the authors explicitly present the source-audit result as a tested negative boundary. A token-cost comparison using GLM 5.2 and DeepSeek v4-pro found that a route in which local weaker models handle routine state curation consumed roughly 24,000 strong-model finalizer tokens with no strong-model update tokens, versus nearly 147,000 total strong-model tokens for strong-model curation, with both routes reaching correct final decisions in all 30 runs.

The practical vision is one of composable infrastructure. Orchestration frameworks such as LangGraph can keep workflow checkpoints, and multi-agent systems like AutoGen can coordinate agents and memory, while BGVD-State retains sole authority over security-review state and the reporting gate, presenting the same event, handoff, and gate interfaces to whichever client is attached. Teams can swap models, prompts, retrievers, or tool wrappers without changing the rules that determine which evidence remains current and whether a finding may be reported. A weaker local model can maintain routine state while stronger models or human reviewers receive the current package only when needed.

The authors are careful about the limits of their claims. The applied case used local copies of public repository revisions without interacting with live services, and no candidate is presented as a maintainer-confirmed vulnerability. The middleware implements one deterministic policy family, external clients remain responsible for authenticating event sources, and deployment-level gains in discovery rate, review time, or total cost are not established by the reported checks. Future work points toward multi-writer transactions, cryptographic event integrity, and signed handoff exchange for distributed deployment. Even so, BGVD-State offers something the fast-moving world of AI security agents has lacked: a provider-independent, replayable contract for carrying evidence and state across handoffs, ensuring that when an AI says a vulnerability is worth reporting, the entire chain of evidence behind that claim can be traced, replayed, and trusted.

Subject of Research: Replayable middleware for evidence-gated state handoffs in third-party software security review using AI agents

Article Title: BGVD-State: Replayable middleware for evidence-gated handoffs in third-party software security review

Article References: Lv, Y., & Wang, C. (2026). BGVD-State: Replayable middleware for evidence-gated handoffs in third-party software security review. SoftwareX, 36, Article 103109. https://doi.org/10.1016/j.softx.2026.103109

Image Credits: AI Generated

DOI: 10.1016/j.softx.2026.103109

Keywords: BGVD-State, software security, LLM agents, vulnerability discovery, blackboard architecture, middleware, reproducibility, evidence chain, handoff, open source, cybersecurity, multi-agent systems

The system, called OpenTangYuan, was developed by Mingyang Liu, Wenjuan Wang, Jin Liu, Lele Ouyang, Hanyu Yang and Haifeng Pang and is released under the permissive MIT license. Its central design idea is a strict separation of responsibilities: the external language-model agent does the thinking, while a locally installed runtime does the touching. The runtime, written in C# on .NET 8, exposes REST entry points through which an agent can ask what the machine is capable of, retrieve the parameters of individual skills, and submit structured requests for execution. Every actual operation on files, browsers, email accounts, screenshots, or approved local programs happens inside the trusted local boundary, mediated by the runtime rather than by the agent.

Capability discovery is one of the system’s most elegant mechanisms. Each skill is described in a manifest file that lists its name, its typed parameters, and an invocation example. When an external agent wants to accomplish a task, it first calls a discovery endpoint that returns compact summaries of available workflows and built-in skills. If a stored workflow already matches the request, the agent receives its predefined steps; otherwise it retrieves the detailed schema of the individual skills it needs and composes a temporary multi-step workflow on the fly. This workflow-first approach means that routine, repetitive tasks can be captured once as reusable recipes, while genuinely novel requests can still be assembled from the same typed building blocks.

The built-in skill set reads like a menu of the most tedious chores in academic and office life: searching and organizing files, opening documents, capturing screenshots, driving a browser through Playwright automation, sending and reading email via MailKit, dispatching enterprise messaging notifications, invoking approved local analysis tools, and packaging results for delivery. Intermediate results flow through a shared execution context, so the file path discovered in step one can be reused by the copy operation in step three, and the screenshot captured in step five can be attached automatically by the email step in step six. Developers can extend the system by registering their own manifests and endpoints, turning the runtime into a growing library of locally controlled capabilities.

Security is where the design gets deliberately conservative. The authors are refreshingly candid about what their boundary does and does not protect. The implemented controls include API-key authentication on the agent-facing controller actions, required-argument validation, checks that file operations stay within allowed root directories, allowlists of approved executable names, and observable execution records. What the system explicitly does not provide is process sandboxing, semantic redaction of returned content, or full data-loss prevention. A permitted skill can still return derived text, file paths, or browser page content that crosses the trust boundary as structured output. The authors state plainly that the current release should not be interpreted as offering universal field-level filtering, and they warn that a success flag from the runtime does not by itself prove that an output is correct or free of sensitive content.

To demonstrate that the machinery actually works, the team built a reproducible benchmark of thirteen fixed cases using deterministic local fixtures. Seven cases tested functional and output correctness, judged against observable artifacts such as exact file paths, page output, and SHA-256 hash values. Three cases tested policy enforcement, confirming that invalid arguments, forbidden paths, and unapproved executables are correctly rejected. The remaining three probed workflow context passing and failure semantics, including a missing-source search followed by a failing copy and an unresolved template variable whose absence correctly propagates downstream. All thirteen cases conformed to their predefined oracles, and the distinction between transport status, runtime success, task correctness, and policy conformance proved essential: a rejected request can be the right outcome even though the task did not succeed.

A second evaluation, labeled RS01, exercised a genuine research-support workflow rather than an administrative stand-in. The runtime opened a specified website, retrieved the page title, captured a full-page screenshot into an allowed directory, invoked an allowlisted benchmark tool to compute the screenshot’s SHA-256 hash, and emailed the evidence with the screenshot attached. The hash was independently verified outside the workflow. Across three recorded runs plus one clean replay, all four executions satisfied every predefined check, from page access to attachment presence. The case shows how the same mechanisms that serve office automation can support research evidence collection with locally verifiable integrity.

The most striking quantitative result concerns the value of storing workflows rather than recomposing them from scratch each time. The team ran two fixed tasks, one for office document handling and one for research evidence gathering, in thirty paired comparisons each, with execution order varied to reduce ordering effects. Every one of the 120 executions passed its correctness checks, but the stored workflows were dramatically cheaper: median end-to-end time fell from roughly 49 seconds for ad-hoc composition to 15.5 seconds for stored workflows, and median token consumption dropped from about 24,500 to about 7,600. Wilcoxon signed-rank tests confirmed the reductions were statistically significant, with p-values below 0.001 for both time and tokens in both tasks. Median paired reductions reached 68 percent in time and 70 percent in tokens for one task, and 67.2 percent and 69.5 percent for the other.

Before the formal benchmark, the system also ran a historical pilot at the academic affairs office of the College of Arts and Information Engineering at Dalian Polytechnic University, deployed on a single Windows workstation in April 2026. Over its first ten days the runtime logged 1,061 executions across four task categories, with retained aggregate success rates of 97 percent for file search and copy, 99 percent for browser automation, 100 percent for email processing, and 98 percent for multi-step workflows. The authors are careful to note that these figures rest on runtime-reported status rather than an independent semantic oracle, and that the raw records are no longer retained, so the pilot stands as descriptive evidence of operational feasibility rather than proof of correctness.

The limitations are stated with unusual precision for a software release. The runtime is Windows-oriented, and full desktop functionality has not been evaluated on Linux or in containers. There is no multi-tenant isolation, no centralized cloud service, and no claim of protection against a compromised administrator, stolen credentials, or malicious behavior inside an already approved executable. Prompt injection and semantic exfiltration through permitted outputs remain outside the defended boundary. Yet within those limits, OpenTangYuan makes a compelling argument for a particular architectural pattern in the age of agentic AI: let the language model plan, but let an inspectable, policy-controlled local runtime execute. As institutions grapple with how to give AI assistants real utility without surrendering their data, this open-source execution boundary offers a concrete, benchmarked starting point that others can examine, extend, and deploy on their own terms.

Subject of Research: A policy-controlled local runtime enabling AI agents to safely execute local research-support and office automation tasks on Windows

Article Title: OpenTangYuan: A policy-controlled local runtime for agent-driven research support and office workflows

Article References: Liu, M., Wang, W., Liu, J., Ouyang, L., Yang, H., & Pang, H. (2026). OpenTangYuan: A policy-controlled local runtime for agent-driven research support and office workflows. SoftwareX, 36, Article 103097. https://doi.org/10.1016/j.softx.2026.103097

Image Credits: AI Generated

DOI: 10.1016/j.softx.2026.103097

Keywords: AI agents, OpenTangYuan, local runtime, workflow automation, capability discovery, software security, Windows automation, language models, research support, open source, benchmark evaluation, trust boundary