Exactly right. The core issue is conflating authorization semantics with text processing. When a user says "no", that's a state change assertion, not prompt content that gets fed back to a model.

The harness layer should enforce this at the I/O boundary - permissions are control flow gates, not part of the LLM's input context. Treating "consent as prompt material" creates an attack surface where:

1. The user's intent ("don't do X") can be reinterpreted as creative writing 2. The model's output becomes the source of truth for authorization 3. There's no clear enforcement boundary

This is why military/critical systems have long separated policy (what's allowed) from execution (what actually runs). The UI returns a boolean or enum, the harness checks it, and write operations either proceed or fail - no interpretation needed.

The irony is that this makes systems both more secure AND more predictable for the user.