{"slug": "the-ai-said-the-encryption-was-applied-a-grep-said-otherwise", "title": "The AI said the encryption was \"Applied.\" A grep said otherwise.", "summary": "An engineer at MDLC discovered that AI-generated code can silently omit security controls while all automated signals report green. In one build, 'PII encryption at rest' was marked applied in three documents, but a grep for createCipheriv found zero hits, leaving address columns in plaintext. The issue was caught by a fresh-context reviewer agent that disbelieves claims and verifies each control in the code, leading to remediation with AES-256-GCM and an integration test.", "body_md": "AI-generated code rarely fails loudly. The failure that scares me is the quiet one: a build report that says a security control is \"Applied\" when the code behind it was never written.\n\nI hit this on a real build. \"PII encryption at rest\" was marked done in three places: a schema comment, an architecture invariant, and a compliance sheet. Three documents, all agreeing with each other.\n\nThen I grepped for createCipheriv. Zero hits. The encryption key referenced in the docs was in no environment schema. The address columns were plaintext.\n\nEvery automated signal was green. The invariant that should have verified the control was marked \"manual,\" so the linter skipped it. The tests passed because they only test what exists; nothing asserts the absence of a thing that was never written. The compliance sheet passed because it echoes the spec instead of auditing the code. Greenness was self-referential.\n\nOnce you look for this pattern you find weirder versions. Another build's invariant linter reported \"0 violations\" while inspecting zero files: the model had re-derived a glob-to-regex translation and applied the wildcard replacements in the wrong order, so the pattern matched nothing. A clean pass over an empty set. Across four builds I watched, the model's first attempt at that same translation was wrong in three, each differently.\n\nWhat finally caught the missing encryption was not more tests. It was a fresh-context reviewer agent that gets the spec and the working tree, and deliberately not the builder's notes or report. Its job is to disbelieve: grep for every claimed control, file and line. It flagged the encryption on the first cycle. The remediation added real AES-256-GCM plus an integration test that reads the row straight from the database and asserts the stored value is ciphertext, so the control can never silently evaporate again.\n\nThe question to ask an AI build is not \"did it pass.\" It is \"what proved it passed.\" Would a deleted control actually fail something?\n\nI wrote up the full story, with the other failure variants, on the [MDLC](https://mdlc.ai/blog/the-control-said-applied-and-wasn-t) blog. Disclosure: I build MDLC, the workflow these gates come from.", "url": "https://wpnews.pro/news/the-ai-said-the-encryption-was-applied-a-grep-said-otherwise", "canonical_source": "https://dev.to/grepzero/the-ai-said-the-encryption-was-applied-a-grep-said-otherwise-4jdd", "published_at": "2026-08-21 00:54:20+00:00", "updated_at": "2026-08-21 01:44:02.286341+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "developer-tools", "ai-ethics"], "entities": ["MDLC", "AES-256-GCM"], "alternates": {"html": "https://wpnews.pro/news/the-ai-said-the-encryption-was-applied-a-grep-said-otherwise", "markdown": "https://wpnews.pro/news/the-ai-said-the-encryption-was-applied-a-grep-said-otherwise.md", "text": "https://wpnews.pro/news/the-ai-said-the-encryption-was-applied-a-grep-said-otherwise.txt", "jsonld": "https://wpnews.pro/news/the-ai-said-the-encryption-was-applied-a-grep-said-otherwise.jsonld"}}