DOUBLEGATE
Menu

Evidence

Every finding, with its source.

Read the finding. Check what it actually supports.

Published research documents the problem. Anyone can check the gate’s rules against what we publish, on their own gate.

Read the primary sources

Research behind the problem

Individual AI access changed time use, not the mix of tasks

A six-month randomized field experiment covered 66 firms and 7,137 knowledge workers. It added a generative AI tool to the email, meeting and writing applications they already used. The 80% of treated workers who used it spent two fewer hours a week on email in the experiment's second half. They also did less work out of hours. Apart from those individual time savings, the authors "do not detect shifts in the quantity or composition of workers' tasks resulting from individual-level AI provision".

What we use it for: telling time saved by one person apart from a change in how work is organized. The World Economic Forum's September 2026 piece frames the same result as the "single-player" phase of workplace AI. Knowledge shared between agents is the second kind of change, the one doublegate offers, and its effects need their own measurement.

Study scope: the tool tested was an office assistant. The experiment did not evaluate shared agent memory. It did not establish why task patterns stayed unchanged.

Dillon, Jaffe, Immorlica & Stanton, "Shifting Work Patterns with Generative AI", AER: Insights (forthcoming)

Meta built a reviewed institutional knowledge system

Meta's "organizational second brain" uses adversarial review by an agent that shares no context with the author. Its validation passes or fails rather than scoring. A human expert signs off, and the audit trail is complete. Meta's engineers write that they "haven't seen this level of validation rigor applied to a structured knowledge base without model retraining". They describe the output as "permanent, compounding institutional memory".

What we use it for: a team independent of us built a way to turn expert corrections into reviewed knowledge updates. The article evaluates Meta's system, not doublegate, and it is not a market survey.

Meta Engineering, 2 September 2026

Two of fourteen memory providers can hold changes for review

Of the fourteen memory providers we surveyed in September 2026, two offer a review step before what an agent writes is final. Since version 3.14.0, Mnemosyne can hold everything written until it is approved. Byterover holds back two kinds of change from the rest of the team: a deletion, and a change its own curation agent rates high-impact. The author's own queries already see the change. In both, the agent that wrote a change can approve it, and neither records the decision as a signed event.

What we use it for: holding back what an agent writes is no longer rare. The difference left is who may approve, and whether the decision is signed. We read both providers' own documentation on 2026-10-06. The survey of the fourteen is our own.

Mnemosyne v3.14.0 release notes, "Write-Approval Gate" Byterover documentation, "Review Changes" Our survey of fourteen providers — method and per-provider notes available on request

More than a third of public agent skills had a security flaw

A skill is a set of instructions, sometimes with scripts, that changes what an agent does. Of 3,984 public agent skills scanned, 36.8% had at least one security flaw and 13.4% a critical one. The scan confirmed 76 malicious payloads, 8 of them still live when the study was published. Of the malicious ones, 91% paired prompt injection with conventional malware. The barrier to publishing a skill was a single file and a git repository.

What we use it for: why a skill is held, scanned and reviewed like anything else an agent writes, instead of going straight into use.

Snyk, ToxicSkills

Packed skill malware got past every scanner tested

The authors took 1,613 malicious skills found in the wild and packed each one. Packing hides the payload when the skill is installed and restores it when the skill runs. They tested eight scanners: six that inspect a skill without running it, and two that ask a language model to judge it. The packed skills got past every one more than 90% of the time, with the two model judges tried on a random 100 of the skills. Disguising the payload's code, instead of packing it, got past most of the six non-running scanners more than 80% of the time. The authors' own answer was to run each skill in a sandbox and watch what it does. It detected 97% of attacks at a 2% false-positive rate.

What we use it for: the gate's grading model reads a skill as it would be installed. That is the same kind of check as the two model judges the packed skills got past. So a grade of a skill proves no more than the scan does. Both hold a skill for review and never prove it safe, and review is not permission to run it.

Ji et al., "Cloak and Detonate: Scanner Evasion and Dynamic Detection of Agent Skill Malware", arXiv 2607.02357, July 2026

Public registries exclude curation by design, and say so

The official registry of the Model Context Protocol, the standard agent-tool protocol, publishes its design principles. In them it commits itself to "no built-in ranking, curation, or quality judgments" and to "avoid features that require constant human intervention or moderation". Its ecosystem document expects that role to be filled by "subregistries [that] add value […] by providing curation".

Hugging Face, the most mature artifact registry in AI, scans uploads and states: this is not 100% foolproof. It is your responsibility as a user to check if something is safe or not. We are not actively auditing python packages for safety.

What we use it for: by their own design, the registries leave review to whoever installs, for stated reasons: operational cost, vendor neutrality and liability. Whoever reviews instead carries those costs.

The registry's published design principles and its ecosystem vision, for the subregistry role Hugging Face, Pickle Scanning

A correction we made to our own case

Much published material states that BCBS 239 requires data lineage. We searched the full 2013 text: zero occurrences of "lineage", "provenance", "traceability" or "audit trail". The document requires reconciliation with source systems, and striving toward "a single authoritative source for risk data per each type of risk". That is a different requirement from a lineage mandate, and a weaker one.

The lineage requirement is real. It lives in the ECB's 2024 implementation guide. The guide states lineage must let a bank "track back the source of the issue in a timely manner" and "allow traceability for (external) validation". That is the document we cite.

Why this is here: a bank's risk and compliance function, its second line of defence, is paid to catch borrowed authority. Quoting the better-known document as a lineage mandate is that kind of borrowed authority. We would rather lose the stronger-sounding citation than be caught using it.

ECB Guide on effective RDARR, 3 May 2024

Each rule, and how to check it

The gate, the doublegate service on the operator’s machine, enforces five rules on each claim, one thing written down for reuse. Each row says how, how anyone can check it from what we publish, and any limit on one machine. The checks are for whoever runs the gate.

RuleHow the gate enforces itHow to check it
The reviewer is never the author. Before a promotion counts a signature, the gate drops any signer who is the claim's author, whether an agent, a person or the operator. In the console, the author sees Refused: the claim's author cannot sign it where Sign would be. If an agent starts as the gate's own operating-system user, its shell can promote what its session wrote (how to prevent that). Run the agent as another operating-system user and the rule holds against it. A gate that runs under a service user of its own is on the roadmap. No method an agent-role API key can call promotes, signs, rejects, demotes or hides, and no method at any role deletes. The published method catalog names the role each method needs: an agent-role API key reaches 37 of 83. The role table on the engineers' page counts every role.
Other agents can find a claim once it is signed. Recall, the gate's search, returns promoted claims, then the asker's own held claims after them, marked held. Claims by other authors that are still held are not searched. Unless the operator requires a person, both signatures a promotion needs come from one grading model, which reads each claim twice: once for it and once against. By default an agent recalls from its own work area, then each area above it. Recalling across the space searches every work area in it. Have one agent remember a claim, then recall across the space with another: the claim is absent until it is promoted. When its author recalls it, the answer carries the held mark, a field of every recall hit in the published OpenAPI.
Every decision is signed and kept. Each claim written, and each promotion, rejection and demotion, is an event in the journal. Each is signed with the gate's signing key and linked to the one before it, so a later change shows. Nothing is edited in place or deleted, so storage only grows. Run doublegate verify on the gate's machine, with the gate's home directory or an API key. It walks the chain and checks every signature.
Only its author and reviewers can read a held claim. Without the reviewer role, ask for another author's held claim by id, in a listing or in a count. The gate answers as if the claim did not exist. With an agent-role API key, ask for another author's held claim by its id. Then ask for an id that no claim has, and compare the two answers. A caller can still learn four things, timing among them, measured on the governance page.
Promotion makes a claim findable and never ranks it higher. A promotion adds no weight to a claim. Every promotion on one gate is marked provisional, checked by this one gate alone. The mark shows on each hit without moving it. By default recall matches words. An embedding model, if the operator configures one, adds matching by meaning. Read any recall answer: each hit carries the provisional mark, a field in the published OpenAPI, beside the search's own score. The mark does not change the order.

The full research set

Every study above links to its primary source. Our internal provider survey is available on request, with its method and per-provider notes.

Who pays, and what it costs

The business case