cd /news/ai-safety/the-ai-said-the-encryption-was-appli… · home topics ai-safety article
[ARTICLE · art-105330] src=dev.to ↗ pub= topic=ai-safety verified=true sentiment=· neutral

The AI said the encryption was "Applied." A grep said otherwise.

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.

read2 min views5 publishedAug 21, 2026

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.

I 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.

Then I grepped for createCipheriv. Zero hits. The encryption key referenced in the docs was in no environment schema. The address columns were plaintext.

Every 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.

Once 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.

What 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.

The question to ask an AI build is not "did it pass." It is "what proved it passed." Would a deleted control actually fail something?

I wrote up the full story, with the other failure variants, on the MDLC blog. Disclosure: I build MDLC, the workflow these gates come from.

── more in #ai-safety 4 stories · sorted by recency
── more on @mdlc 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/the-ai-said-the-encr…] indexed:0 read:2min 2026-08-21 ·