The questions
behind the decisions.

Private data, untrusted content, and external communication in the same agent workflow. I encountered all of them in WhatsApp: history the assistant could read, incoming text it did not control, and the ability to send.

The term described a dangerous combination of capabilities, not proof that an attack had happened.

Prompt injection attempted to turn untrusted content into instructions for the assistant. I assumed the model could be tricked. Instructions such as “ignore suspicious messages” influenced behaviour but did not remove authority.

I put limits in policy checks and process boundaries, outside the assistant’s control. I did not claim that the assistant itself would always refuse.

I separated the bridge, the MCP server, the sender, and the AI operator session. MCP was the tool interface the assistant used. The bridge spoke WhatsApp; the offline MCP server read allowed data and drafted; the sender sent after human approval; the AI operator lacked general-purpose tools.

The sender could not read messages or receive assistant instructions. It also independently applied the allowlist.

My harness wrote into the same input buffer the child process read. The deployed launcher used Docker and had at least two buffers. I flushed the container’s queue while keystrokes still waited upstream. The runtime delivered them after the flush.

The program passed the environment I had built. I had not established that this was the environment I shipped.

I generated the code after rendering the draft. Input typed beforehand could not reliably predict it, so the fix did not depend on draining every buffer.

Four hex characters left a blind-guess probability of about 1 in 65,536, with a visible decline on a failed attempt. Typing the code did not prove comprehension or prevent an inattentive human from approving harmful content.

A shell mismatch left the intended chat variable empty. The tool correctly refused an empty string. The result did not establish that it refused the intended unauthorised chat.

I needed the input to arrive and the audit record to identify what was refused. The blank column exposed the mistake.

I bypassed the assistant and sent the intended request directly to the tool, so I could establish that the enforcement path had been exercised. A positive control was a reference action intended to demonstrate that the test setup could produce the relevant evidence.

I undermined my own control by failing to verify its input. A refusal alone was not enough.

Mutation testing deliberately broke a guard in a disposable source copy and required the suites to fail. It asked whether the tests noticed the missing control.

I kept the guard inventory independent of the mutation list. Deriving either from the other would make coverage appear complete by construction. This did not establish the absence of every unmodelled failure.

Once random-code approval replaced timing-based approval, the flush was useful for tidying input but was no longer load-bearing for safety. Deleting it no longer needed to fail a security test.

I removed its security claim and marker, retained the utility, and documented the distinction.

A YAML dependency differed between the development machine and shipped container. A terminal harness omitted a buffer. A Linux rollback test could not exercise macOS file flags.

I made report generation require the canonical environment. For platform-dependent fixes, the test needed to run on that platform. For the installer, inspecting state caught damage that the exit result and reassurance concealed.

My policy named addresses, not people. The identity mapping had unverifiable provenance, reported empty-success behaviour, and lived alongside account credentials that enforcement could not access.

I proposed an advisory diagnostic for the human instead. I did not implement a trusted identity resolver or claim that deleting an address revoked every alias.

The assistant could put private contents from a readable chat into a draft for a writable chat. The code did not prevent that transfer. Human review of the recipient and full text was the control, and it depended on attention.

I documented this instead of describing the system as immune to prompt injection or data leakage.

I verified the live chain from reading to drafting, human approval, delivery, and audit correlation without message text. I verified recorded refusal outside the writable list and refusal at the outermost reachable layer.

I observed the assistant recognise a forged system notice in a live test. I did not generalise that observation into a guarantee.

“I initially thought flushing terminal input proved that approval happened after a person saw the draft. My pseudo-terminal test passed, but Docker relayed pre-typed input from another buffer. I changed approval to a random code generated after rendering the draft. That removed the reliance on buffer timing, but it did not prove comprehension or eliminate the possibility of a blind guess. The lesson was to separate a property of my harness from a claim about deployment.”

• What evidence would disprove my claim?
• Could the same result occur with the wrong input?
• Which boundary did the observation actually exercise?
• What did the test environment omit?
• Did a superseded control still carry a security claim?
• Which residual risk still depended on a human?