In 2012 I was compelled by breaches I was investigating to give talks around the world, on the threat to data integrity. One of those talks described the rise of automation systems that would behave like the Loch Ness Monster, where the quality of information would kill the profit.

In other words we risk an unresolved/corrupted state becoming more valuable to vendors than the resolved one. Users delegate because they lack expertise or time to verify. Vendors structurally benefit from that gap. Resolution never comes, because that would end the ruse.

Tesla “AI” has killed many people with exactly this fraud. The car is sold as resolved autonomy. The driver delegates because they trust Elon Musk. The gap between what the system actually does and what he tells them it does is where the bodies pile up. DOGE AI is worse. The same fraud applied to federal systems, killing hundreds of thousands.

And now a new Microsoft paper examines 52 domains, 19 models, parsing pipelines, and backtranslation theory to prove that the “telephone game” at children’s birthday parties is real.

LLMs Corrupt Your Documents When You Delegate

Information passed through enough lossy nodes degrades to noise. Water is wet. End of story? Not really, because people still don’t believe in drowning. This post is about the science of describing the dangerously wet properties of water.

Vendors are selling LLM-mediated workflows as lossless. It’s a lie. You delegate the work and you don’t get your work back. You get something that looks like your work. The paper measures how much it isn’t, at scale. The phenomenon is far older than computing. The industry measurement is the contribution.

Every interaction is a translation. Translation has loss. Chained translation compounds loss. None of this is novel. The novelty is that AI behaves like a rumor mill while vendors sell it as a query platform. Databases have ACID guarantees, checksums, replication consistency. Breaches are detectable and the system tells you. LLMs have plausibility optimization. Breaches are designed to be undetectable because detectability would break the product. Treating one as the other is the category error. Selling one as the other is the fraud.

Why are frontier models corrupting so much data? Confidence is the product. RLHF rewards outputs that read as authoritative, and authority means smoothness. A model that flagged its own uncertainty at every edit would be unusable as a delegate. So the training pressure runs the other way: produce something plausible, deliver it cleanly, do not interrupt the user’s workflow with doubt. Better players in the telephone game produce more confident-sounding distortions, not more accurate transmissions. The kid who whispers “I think she said something about a dog” is more honest than the kid who confidently states “the elephant went to Paris.” Frontier models are the confident kid. They are rewarded for being confident and wrong.

This is where the Loch Ness pattern I presented in 2012 is most useful. The user delegates because they lack the time or expertise to verify. The model produces output that looks like the work. The user moves on. The corruption is detectable only by someone running a parser against a known seed, which is to say: only by the researchers who built this benchmark. Everyone else operates downstream of silent damage. The unresolved state of “did the model preserve my document or not” is structurally more valuable to the vendor than the resolved state, because resolution would surface the failure rate and end the sale. The product depends on the user not being able to check.

Leaded gasoline ran on the same logic. The harm was real, the measurement was suppressed, and the product depended on the public being unable to prove what it was being told didn’t exist.

Degradation is not gradual. Models maintain near-perfect reconstruction across most rounds, then drop 10-30 points in a single interaction. Sparse, severe, invisible to anyone without a reference seed. By round 20, 86-95% of relays across all tested models have experienced at least one critical failure. Stronger models do not avoid the failures. They delay them, which extends the period during which the user trusts the system before the artifact breaks.

The corruption is not random. It drifts toward training distribution. The palm tree becomes a generic tree-shape. The Manet becomes a generic café scene. The 12-shaft twill becomes patterned fabric. Whatever made the original specific – the cultural particularity, the technical precision, the structural integrity of the source – erodes toward training-set average. Delegated editing is structurally a homogenization process. Specificity dies first because specificity is what models have least of in their priors.

More translation steps, more loss. Anyone who has run signal through a chain of analog effects pedals knows this. Each stage adds noise floor. Vendors are selling pedalboards as mastering chains. Adding tools degrades performance by an average of 6%. The harness consumes 2-5x more input tokens, models invoke 8-12 tools per task, and they prefer file rewriting over code execution in domains where code execution would be safer. GPT 4.1 uses code for only 10% of edits; GPT 5.4 reaches 45%. Agentic systems are inducing the long-context degradation they were supposed to escape, and being sold as the solution to it.

Anthropic, OpenAI, and Google cannot stop integrity breaches without breaking the thing they sell. xAI is engineered as the opposite of integrity. Data corruption is not something they want to, or even can, patch. It is the structural property of plausibility optimization. Imagine a privacy policy with that disclaimer. Oh, wait. That’s Facebook.

Microsoft has published an “agent governance toolkit” that promises to make AI safer with identity, audit, and policy enforcement. The code does not deliver, however, because the authentication functions are disconnected. Let me explain where and how.

One Header, One Flag

This Microsoft toolkit is supposed to be a security checkpoint that sits between AI agents and the things they do. It has to verify the agent is who it claims to be before deciding what the agent is allowed to do, let alone logging what the agent did. But it doesn’t verify.

Welcome to what I noticed at commit 573f989.

The Go port of agentmesh exposes an HTTP middleware. The middleware reads an HTTP header into a struct field, and that struct field becomes the agent identity every downstream governance check trusts.

curl -H "X-Agent-ID: McLOVIN" <your-mcp-endpoint>

The audit log records the action under agent “McLOVIN,” while the rate-limit bucket counts against agent “McLOVIN” and the policy decision is attributed to agent “McLOVIN.” One header is one flag, and the entire chain of governance attaches to whatever string the caller chose to send.

The code lives in packages/agentmesh/middleware.go at line 241. The header flows directly into GovernedOperation.AgentID, with no authentication call anywhere on that path.

Five Ports, One Property

Across five languages, an agent’s claim about who it is becomes the system’s belief about who it is, with no verification step in between. Four of them accept the agent ID directly from caller input at the request entry point. All of them export a verify_peer-shaped trust primitive that production code never calls:

Port	Entry-point ID source	Auth	Trust	Live callers
Rust	pub agent_id: String on DTO	None	TrustManager::verify_peer	0
Python	agent_id: str method parameter	None	MCPSessionAuthenticator, MCPMessageSigner	0
TypeScript	config.agentId at SDK construction	None (delegated to embedder)	TrustManager.verifyPeer	0
.NET	required string AgentId; integration falls back to literal “did:mcp:anonymous”	None on core entry points	TrustVerifier.VerifyPeer	0
Go	X-Agent-ID HTTP header	None	TrustManager.VerifyPeer (length-only)	0

None of the ports bind a verified identity to the agent ID before it’s handed to the audit, policy, and rate-limit primitives.

Default Lie Enabled

The .NET port has the most important default. If the operator forgets to set up authentication, every action in the audit log gets attributed to the same fake identity, and the system never says a word.

The integration runtime tries three claim names from ClaimsPrincipal in order. If none match, it falls back to a caller-controlled Items dictionary, and if that is empty, it falls back to a hardcoded literal: “did:mcp:anonymous.”

Anonymous.

In any deployment that has not explicitly configured ASP.NET authentication middleware to populate one of the three claim names, every request gets attributed to that same anonymous identity. The audit log records one subject for everything. The rate limiter buckets all traffic against one key. The policy engine evaluates every action under the same subject, and so the deployment runs without any error or warning. There won’t be a log event acknowledging authentication isn’t really configured. It just sits wide open.

The operator watches the audit log fill, the rate limiter enforce, and policy decisions get recorded, yet the entire log resolves to one subject because the identity being attributed to every action is a literal string in McpGovernanceOptions.cs at line 68.

A correctly configured deployment and a misconfigured one therefore would look identical until someone spoofs a claim and the audit log records the wrong attribution.

Six Primitives, Zero Callers

It doesn’t matter that functions for security work exist when the live system never calls them. It’s like hiring security guards to wait for your phone call, in a room where they have no phone.

A workspace search for non-test callers of the security primitives in the Rust crate returns the same result for each: TrustManager::verify_peer, RingEnforcer::check_access, AuditLogger::verify, TrustManager::is_trusted, McpMessageSigner, McpSessionAuthenticator. Six security primitives, each exported, each tested in isolation, each with zero call sites in production code.

The pattern shows up in the other four ports. Five trust primitives across five languages, three of which replicate the verify-itself bug verbatim, with Go validating only key length and Python shipping separate session and message authenticators that no production caller invokes. The call-graph property is the same in every port: zero non-test callers.

No Locks, No Way

Microsoft built locks. Microsoft built doors. The doors have no way to install the locks. The MCP gateway constructor in Rust takes (config, sanitizer, rate_limiter, audit_sink, metrics, clock). The .NET constructor takes (config, sanitizer, rateLimiter, maxCallsPerMinute). The Go HTTP middleware constructor takes (rateLimiter, policyEngine, auditLog).

None of them takes an Authenticator, a Signer, or a TrustVerifier. The integration surface does not invoke the primitives, and there is no parameter on the constructors to plug one in. The primitives exist as exported symbols only, so the constructors that compose the request flow have no slot to receive them.

Verify-Peer Verifies Itself

The function meant to check whether you are who you say you are checks instead whether the local computer can sign things with its own key. Not great. It always can.

TrustManager::verify_peer in trust.rs at lines 188 to 193 takes a peer_id parameter. The parameter name has an underscore prefix, which the Rust compiler reads as “intentionally unused.”

The function generates a 32-byte random challenge, calls peer_identity.sign(&challenge), and verifies the resulting signature against peer_identity’s public key. All three steps happen in the local process. The local process signs a value of its own choosing using a key it already holds, then verifies its own signature. Any AgentIdentity passed in returns true.

The doc comment on the function reads: “Generates a random 32-byte challenge, asks the peer to sign it, then verifies the signature against the peer’s public key.”

The .NET TrustVerifier reproduces the same logic at Trust/TrustVerifier.cs lines 42 to 82, with a DID-equality precheck. The TypeScript port reproduces it at src/trust.ts lines 48 to 66. The Go port skips challenge-response entirely and validates len(PublicKey) == 32.

Audit Log

An audit log that does not survive a restart and breaks its own integrity check under normal load is not an audit log. It’s barely even a log.

The Rust AuditLogger holds entries in a Mutex<Vec<AuditEntry>> at audit.rs line 16, without any persistence layer. A process restart will wipe away every record from before the restart.

When with_max_entries(N) is set and the buffer overflows, entries.drain(..overflow) at audit.rs lines 62 to 69 removes entries from the front of the chain. After the drain, the new index-zero entry has a non-empty previous_hash field, while AuditLogger::verify at audit.rs lines 78 to 103 requires index-zero to have an empty previous_hash and returns false on that check.

The audit log silently transitions from “tamper-evident” to “always reports tampered” under a normal operating condition: buffer full. There is no checkpoint, no rotated-out signed root, no recovery path. AuditLogger::verify has zero non-test callers anyway, so the chain integrity check that breaks on eviction is never invoked from production code regardless. The audit subsystem ships an integrity primitive that nothing calls, that breaks under normal load, against an in-memory store that does not survive process restart.

Whack-a-crate

Fix the bug in one place and it stays unfixed in the other.

agent-governance-rust/agentmesh-mcp/ is byte-identical to agent-governance-rust/agentmesh/src/mcp/. Twelve files, every one matching under diff -q. The agentmesh-mcp directory ships to crates.io as agent-governance-mcp per its Cargo.toml, and no build script enforces sync between the two locations. Every finding in the mcp tree exists in two crates that ship to crates.io independently. A patch that fixes the agentmesh tree does not fix the agentmesh-mcp crate unless the patch is mirrored.

Different Surface, Same Class

Enclave’s writeup of CVE-2026-32173 documents an authentication failure in Microsoft’s Azure SRE Agent. The /agentHub WebSocket endpoint required a token to connect, and the underlying app registration was multi-tenant, which meant any Entra account from any company anywhere could obtain a valid one. The hub checked that the token was valid and that the audience was correct. It never checked that the caller belonged to the target’s tenant. Once connected, the hub broadcast every event to every client with no per-message identity filter.

A check that ran every step except the only one that mattered.

The agentmesh codebase shows the inverse: checks that would have mattered, written, exported, tested, and never invoked from any production path. Same class of bad architecture, two presentations.

The category here is AI agent governance, and the structural property is that the security surface and the integration surface drift apart unobserved. A review of the security surface finds primitives that look correct in isolation. A review of the integration surface finds caller-asserted identity strings flowing into audit, policy, and rate-limit consumers. Neither covers the gap between them.

What This Means For You

If you have this toolkit in production, check the audit log.

The agent ID it records comes from caller input. Nothing on the request path verifies that the caller is the agent it claims to be. An attacker spoofing the header gets attributed to whichever identity they chose to send.

Hand this to an auditor in the .NET case with default configuration and you are handing them a single-subject log of every action regardless of caller. The store behind that log is in-memory, does not survive a process restart, and breaks chain integrity on overflow. The trust primitives the marketing describes are in fact written, tested, and imported. No production code path calls them, so they may as well not exist.

This is the failure pattern to watch for in every AI agent governance product, not just this one.

Vendors are racing to ship “zero-trust identity” and “cryptographic verification” for agents because the OWASP Top 10 for Agentic Applications calls out Identity and Privilege Abuse (ASI03) and procurement asks vendors to demonstrate the mitigation. The primitives are the easy part. Wiring them into the request flow such that they actually run before audit, policy, and rate-limit consumers see the agent ID is the part that does not happen by accident.

What To Do

Audit any deployment of this toolkit for three things.

First, find every path where an agent ID enters the system from caller input (HTTP header, request body field, method parameter, SDK construction config) and confirm whether anything between that input and the governance consumers verifies the caller. In any deployment that follows the toolkit’s documented integration pattern, the answer will be no.

Second, in the .NET integration, do not rely on the default ClaimsPrincipal probe. Configure ASP.NET authentication middleware explicitly, populate one of the three claim names the toolkit reads, and treat any appearance of “did:mcp:anonymous” in your logs as a configuration alarm rather than expected output.

Third, do not treat the in-memory audit log as durable evidence. If you have a compliance obligation that touches agent activity, route audit entries to external persistent storage on write, not via post-hoc export. The chain integrity check is broken under normal operation, and nothing calls it anyway.

If you are evaluating any AI agent governance product, send an unsigned request to the running system and see if it’s rejected.

The test suite proves only isolation. A real test proves the primitive runs when a request arrives. A review focused on either surface alone misses this. I had to look across both to see it.

The Class Remains

The agentmesh toolkit ships authentication primitives in every language port with zero production callers in any of them. The verify_peer primitive in three ports signs values it chooses with keys it already holds and verifies its own signature. The audit subsystem is in-memory only, breaks chain integrity under normal load, and has zero callers of the integrity check. The same crate ships twice. Patches will close specific paths while the class remains open.

Nothing to see here. Move along.

The FBI director was arrested twice in his youth for alcohol-related incidents that he said were “not representative of my usual conduct.”

Talk about a low bar.