The "Meat Proxy" Problem: Why Unread AI Output Is a Security Risk

Developer Niklas Gruhn recently put a name to a pattern most security and engineering teams will recognise: the meat proxy — a person who takes an AI system's output and relays it to someone else unread, unverified, and unedited. Simon Willison called it "an excellent new term" and it's worth taking seriously beyond the workplace-etiquette angle, because in security work the unread middle step is exactly where things go wrong.

What Gruhn is describing

In his original post, Gruhn gives concrete examples: answering a Slack question by pasting an LLM's response, leaving pull-request feedback generated by AI, or settling a WhatsApp group debate with an unedited chatbot reply. His sharpest example is a code-review workflow where a ticket description goes straight into an AI coding assistant, the output ships without genuine review, and any correction comes from further prompting rather than the engineer's own understanding. His summary is blunt: "By all means, prompt AI. But don't just relay the output. Read it, understand it, validate it, and then write a response in your own words (a decent certificate that you've done the prior steps)."

Why this matters for security teams specifically

Most write-ups on this topic treat it as a productivity or courtesy issue — wasted reader time, low-effort communication. For security practitioners, the stakes are higher, because the artefacts being relayed often gate a decision:

• Code review — an AI coding assistant's output merged on the strength of the assistant's own confidence, not a reviewer's understanding, is exactly how insecure patterns and unvetted dependencies slip into a codebase.
• Vulnerability triage — an AI-generated severity or exploitability assessment forwarded to a client or a dev team as-is, without a human checking it against the actual environment, can under- or over-state real risk.
• Incident response — a runbook step or root-cause summary pasted from an LLM into a live incident channel, unverified, can send responders down the wrong path at the worst possible time.
• Advisories and reports — relaying AI-drafted analysis of a CVE or breach without checking it against primary sources risks repeating a hallucinated detail as fact.

Gruhn's point about a "certificate" is the useful part here: writing a response in your own words isn't busywork, it's the evidence that verification actually happened. Without it, there's no way for a colleague, a client, or an auditor to tell a validated judgment from a forwarded guess.

What to do about it

None of this argues against using AI in security workflows — triage assistance, draft advisories, and AI-assisted code review are all legitimate uses. The discipline is procedural: treat AI output as a first draft that requires a named human to read it, check it against the source (the codebase, the CVE record, the log data), and only then pass it on in their own words. That single step is cheap compared to the cost of an unreviewed vulnerability call or a merged AI-written vulnerability.

A note on where this discussion is happening

Willison's post links onward to a Lobste.rs discussion where developers are already debating the boundaries — for instance, whether a well-edited AI draft that the sender has genuinely checked still counts. That's a useful signal: the community consensus forming here is about verification, not about banning AI tools outright.