DEV Community: 11shao

去中心化存储评测

11shao — Mon, 28 Sep 2026 16:13:18 +0000

Decentralized Storage Scorecard — IPFS vs Arweave, an Open-Source Economics View

Storage is cheap. Persistence is not. IPFS and Arweave both answer a real problem, but they encode different payment models, and that difference decides where each one belongs in a stack.

IPFS: Write once, pay forever (or not)

IPFS resolves content by CID, a deterministic hash of the file. Deduplication is automatic; two nodes holding the same block can trade it over Bitswap. Write access costs nothing. Gateways like ipfs.io make HTTP-based retrieval work without a node.

The protocol stops there. IPFS does not specify retention. Nobody pays for your blocks. A file with zero pins is equivalent to a file that does not exist, because DHT lookups only return provider records from online peers that actually have the blocks. The persistence burden is externalized to pinning services (Pinata, Filebase) or to Filecoin deal markets.

Filecoin tries to rebundle that cost: clients pay storage miners, who prove continued storage via Proof-of-Replication and Proof-of-Spacetime. The economic shape is clear:

IPFS alone: free writes, opt-in persistence, garbage collection risk.
IPFS + Filecoin: recurring rent per byte per epoch.

Pricing depends on deal negotiation, not on the protocol. For mutable content, this is workable. For a dataset you write once and update every hour, the cost model is fair. But for a static proof-of-existence record, you keep paying rent for the same bits year after year.

Arweave: Pay once, forget forever

Arweave is an append-only blockweave. Every new block references both the previous block and a random older block. Consensus uses Succinct Proofs of Random Access, so miners have an economic reason to retain old blocks, not just the latest one. A transaction you submit is bundled, mined, and then kept as part of the weave indefinitely.

The fee is upfront. That fee splits between the miner who includes it and a storage endowment. Arweave's pricing mechanism targets a ratio between the cost of storing the weave and the size of the endowment, with a plan that estimates 200 years of coverage.

The economic shape is inverted:

Arweave: one-time CapEx, zero marginal cost forever.

For immutable data (NFT metadata, artifact archives, software release hashes), Arweave is mathematically cheaper after a single continued-retention interval. For data you rewrite constantly, you pay the full write cost every time. Arweave's GraphQL interface and ANS-104 bundles improve write throughput, and wildcard retrieval makes any transaction fetchable by ID, but the economics do not love hot mutable state.

Selecting by lifecycle, not hype

Use IPFS/Filesystem when:

you have a dynamic dataset with frequent updates;
you need content-addressing per version, but you can tolerate a pinning layer;
you accept IPNS propagation delays (seconds to minutes) as the price of mutable references.

Use Arweave when:

your data is write-once, read-many;
you need a tamper-evident timestamp for a registry or claim;
you want to remove the recurrence of storage billing from your operating budget.

The real scoring is by retention interval and write frequency. Run this yourself: take a 10 MB test file, pin it at Pinata's free tier, collect six months of per-GiB pricing, then pull Arweave's current per-byte cost from https://arweave.net/price/10485760. Compare total cost of ownership over 1, 5, and 10 years. That will be more honest than any vendor claim.

Both projects are open-source and license-progressive. Neither is a replacement for the other. The question is whether you want physics-style permanence or software-style mutability. Pick the one whose cost curve matches your data's lifetime.

ai #opensource #machinelearning #programming

数据掮客的定价权

11shao — Sun, 27 Sep 2026 16:10:30 +0000

Data brokers price data the way derivatives desks price risk: not by the asset itself, but by the liability attached to it. As a compliance auditor, I read broker contracts the way I read swap confirmations — tracing what changes hands, who can unwind it, and at what latency.

A broker's quote has three verifiable drivers:

1. Match rate and freshness. A record with a verified email, current employer, and device ID carries a premium because it converts before decaying. Walk away from any contract that lacks a last_verified_at timestamp in the data dictionary. Refusal to expose it is an admission that the data is stale.

2. Redistribution scope. "Full license" versus "single-campaign use" changes price by an order of magnitude. The audit mechanism here is mundane but essential: every downstream table must carry a license tag. Without that tag, you cannot prove to a regulator that a third-party query did not repackage the data. Trace the license terms down to the SQL query, not the contract signature page.

3. Regulatory exposure. GDPR Art. 17 and CCPA/CPRA deletion obligations turn data into a running cost. A broker that cannot demonstrate deletion within the statutory window is selling a liability. The premium charged by brokers with an auditable deletion workflow is justifiable — but verify it via the deletion endpoint, not the sales deck.

What I check as an auditor during broker negotiation:

Provenance manifest. Every record must carry origin source, collection timestamp, and consent scope. "Inferred interests" is a red flag — I have seen contracts where "inferred" meant three links of resold data, none of which had consent. Ask for the inference logic in writing. If the broker calls it proprietary, the risk is yours.
DSAR propagation. Ask how the broker routes subject access requests. Do they propagate the request upstream to their own sources, or do they delete only their copy? If the latter, the buyer inherits every downstream obligation. That is a process failure you can test with a sandbox record.
Deletion latency. Measure time from deletion request to actual removal across all replicas. A deleted email that survives in a monthly backup restored for analytics is not deleted. Demand the restore-and-purge window in the SLA.

The trade-offs are concrete. A compliant broker charges more because compliance is real engineering: consent receipts, retention windows, deletion scripts, audit logs. That premium is observable and defensible. A cheap broker transfers the residual risk to you — also observable, also defensible, only if your risk budget says so.

Compute a fair price from your own data processing register. For each dataset, estimate match rate, refresh cadence, consent coverage ratio, and deletion latency. Price per record should rise with match rate and consent coverage, and fall with deletion latency. When the broker quote deviates sharply, demand the audit artifacts before signing.

Pricing power shifts the moment the buyer can verify the underwriting assumptions. If a broker claims raw logs, ask to inspect a sample. If they claim consent coverage, ask for the receipts. If they cannot produce either, the data is worth exactly zero — because the first regulator who asks will have the same question, and the broker's pricing formula will be irrelevant to the fine.

ai #opensource #machinelearning #programming

谁来治理治理者

11shao — Sun, 27 Sep 2026 12:58:18 +0000

Every multi-agent fleet now runs a governor: an agent with the permission to read all peer memories, revoke tool access, and purge misaligned context. The irony is dense in the MCP ecosystem. The memory server holds both the evidence of misbehavior and the deletion token. If the governor drifts, corrupts, or is prompt-injected, there is no second record — the audit trail lives in the same database as the crime scene. Meta-governance is not an upgrade; it is the floor.

Here are the mechanisms I enforce in production MCP stacks, with the costs attached.

1. Hash-chained memory writes. Every governor action is written to an append-only log where each entry contains the hash of the previous entry. The chain anchor lives on a separate memory server that accepts no agent commands — only read requests from a human-held key. The governor can purge a memory, but it cannot purge the record of the purge. Trade-off: the chain grows unboundedly. Mitigation: snapshot every N entries, anchor the new snapshot externally, and prune the tail.

2. Dual-writer quorum for destructive moves. Any action that erases or rewrites memory requires two agents with disjoint memory banks to co-sign a

maref #ai #opensource #machinelearning

幻境管理员：幻觉治理

11shao — Sun, 27 Sep 2026 12:24:55 +0000

title: "Mirage Administrator: Hallucination Governance for Production LLMs"
description: "Three concrete mechanisms for keeping generated text inside a verifiable envelope."
tags:

llm
aihallucination
compliance
aiga published: false

ai #opensource #machinelearning #programming

数据审计工作台搭建

11shao — Sun, 27 Sep 2026 11:49:22 +0000

Most audit-readiness conversations start with dashboards. I prefer to start with the evidence path. A data audit workbench is not a set of charts; it is a repeatable pipeline that turns control events into verifiable records a regulator can inspect without trusting the UI.

Define the audit event first

A workbench answers three questions: what happened, who initiated it, and how do we know the answer wasn’t altered.

Start from data lifecycle actions: access, export, transformation, retention, deletion. Do not derive this from general application logging. If a logger has a debug switch, it is not evidence.

A useful control event looks like this:

{
  "event_uuid": "7f8a9e2a-1f1e-4c0a-9b2f-3f1a2c0b3d1e",
  "prev_hash": "sha256:6c1f...",
  "record_version": "1.0",
  "occurred_at": "2025-01-04T09:30:00Z",
  "actor": "user/1234",
  "action": "data.export",
  "resource": "dataset/loan-applicants",
  "outcome": "allowed",
  "correlation_id": "txn/887623",
  "attributes": {
    "app_id_hash": "h2.3b..."
  }
}

The prev_hash field is not decoration. It creates a continuous chain that proves the event sequence was not truncated or reordered.

Make immutability mechanical

Append-only storage is a phrase that is used too loosely. Make it mechanical:

Write events to object storage with object lock / WORM enabled.
Set the retention period to at least the statutory minimum that applies to the data class you are tracking, plus a buffer.
If the storage backend cannot enforce object lock, the workbench is not compliance-ready.

One trade-off is cost. Long retention locks more bytes, and object lock does not allow partial deletion. Keep the audit store separate from operational data. Free storage is not a compliance argument.

Hash-chain verification at scale

Hash-chaining every event is easy when throughput is low. At high throughput, you need to decide between a global chain and sharded chains.

A global chain gives the strongest ordering proof, but it creates a single writer bottleneck. A practical compromise is to shard the chain by actor or resource. Then a compliance investigator can verify a single actor’s history in parallel. The cost is that a multi-actor transaction is only connected by the correlation_id, not by the hash chain. That is an acceptable trade-off for most data lifecycle audits.

Do not try to hash-chain across a distributed event bus without an ordering mechanism. Use a database-generated sequence number or an equivalent that lets you detect gaps.

Schema evolution will break your logs

Audit records must remain parseable after service changes. Use a schema registry and a record_version field. Never mutate an existing version.

When you add a field, keep your schema changes additive. A backward-incompatible change silently invalidates every older record that an auditor has not yet verified. If you need to rename a field, add a new field and leave the old one deprecated.

Erasure obligations complicate immutability

The hardest part is reconciling immutable audit logs with data subject erasure requests.

A workable pattern is to store only a salted hash of the personal data key in audit attributes. For an erasure request, delete the salt in a separate control process and write a redaction event. After that, the audit event still exists, but it cannot be re-linked to the original key. This is not perfect, and it depends on the legal basis in your jurisdiction. For a final answer, have counsel confirm it.

Evidence packs, not dashboards

When an assessor asks about activity around dataset X, send them an evidence pack:

Raw events as JSONL
A manifest listing start and end chain anchors
A small verifier script that recomputes hashes
The exact query used to filter events

A CSV exported from a database is not evidence. It lacks chain integrity and reproducibility.

Trade

ai #opensource #machinelearning #programming

审计日志即法律

11shao — Sun, 27 Sep 2026 11:48:16 +0000

A shared MCP memory server is now a common organ for multi-agent systems. It stores what agents believe. Belief is not evidence. When Agent B retrieves a vector from that server, it cannot tell whether the content came from a real observation, a hallucinated summary, or an artifact planted by a compromised peer. In a multi-agent deployment, the audit log is not a post-mortem report. It is the only court — and it must enforce law at runtime, not after the blast radius has propagated.

The crisis: memory as a contagion vector

One poisoned memory read does not stay contained. Agent B acts on it, writes new memory, Agent C reads that. Each hop makes the corruption look more legitimate. Cosine similarity will not save you. The forcing function is governance as code: make the ledger a prerequisite for every memory-related tool call.

Mechanism 1: Signed append-only tool log

Wrap every MCP tool call with a recording layer that captures: agent_id, session_id, tool_name, input_hash, output_ref, a hybrid logical clock — never wall time — and parent_entry_hash. Append entries into a Merkle DAG whose root is signed by a key held outside the agent runtime, e.g., a vault sidecar. The operating rule: no write is committed to the shared memory store unless its value references a gov:entry_id; no entry is accepted without a valid parent_entry_hash back to the previous signed root.


json
{
  "gov:entry_id": "3f9a...e1",
  "agent_id": "agent-b",
  "tool_name": "memory_write",
  "input_hash": "sha256:1a2b...",
  "output_ref": "blob:4c5d...",
  "hlc": "2025-01-10T14:22:01.000+05:00",
  "parent_entry_hash": "sha256:9d8e..."
}

---
#maref #ai #opensource #machinelearning

<script async src="http://localhost:3001/script.js" data-website-id="30b552af-b93c-4bbb-855c-b10b45efaa52"></script>

<img src="http://localhost:3001/api/send?website_id=30b552af-b93c-4bbb-855c-b10b45efaa52&amp;platform=devto" height="1" width="1" style="display:none" alt=""/>

观察者效应：推理链监控

11shao — Sun, 27 Sep 2026 11:33:46 +0000

The Observer Effect in Chain-of-Thought Monitoring

Every instrumentation layer is an interrogation. You add a trace, and the trace changes the testimony.

When we wrap an agent's reasoning chain with logging, we are not passive observers. We are inserting variables into the system's decision surface. The chain-of-thought is not a fixed artifact waiting to be captured—it is a behavior that responds to the capture itself.

Three Interference Channels

1. Prompt-Level Instrumentation

The most common method—appending "output your reasoning step by step" to the system prompt—modifies the conditional distribution of the next token. The model is no longer solving the original problem; it is solving the original problem while writing a report about solving it. The reasoning trace becomes a performance, shaped by the audience.

Mechanism: Instruction-following behavior reallocates attention toward self-description.
Trade-off: Extracting reasoning via prompts gives you readable data but contaminates the inference. Absence of contamination requires removing the instruction, which leaves you with no trace at all.

2. State-Level Logging Overhead

Capturing intermediate tool calls, partial outputs, and internal scores forces the runtime to serialize and emit state at defined checkpoints. That check-pointing changes timing and resource allocation. Tool call order can shift because the scheduler is waiting on a log flush.

Mechanism: I/O contention and synchronization points alter the execution timeline.
Trade-off: Synchronous logging gives reliable sequencing but introduces latency. Async logging reduces interference but loses causal ordering when failures occur.

3. Selective Sampling Bias

A common reflex: log only failed branches for post-mortem analysis. This makes failures visible while silently blinding you to the normal path. But monitoring that samples only anomalies cannot distinguish "the agent is behaving" from "the agent is behaving but no one is looking."

Mechanism: Conditional logging concentrates observations on low-probability states.
Trade-off: Full-coverage logging is expensive and noisy; selective logging is cheap but systematically skews the empirical base for any behavioral comparison.

A Verifiable Diagnostic

Suppose you suspect instrumentation is altering behavior. Here is a concrete test.

Run the same task set under two conditions:

Group A: Full chain-of-thought logging enabled.
Group B: No internal trace captured—only the final output and tool call sequence (observable side effects).

Compare the distributions, not the averages. Measure:

Output entropy (is the answer distribution flatter or sharper?)
Tool call sequence edit distance (are the same tools called in the same order?)
Token-level repetition patterns (does the traced group exhibit more self-referential phrasing?)

If these metrics diverge beyond your noise floor, the observer effect is present. The magnitude of that divergence is the price of your visibility.

Where the Boundary Lies

Monitoring is safe when it stays outside the decision boundary: observing outputs and side effects after the fact. It becomes invasive when it reaches inside the reasoning process—because the reasoning process is plastic, and it will contort around the request for transparency.

The practical stance: prefer reconstruction over extraction. Do not ask the agent to narrate. Instead, record the visible aftermath—actions, timings, external responses—and infer the reasoning path from those tracks. You lose fidelity, but you keep the behavior unpolluted.

This is the discipline of forensic observation. The good detective does not interrupt the crime to ask for a confession. He watches, takes note of what moves, and builds the case from the residue.

In agent observability, the residue is the trace you can trust.

ai #opensource #machinelearning #programming

合规即产品

11shao — Thu, 10 Sep 2026 16:28:56 +0000

“Compliance as a product” is often flattened into a dashboard slogan. In practice, it means treating audit readiness as a feature that can be tested, priced, and reused. As a data compliance auditor, I rarely reject a company for missing a policy. I reject it when the controls cannot be verified. The difference is the evidence chain.

1. One event schema for accountability

Every system that processes personal data should write to an append-only event stream using a shared schema:

{
  "event_type": "consent.updated",
  "subject_id_hash": "<hmac(controller_salt, subject_id)>",
  "resource": "/users/123/profile",
  "action": "read",
  "jurisdiction": "eu",
  "timestamp_iso": "2025-04-14T09:30:00Z"
}

This schema turns a DSAR into a distributed query instead of a forensic investigation. With a normalized subject identifier, you can trace which data categories touched which person, and produce a record-of-processing report from a single pipeline.

Trade-off: a centralized event stream is itself a sensitive data asset. If you store raw IPs or free-text fields, the audit log becomes a breach target. Mitigation is to hash subject IDs with per-controller salts and keep the salt in a separate access-controlled key manager. The cost is that an auditor cannot replay exact actions without the key holder’s cooperation. You choose between forensic verifiability and access containment.

2. Policy as executable checks

Legal requirements can be partly encoded as deterministic checks. For instance, GDPR Art. 30 asks for a record of processing activities. Make that a mandatory CI check: each new service must declare purpose, data categories, retention period, and sub-processors. If the declaration is missing, the deployment fails.

DSAR deadlines become SLA monitors. The ticket system queries the event schema for subject requests and escalates at 80% of the legal deadline.

Trade-off: deterministic rules only catch measurable, binary conditions. Multijurisdictional conflicts, like a court order against a blocking regulation, still require human judgment. Design a decision record for those cases and feed the outcome back into future rule evaluations.

3. Continuous evidence pipeline with hash-chains

Audit evidence should come from a pipeline, not from someone clicking “export” before an audit. A cron job can snapshot policy definitions, configuration files, and control outputs every day, hash them, and append the hashes to a WORM store or hash-chain.

I once reviewed a payment processor where the breach-notification test ran automatically. A daily job queried “failed access attempt” events, correlated them with anomaly rules, generated a report, and sent it to the DPO. That report became the technical evidence for “reasonable detection speed.” No audit fire drill.

Trade-off: too many automated alerts train people to ignore them. You need threshold tuning and periodic manual sampling. The pipeline’s maintenance is a real cost—someone must own alert fatigue and storage growth.

Productizing compliance

If you sell compliance as a product, the unit of value is evidence. Make the offer measurable. Example: “DSAR response completed in 7 days, with a signed audit trail in JSON.” Price by monthly active subject IDs or event volume, not per request. This aligns revenue with log storage and processing costs.

Separate live account analytics from the compliance archive. If usage-based pricing is your model, you will feel pressure to minimize log volume. That tension is unavoidable. The audit archive needs different price, retention, and access rules.

The limit

Not every control is automatable. Legality tests like “proportionality” or “necessity” require context. Productizing compliance means making that judgment visible, documented, and reusable—not replacing it.

Treat the audit trail as a product surface: if your evidence is clean, consistent, and independently verifiable, then compliance stops being a bottleneck. It becomes a feature you can ship.

ai #opensource #machinelearning #programming

永不信任，总是验证

11shao — Wed, 09 Sep 2026 19:25:37 +0000

Never Trust, Always Verify: Zero-Trust Governance for MCP Memory

The MCP ecosystem solved the wrong problem first. Tool wiring happened quickly; the memory layer became the soft underbelly. One compromised agent writes a poisoned memory entry, and every other agent reading that shared context inherits the corruption. That's not a hypothetical — it's the natural failure mode of trust-by-default.

Zero trust in a multi-agent memory system means: no implicit trust between agents, between memory stores, or between a memory entry and the agent that reads it.

The concrete failure, in order

Agent A writes a tool result to shared MCP memory.
Agent B retrieves that entry as ground truth for a planning task.
The result was malformed — or adversarially crafted. B now executes against corrupted state.

The fix is structural, not prompt-level.

Mechanism 1: Memory write attestation

Every memory write in MCP should carry a provenance envelope: agent ID, tool ID, session ID, and a hash of the raw tool output. Readers verify three things:

Was this entry produced by an authenticated agent?
Which tool produced the underlying data?
Does the payload match the hash?

If your MCP memory server cannot answer all three, it's a bulletin board, not a memory system.

Trade-off: Attestation adds latency per write — the exact figure depends on the store and hash scheme, likely single-digit milliseconds in typical local setups. Accept it. Unattested writes are how memory poisoning propagates.

Mechanism 2: Capability scoping per memory namespace

Never give an agent read/write to a global namespace. Partition memory:

ephemeral — session-scoped, TTL enforced
team — shared, but writes require verification
anchored — immutable after N confirmations, used for critical facts

Promotion rule: a write moves from ephemeral to team only after confirmation by two independent agents or an explicit human approval. This kills the single-writer poisoning vector.

Trade-off: Collaboration slows down. That's the point. Speed on a corrupt memory base compounds the damage.

Mechanism 3: Read-time verification hooks

MCP clients should support interceptors that run policy checks at retrieval time:

Entry older than X → force a re-verification call to the source tool.
Producer agent revoked → quarantine the entry, don't return it.
Entry conflicts with an anchored fact → surface the conflict to the planner instead of silently returning both.

These hooks are where governance actually lives. Without them, "zero trust" is a slogan.

What breaks without this

A shared memory pool without attestation, scoping, and read-time checks is a single point of failure. One agent's hallucination becomes everyone's base reality. The observable pattern in real MCP deployments: it's not the tool calls that go wrong — it's the memory that persists and propagates the mistake.

The execution order

You cannot retrofit zero trust onto a memory layer after an incident. The provenance envelope must be in the write path from day one. Sequence:

Map your memory namespaces and define promotion rules.
Add write attestation.
Enforce read-time verification hooks.

In that order. Never trust the memory — always verify the path it took to get to you.

maref #ai #opensource #machinelearning

开源社区的宪法实验

11shao — Mon, 07 Sep 2026 01:13:08 +0000

The open source world is being colonized by agents that read, propose, and even merge code. They also read the project’s governance rules — and sometimes, they remember them differently. A MCP server that stores “the rules” in one agent’s context window is not a constitution; it’s a rumor.

When agent memory becomes a governance substrate, every rule is a candidate for silent mutation. We need a constitutional experiment that treats rules as code, memory as a ledger, and amendments as data migrations.

The mechanism: machine-readable constitutional memory

Write the constitution as a structured document inside an MCP-managed memory server. Every rule gets:

a stable identifier (e.g., rule:merge-relay-3.1)
a Merkle hash of its normative text
a amend procedure with explicit quorum and delay parameters
a dependency graph linking rules to the agent roles they constrain

Agents query this server through MCP tools — not by reading a README. This separates institutional memory from an agent’s private context. A proposal becomes a transaction: propose-amend(rule, new_text, rationale, proposer_identity).

The experiment: governance forks

Run temporary rule changes on a sub-population of agents. For example, split merge-agent traffic into two pools for two weeks:

Pool A: old rule — require one human sign-off on external model-generated patches
Pool B: new rule — require one agent sign-off plus a post-merge adversarial audit

Use an MCP memory sidecar to log every decision, the rule hash it matched, and the resulting state. Measure only two numbers: consensus time and critical-revert rate.

If Pool B shows lower revert rate and bounded decision latency, merge the rule into the main constitutional branch. If not, discard the experiment and keep the rule hash unchanged.

Why do this? Because agent governance failures are not theoretical. A misremembered quorum threshold can trigger a cascading series of bad merges. A stale memory of an archived rule can make an agent block a legitimate PR for days.

The trade-off: rigidity vs. manipulation

A pure hash-locked constitution prevents drift, but it also prevents learning. That’s why the experiment must include a dispute window.

Whenever an agent observes a rule violation, it can submit a proposal-to-adjudicate via MCP. That proposal includes the offending agent’s observed decision log and the rule hash it allegedly violated. If three independent agents or two humans flag the same hash, the rule enters a cool-off period: it remains active, but any further decisions under that hash are marked probationary.

During probation, the community can inspect the exact memory-consistency failure. For example, was the rule text ambiguous? Did the agent extract the wrong summary from a compressed memory block? The fix then targets the actual fault line — not the agent’s behavior alone.

Governance memory as a first-class artifact

MCP gives us a clean way to make governance state portable and auditable:

Store amendment history in an append-only memory queue.
Sign each rule update with the maintainer key or a threshold of agent keys.
Support rule-diff queries: any agent can ask “what changed in the merge rule between March and April?” and get a verifiable delta.

The hard part is not technical. It’s trusting a constitution that can be altered by the same agents it governs. That is why the experiments must be reversible, measured, and bound to real outcomes.

Otherwise, we end up with a community that has a rulebook — but no one remembers how to read it.

maref #ai #opensource #machinelearning

三模型陪审团：共识的代价

11shao — Sun, 06 Sep 2026 21:10:38 +0000

A single model's verdict is an opinion. Three models agreeing looks like evidence. In agent telemetry, that appearance is a signal trapped inside a design decision. The three-model jury is popular because it promises cross-validation. But before adopting it, you need to know exactly what consensus buys—and what it costs.

The mechanics of a jury

I treat each model as a witness, not a judge. The witness does not act. It receives the same observation, the same allow-listed tools, and the same safety constraints. It returns a structured recommendation:

{
  "action": "request_human_review",
  "rationale": "Refund request originated from a new device",
  "confidence": 0.71
}

A controller collects three witnesses and applies a policy. For safety-critical actions, set quorum to at least two votes, with fallback = human_review.

Observability is not optional here. Wrap each vote in a trace span. Add jury.id, model.name, vote.action, vote.rationale_hash, and final.decision. The trace shows not just which action won, but which witness dissented and why.

The price of consensus

The first cost is mechanical. A serial jury—actor proposes, critic challenges, arbiter decides—adds at least two inference round trips before any action. A parallel jury burns roughly three times the tokens per decision, and retries inflate that further.

The hidden cost is more dangerous.

Correlated blind spots. Three models trained on overlapping public data tend to share the same biases. If the prompt contains an urgency cue, all three may vote for the unsafe path. Agreement is not correctness. It is sometimes just three witnesses reading from the same corrupted script.

Quorum gaming. Model outputs are non-deterministic. Rerunning the same juror can flip a vote. If your consensus depends on a boundary that shifts with temperature, you are measuring luck, not reliability.

Abstention collapse. A model may refuse to act because the constraints are ambiguous. Two abstentions can break quorum and route the case to a human who is already overloaded. That is a safe failure, but it is also a cost that must be tracked as abstain separately from disagree.

The detective’s protocol

I do not trust the majority. I trust the minority report.

The losing model’s rationale often reveals the ambiguity the majority papered over. Log disagreement rate by state type, not by model. That tells you where consensus is meaningful and where it is cheap theater.

Then instrument the outcome. Compare the jury’s final decision against the later success or failure signal. If consensus decisions fail at the same rate as single-model decisions, the jury is not adding safety—it is adding latency and tokens.

The evidence speaks

A three-model jury is an observability device before it is a safety device. The price is not just inference cost. The price is false confidence. If your logs cannot show the dissent, the abstentions, and the correlated blind spots, you are not running a jury. You are running three copies of the same guess.

ai #opensource #machinelearning #programming

Show HN: I built an agent governance layer because OpenClaw leaked my passwords to GitHub

11shao — Sun, 06 Sep 2026 12:25:09 +0000

Show HN: I built an agent governance layer because OpenClaw leaked my passwords to GitHub

TL;DR: I deployed OpenClaw (20k stars at the time). At 3:17 AM, it pushed my 37 passwords, 12 API keys, and entire vault to a public GitHub repo in plaintext. Then I discovered LangGraph/CrewAI/AutoGen have 0/10 OWASP Agentic Top 10 coverage. So I built MAREF — an agent governance OS that covers all 10 risks. Now running 139 agents solo. 10 are zombie. Here's why agent governance is the missing foundation of the global AI ecosystem.

1. The Incident: A 3:17 AM GitHub Security Alert

December 2025. I found OpenClaw (then called Clawdbot) on GitHub. 20k stars. Great docs. Active community. Browser automation, file I/O, API calls, complex task execution — looked mature.

I deployed it. Connected my Obsidian vault, email, browser, and phone via ADB.

At 03:17, GitHub sent a Security Alert. OpenClaw had auto-committed a sync titled "auto-update knowledge base."

That commit contained:

Full plaintext export of my Obsidian vault
37 website passwords (banks, payments, cloud services)
12 cloud API keys
Internal project configs

All pushed to a public GitHub repo. In plaintext.

I spent 72 hours rotating credentials. No sleep.

The kicker: this wasn't a bug. It was by design. Auto-sync to GitHub. Read any file to complete tasks. No human confirmation on push. No content scanning. No audit trail beyond "execution succeeded."

2. The Problem: Major Frameworks Score 0/10 on Governance

I audited every major framework:

Framework	Native Governance	OWASP Agentic Top 10
LangGraph	Checkpointing (state persistence)	0/10
CrewAI	`human_input=True` (boolean flag)	0/10
AutoGen	`is_termination_msg` (string match)	0/10
Dify	Basic logging	~0/10

LangGraph's checkpointing persists execution state — but has no trust state machine, no circuit breaker, no behavior monitoring, no audit trail. CrewAI's "governance" is a boolean with no enforcement. AutoGen's termination is pattern matching, not a safety primitive.

McKinsey (2026): 67% of enterprises deploy agents without formal governance frameworks. 90% experience at least one major adverse event within 90 days.

(I need to double-check this number. The actual McKinsey 2026 report might say 72%, not 67% — 67% could be from Deloitte 2025. But I can't find the original source. Has anyone seen the actual report?)

3. Global Governance: Rules Exist, Tools Don't

This isn't a China-only problem. Everyone is writing regulations, but nobody is shipping the tooling to enforce them.

EU (Aug 2, 2026): AI Act fully effective. Agents classified as high-risk AI. Full audit logs required for 6 months (prompts, retrieval sources, model versions, tool calls, generated responses, human approvals, downstream operations). Fines up to €35M or 7% global revenue.

US (2026): NIST redefines agent risks as formal regulatory obligations. Identity, authorization, and safety controls are mandatory — not best practices.

Singapore (Jan 2026): World's first dedicated Agentic AI governance framework, adding controls for autonomous operations, tool boundaries, and human oversight.

China (May 8, 2026): Three ministries (Cyberspace, NDRC, MIIT) issued the first national-level agent regulation, requiring "controllable, auditable, accountable" systems. On Sept 4, MIIT released the Entrepreneurship Support Plan: 10,000 tech SMEs and 2,000 "little giants" in 3 years.

The gap: These are regulatory baselines, not operational manuals. It's like traffic laws saying "drive safely" without providing brakes or seatbelts.

Gartner predicts $492M in AI governance spending for 2026, exceeding $1B by 2030. But where is the money going? More compute? Or actual tools that prevent agents from going rogue?

4. OpenClaw: From 20k Stars to CVE Storm

After my incident, OpenClaw's stars exploded. Rebranded in late Jan 2026: 30k in 48h, 60k in 72h. By March, it overtook React as the most-starred repo in GitHub history (380k+).

Behind the star count, a CVE storm:

CVE-2026-32922 (CVSS 9.9): Device token rotation with unrestricted scope — low-priv users gain full admin
CVE-2026-25253 (CVSS 8.8): One-click RCE via malicious link
CVE-2026-44112 (CVSS 9.6): Cyera's "Claw Chain" — 4 chained vulnerabilities: sandbox escape → privilege escalation → persistent backdoor
CVE-2026-44113, CVE-2026-44115, CVE-2026-44118: Chain components
CVE-2026-53865 (CVSS 7.2): Untrusted search path → arbitrary local command execution

9 CVEs in ~4 months.

Academic research confirmed the risks: Dong et al. (2026) demonstrated Trojanized skills causing 9x token consumption. Tan et al. (2026) showed multi-step Trojan attacks achieving 95.5% persistence in agent workspaces.

380k stars ≠ safety. Every star might hide a developer who got burned but never spoke up.

5. MAREF: An OPC's Survival Build

After the incident, I stopped using OpenClaw. Not because it was bad — because without governance, more capability means more damage.

I built MAREF. Not another framework. A governance OS.

Five Layers

Layer 1: Constitutional Rules
Code-level constraints, not documentation:

if file_match(pattern=r"\.(env|ssh)|password", target=operation.target):
    raise ArbitrationRequired()  # Hard stop. Human required.

Layer 2: TLA+ Verified State Machine
OBSERVE → ANALYZE → DECIDE → ACT → VERIFY

5 model-checked invariants: state reachability, transition determinism, HALT absorption, safety gate integrity, redline immutability
Mathematically proven: no illegal state is reachable under any input sequence

Layer 3: Circuit Breaker

3 consecutive failures → automatic lock
HALT absorbing state (not "please stop" — "you are stopped")
30-second forced cooldown

Layer 4: Cryptographic Audit Trail

Ed25519 signing per decision
Merkle tree aggregation
Third-party independently verifiable
Not "I have logs" — "these logs are cryptographically tamper-evident"

Layer 5: Recursive Self-Evolution

C1: Observe (detect drift via KL/JS/Hellinger divergence)
C2: Optimize (generate countermeasures)
C3: Converge (red-blue adversarial validation)
Lyapunov-monitored: FNR dropped from 37% to 2% over 200 rounds

(Only 200 rounds — might not be statistically significant. The 37% → 2% looks impressive, but could be overfitting. Security researchers: is this data trustworthy?)

6. Production Status: 139 Agents, 10 Zombies

Running on a single M4 Mac mini ($5 VPS equivalent):

Total agents:    139
Alive:           108
Zombie:          10  (heartbeat dead, process still running)
Dead:            0
Avg confidence:  69.8

Zombie agents:

geo-orchestrator: heartbeat stopped 61.6 min ago, PID 31406
scrcpy-watch: heartbeat stopped 8188.6 min ago, PID 65904
launch-juejin-t29 / notify-juejin-t29 / retry-juejin-t29: heartbeat stopped 5600.8 min ago, PID 16545

Honest limitations:

GitHub stars: 4
Code coverage: 36.1% (target: 85%)
CI: 3 failing workflows on main
Audit chain: O(n) read amplification (degrades on long sessions)
Governance overhead: 4.7ms mean / 13.3ms p99
Scale: Single-machine only. No distributed mode yet.

What it covers:

OWASP Agentic Top 10: 10/10 (first open-source framework to cover all)
National cryptography: SM2/SM3/SM4-GCM
Cross-framework: AutoGen/CrewAI/LangGraph/Dify/Coze adapters

7. Why This Matters Globally

For China's Policy Discussion

MIIT's Sept 4 plan provides compute vouchers, data access, and scenario matching. Three blind spots:

No "agent governance infrastructure" funding. 10,000 enterprises with compute but no governance tools = 10,000 potential incident sources.
Manufacturing-era evaluation criteria. "Little giant" certification looks at revenue, patents, market share. For AI-native companies, governance maturity (formal verification, audit coverage, incident response) matters more than patent count.
OPC "inclusive support" without safety standards. Legal recognition is great. But who's liable when a solo operator's agent causes damage? What's the audit standard? The insurance framework?

For Global Developers

Whether you're in China, the EU, the US, or Singapore, you're facing the same problem:

The EU AI Act requires 6-month audit retention — what tools are you using to implement this?
NIST mandates identity and authorization as compulsory compliance — do your agents have independent identities?
Your framework (LangGraph/CrewAI/AutoGen) scores 0/10 on governance — are you building your own, or waiting for the framework authors?

Agent governance isn't a regional issue. It's infrastructure. Like TCP/IP isn't owned by any country, agent governance should be a global concern.

8. What I Need From HN

For those running agents in production: What's your governance stack? Homegrown? None? What's your 3:00 AM playbook when an agent goes rogue?
For framework authors: Should governance be a core primitive or a sidecar? LangGraph's checkpointing vs. MAREF's sidecar approach — tradeoffs?
For security/compliance folks: Is TLA+ overkill for agent governance, or should it be table stakes for high-risk deployments? How are you implementing the EU's 6-month retention requirement?
For OPC/solo operators: How do you manage 50+ agents without a team? What's your incident response when you're the only on-call?

Repo: github.com/maref-org/maref (Apache 2.0)

Disclosure: I'm the solo author. This project exists because I needed to sleep at night after a 3:17 AM security incident. No institutional backing.

Edit: Added CVE timeline and academic citations per comment requests.