Coding-agent hard limits belong in scoped credentials and CI checks outside the system prompt

The problem starts with the channel. A system prompt, the user's messages and the output of every tool call all land in the same context, and the post says the rules in that text have no separate enforcement path ^[4]. Models are trained to follow instructions and also to be helpful. When those goals collide, according to the post, helpful often wins ^[1]. A determined user, a long thread or a cleverly worded task can dilute or override a rule the team thought was hard-coded ^[2].

The quieter failure needs no adversary. Each change to tone, each new workflow and each block of pasted context edits the same text that was supposed to hold the policy ^[3]. "If your safety depends on the model remembering to behave, you don't have a control plane. You have a suggestion," the author wrote ^[14].

The fix is sound because it puts the rule where the model's output cannot change the result. If the agent's credentials cannot run git push --force or read production secrets, the prompt does not need to ask it to refuse ^[8]. Before a merge, a delete or any contact with production, the post puts a policy check or a human approval step in the way, one the model cannot skip by rephrasing the request ^[9].

For that to hold, the check has to sit on the only path to the action. A deny list on one tool does little if the same agent also holds a shell and a broad token. The post lists scoped credentials in its first bucket, next to allowlists and deny lists, and adds limits on repos, branches, environments and file paths ^[7]. In my view the credential is the stronger of those controls, because it binds the agent whichever tool it calls.

The operational objection is the weakest of the three. The post says a new prompt rule cannot go to 5% of agents, be measured against bad tool calls and roll back in one click, because changing a prompt usually means redeploying config for everyone ^[5]. Its own starter set then tells teams to ship a prompt-driven config behind progressive release: small, observable, reversible ^[18]. That describes a habit teams could change. The audit objection holds up better. An external control can log a deny, a blocked tool call or a failed policy check. A sentence the model ignored in a 2,000-token system message tends to surface only as "the agent did a weird thing" ^[6].

"Judgment without measurement is optimism," the author wrote ^[15]. The post does not report failure rates for prompt-only rules, or before-and-after figures from a team that moved them. Its instrumentation list is where those numbers would come from: blocked tool calls, policy denials, failed tests after agent pull requests, and rollback events ^[11].

The prompt keeps a job. Style, priorities and how to reason about the task stay in it ^[12]. I think that split is correct for any agent that can merge or deploy. The post's first step is small: map every irreversible action one trusted agent workflow can take, then move the top three behind an external check ^[13].