Why agents ignore negative instructions

Retries and bigger models do not fix a guardrail that only exists as text. Rules like “do not use any,” “do not write outside src/,” or “do not expose a new public API” sound precise to us, but they stay soft inside the same context window as the rest of the task, so they can be primed, overridden, or simply lose to stronger semantic pressure.

The most useful shift is to move the rule out of the prompt and make it executable. For file safety, that means replacing “do not write outside allowed directories” with a path gate that runs before the tool call. The model can still be told the allowed scope, but the real control is framework code that resolves the requested path, compares it against approved roots, and throws if the write escapes them. That prevents the failure mode prompt wording cannot: a perfectly “understood” instruction that still gets violated at execution time.

function assertAllowedWrite(targetPath: string, allowedRoots: string[]): void {
  const resolved = path.resolve(targetPath);
  const allowed = allowedRoots.some((root) =>
    resolved.startsWith(path.resolve(root) + path.sep) ||
    resolved === path.resolve(root)
  );

  if (!allowed) {
    throw new Error(`Blocked write outside allowed roots: ${targetPath}`);
  }
}

Enter fullscreen mode Exit fullscreen mode

This pattern works because it turns an English policy into a binary check. path.resolve() normalizes both the requested path and each allowed root, so relative segments do not sneak past the policy. The startsWith(... + path.sep) test matters too: it avoids treating /app/src-other as if it were inside /app/src. In practice, we should pair this with a positive prompt scope like “you may edit only files under packages/web/src and packages/ui/src.” The prompt reduces wasted attempts; the policy is what makes the rule real. That is the article’s core point in miniature: prompts are guidance, harnesses are controls.

The full write-up also covers:

• why negation failures often come from priming, not misunderstanding
• the violation and inverse-scaling numbers worth remembering
• runtime tool policies for trusted and confidential content
• a retry harness that feeds checker failures back
• using review rubrics for architecture and public API changes

---

Read the full article on make-it.run →