{"slug": "why-not-trust-us-md", "title": "why-not-trust-us.md", "summary": "A developer behind AxonOS has published RFC-0009, a specification for a bit-accounting mechanism that bounds how much data an authorized application can extract from a neural device, rather than relying on access control. The spec's own not-claimed section (L1–L4) concedes the mechanism does not stop the platform operator itself from extracting data, does not choose which bits leave, and assumes the enforcing component is honest. The author notes that the cross-grant accounting clause N6 is normative but unimplemented.", "body_md": "*A reply to a fair question: if AxonOS bounds what an application can extract,\nwhat stops AxonOS — or whoever operates it — from extracting instead?*\n\nThe honest answer is that nothing in the architecture stops us. An operator who holds the keys holds the data. That is true of AxonOS, of every neural device shipping today, and of every system that has ever had a privileged component.\n\nSo the question is not \"are they trustworthy.\" It is **\"what can you check\nwithout trusting them.\"** Below is the complete list of what I believe is\ncheckable in this project, and — more usefully — the list of what is not.\n\nRFC-0009 does not model a hostile third party stealing data. It models a\n**legitimate, authorised party** — an application with a valid grant, or the\nplatform itself — extracting more than the subject intended, one lawful query\nat a time.\n\nThat is the harder threat, because nothing is broken. Every access is permitted. The extraction is the sum of permitted things.\n\nThis is why the mechanism is an *accounting* mechanism rather than an access\ncontrol one. Access control answers \"may you.\" Accounting answers \"how much,\nin total, have you.\"\n\nThe raw signal lives inside a container with **no public read path**. The\nnormative text:\n\n**N1.** Raw samples MUST NOT be reachable through any public interface of\nthe sealed container.\n\nAn application does not receive samples. It submits a reducer — a question — and receives an answer. The answer has a cost in bits, and:\n\n**C1.** `cost(r)` MUST be computed by the enforcing component from the\nactual content of *r*, per (1).\n\n**C2.** An implementation MUST NOT accept a cost supplied by the requester,\nand MUST NOT allow a reducer to declare its own price.\n\nThat second clause is the part worth dwelling on. If an application could declare its own cost, the budget would be theatre. The price is computed from what the answer actually contains, by the component enforcing the budget, not by the party being charged.\n\nWhen the budget is exhausted, further queries are refused, and:\n\nThe conjuncts MUST be evaluated in the order given, and the refusal MUST name the first conjunct that failed.\n\nA refusal that does not say why is a refusal you cannot audit.\n\n**What this does buy, stated plainly.** It removes every party from the picture\nexcept one. A third-party application cannot exfiltrate the raw signal, not\nbecause a policy forbids it but because no type exists through which the samples\ncould leave. What remains is the platform vendor. That is the same shape of\nguarantee a phone sandbox gives: it does nothing against the vendor, and it does\na great deal against everybody else. Whether that is worth anything to you\ndepends entirely on whether your threat is the vendor — and in the scenario you\ndescribed, it is.\n\nThe specification carries its own not-claimed section, as **L1–L4** in RFC-0009.\nI did not write it in response to criticism; it has been there since\npublication, and it is the part I would read first if I were you.\n\n**It does not choose which bits leave.** A bound of β bits is a bound on\nquantity, not on sensitivity. The β bits an adversary extracts may be the most\ninformative β bits available. A bound is not anonymity.\n\n**It bounds a transcript, not an inference.** What an adversary concludes from\n*facts about* the transcript — timing, query patterns, the fact that a question\nwas asked at all — is outside the model.\n\n**It assumes the enforcing component is honest.** An adversary with kernel\nprivilege, physical memory access, or control of the enforcing component itself\nis out of scope entirely. If the platform is the attacker, this mechanism does\nnot save you. **Including if the platform is us.**\n\n**N6 is normative and unimplemented.** The RFC requires accounting *across\ngrants* for one subject, so that an application cannot reset its budget by\nrequesting a fresh grant tomorrow. The clause is blunt about what its absence\ncosts:\n\n**N6.** The issuer MUST maintain accounting across grants for a subject, per\nTheorem 2. An enforcing component that meets N1–N5 while its issuer grants\nwithout limit satisfies the letter of this RFC and defeats its purpose.\n\nThere is no issuer layer in which to implement it, and none exists yet. Until there is, the bound holds per grant, not per subject — materially weaker than the theorem permits.\n\nFive things, none of which require believing me.\n\n**The specification is public and dated.** RFC-0009 is in a repository with full\nhistory. You can see what it claimed on any past day, and whether a claim\nappeared before or after somebody asked an uncomfortable question. A claim that\nappears the week after a critique is a different kind of claim.\n\n**The not-claimed section predates the criticism.** Check the commit history on\nthat section. If a project only admits limits when cornered, the history shows\nit.\n\n**Every number carries a level, and the levels mean something specific.** From\nthe standard, Section 22:\n\n**Level L1**, *formally proven*: the claim is a bound established by a\nmachine-checked formal proof that covers the entire admissible input space.\n[...] A claimed worst-case bound that has not been proven over the entire\ninput space is not L1.\n\n**Level L2**, *measured on reference hardware*: the claim is a value measured\non the reference hardware, under stated conditions, with the measurement trace\npublished. [...] A measurement on hardware other than the reference hardware\nis not L2.\n\n**Level L3**, *independently validated*: the claim is an L2 measurement that\nhas additionally been reproduced by an independent third party, on a separate\ninstance of the reference hardware, and witnessed by a signed report.\n\nNo claim in this project holds L3. Several L2 figures are measured but their traces are marked publication-pending rather than published, and the catalogue says which. The validation repository holds the structure and the deterministic post-processor that turns a raw trace into a headline figure; what it does not yet hold is the traces, and its README says which are missing and why.\n\n**The corrections are in the history, with dates.** Four in the last fortnight,\nnone of them flattering:\n\n- A clinical memorandum was listed as signed in the roadmap's closed deliverables. None had been signed. Corrected on every surface, 12 August.\n- Phase 1 did not close on its published calendar. The slip was published with its reason rather than the date quietly reprinted, 12 August.\n- A cycle bound was tagged **L1** when the harness backing it proves\ntermination and contains no cycle assertion. Downgraded to analytical. The\ncorrection reached the owning repository on 16 August and the claims\ncatalogue on 23 August, and**that seven-day propagation gap is itself\nrecorded there** as an open process defect.\n- Section 19 of the standard specifies a 28-byte wire record. Every implementation uses a 32-byte record sharing no field at any offset. An erratum now stands at the head of that section warning that it must not be implemented from, 26 August, and the correction is filed as RFC-0011 through the amendment process rather than edited in, because the standard's own Sections 26–28 forbid editing it in.\n\nThat record is the most useful evidence about this project available, and it is not flattering. It is also the reason the third item above is worth reading: a project that finds its own propagation gaps and writes them down is making a different claim than one that has never reported an error.\n\n**The conformance vectors are byte-exact.** An independent implementation can be\nchecked against them without my involvement. That is the only form of\nverification that does not route through trusting me. Six implementations clear\nthat bar today, all of them mine; no outside implementation has, and the\nchallenge is deliberately left open.\n\nNot a specification. A specification enforces nothing, and I would distrust anyone who told you otherwise.\n\nWhat solves it is an **enforcing component the operator does not control** —\nwhich means either hardware the vendor cannot update unilaterally, or an issuer\nrun by a party with no stake in the extraction. Both are unsolved. Neither is\nunsolved only for me: the whole field has this problem, and most of it has not\nyet stated the problem out loud.\n\nWhat a specification *can* do is make the quantity exist. Today a regulator\ncannot ask a neural device how much a given application extracted, because the\nquantity is undefined — there is no unit, no accounting, nothing to point at.\nWith a bound, the question has an answer, and **a device that will not answer it\nis telling you something.**\n\nThat is a smaller claim than \"your data is safe with us.\" It is also the only one I can support.\n\nEverything above is checkable. None of it requires an account, a signup, or asking me.\n\n- **RFC-0009** — the sealed container, the accounting, and the L1–L4\nnot-claimed section:[https://github.com/AxonOS-org/axonos-rfcs/blob/main/rfcs/0009-bounded-disclosure-sealed-neural-data.md](https://github.com/AxonOS-org/axonos-rfcs/blob/main/rfcs/0009-bounded-disclosure-sealed-neural-data.md)\n- **The evidence taxonomy** — Section 22 of the standard, and the claims\ncatalogue with its corrections:[https://github.com/AxonOS-org/axonos-standard/blob/main/CLAIMS.md](https://github.com/AxonOS-org/axonos-standard/blob/main/CLAIMS.md)\n- **Conformance vectors** — byte-exact, independently runnable:[https://github.com/AxonOS-org/axonos-conformance](https://github.com/AxonOS-org/axonos-conformance)\n- **The organisation** —[https://github.com/AxonOS-org](https://github.com/AxonOS-org)\n\nIf you find a claim in any of them that the code does not support, an issue is more use to me than a polite silence. Several have been found that way already, and every one is in the history.\n\n*Revised 13 September 2026. The first version of this note said L1 meant\n\"analytically derived.\" It does not: Section 22 defines L1 as a machine-checked\nformal proof, and analytical derivation is a separate and weaker tag. That\ndistinction is exactly the one the 23 August correction above turns on, so\ngetting it wrong here was worse than getting it wrong anywhere else. Two further\nfixes: a reference to a document that does not exist under that name has been\nremoved, and the validation repository was described as empty when what it lacks\nis the traces rather than the structure.*\n\nDenis Yermakou · AxonOS · [connect@axonos.org](mailto:connect@axonos.org) · Written in reply to Peter\nMeijer, who asked the question that should be asked of every project in this\nfield.", "url": "https://wpnews.pro/news/why-not-trust-us-md", "canonical_source": "https://gist.github.com/AxonOS-BCI/e7536a8421b29eba899cfea058cc0590", "published_at": "2026-09-13 06:49:38+00:00", "updated_at": "2026-09-22 23:52:46.548702+00:00", "lang": "en", "topics": ["ai-safety", "ai-policy", "ai-ethics", "ai-infrastructure"], "entities": ["AxonOS", "RFC-0009"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/why-not-trust-us-md", "markdown": "https://wpnews.pro/news/why-not-trust-us-md.md", "text": "https://wpnews.pro/news/why-not-trust-us-md.txt", "jsonld": "https://wpnews.pro/news/why-not-trust-us-md.jsonld"}}