The control surface moved to the policy file
A few weeks back I almost shipped a name I had spent months keeping out of the work. Not in the code, in the chrome, the title and the metadata of a post. The drafting instructions say keep names out. I say it at the start of every session. And there it was anyway, sitting in a frontmatter field, one keystroke from a commit. I did not catch it by reading carefully. A grep in a pre-commit hook caught it, refused the commit, and printed the offending line back at me. The instruction had not held. The gate did.
I thought about that the other day, when one of the most widely used coding agents shipped two governance knobs in a single release. One lets an organization decide which models are even allowed to run, across the model picker, the command-line flag, the environment variable, all the places someone might reach for one. The other blocks a sandboxed command from reading your credential files and secret environment variables at all. Two different controls, same underlying move. The lever that decides what the agent may do stopped being the prompt and became a policy file.
That move is the whole story, and it is bigger than one release. For a couple of years now the way you governed an AI coding agent was mostly by talking to it. You wrote a system prompt. You left rules in a config the model reads on the way in. You reminded it of the constraints inside the task. All of that is surface. It proposes behavior, it does not guarantee it. A prompt that says do not read secrets is a request, and a request can be argued out of, distracted from, or injected past. A policy that refuses to hand secrets to a sandboxed process is not a request. It is a wall. Same sentence, moved from the layer that asks to the layer that enforces.
I wrote a while back about how your agent runs what it reads, how someone can slip instructions into a tool's output and the agent will run them, because it cannot tell trusted output from hostile input wearing the same clothes. The fix in that post was a gate at the boundary. This release is the platform building one of those gates for you, down at the runtime, where a prompt cannot reach in and undo it. You cannot social-engineer a secret out of an agent that is structurally not allowed to open the file. The control moved below the conversation.
the prompt proposes, the policy enforces
Here is the part worth internalizing, because it is a pattern you can use in your own vibe coding long before any vendor ships it to you. Anything you actually care about holding, you encode as enforcement, not as instruction. The instruction layer is where you express intent. The enforcement layer is where intent becomes guaranteed. If a rule lives only in the prompt, it holds exactly as well as the model's attention that turn, which is to say usually, which is to say not on the turn it matters.
This site runs on that principle, and it is the reason that almost-shipped name never reached a reader. The rules that protect the brand do not live in one place where a single miss ends it. They live in four layers, and each one assumes the layer before it will eventually fail. The drafting instructions catch most violations while a post is still being written. The pre-commit hook greps every staged file and blocks the commit on a match, which is the layer that caught the name. A validator checks the structured fields against a fixed schema and refuses anything off-list. And a periodic audit re-scans what already shipped, because the violation you did not predict is the one that slips the three gates you designed. Four independent checks for one rule. Not because I expect three of them to fail, but because I will not bet the brand on any single one holding.
None of those layers is smart, and that is the point. A grep does not understand the rule, it matches a pattern and says no. The validator does not weigh whether a category feels appropriate, it checks membership in a set and exits non-zero. Dumb, mechanical, and immune to a good argument. The release this week is that exact shape arriving at the agent runtime. The sandbox does not deliberate over whether this particular command has a defensible reason to read your secret keys. It is not allowed to, so it cannot, and no clever prompt rewrites that.
the working rule for vibe coders
So when you read that your coding agent grew a policy file, do not file it under enterprise paperwork you get to ignore. File it under the control surface moving to where you should have wanted it all along. The practical version for a vibe coder shipping real software is short. Stop trusting the prompt with anything that has consequences. Which models a teammate's agent can run, what a vibe coded script is allowed to touch, whether a secret can leave the box, those are not things to request politely in a system prompt and hope. They are things to encode in a file the runtime obeys whether or not anyone is paying attention.
Prompting is how you steer. Policy is how you guarantee. They are different layers, and the day you stop confusing them is the day your AI orchestration grows a spine. This is the same shift I called the move to infrastructure a while back, arriving now one governance knob at a time, and it is what real guardrails actually look like once you stop hoping and start enforcing. Vibe coding does not get less powerful when you put walls around it. It gets shippable.
If you are formalizing how your agents are governed, moving the rules that matter out of the prompt and into something that actually holds, and you want a sparring partner on where the gates go, work with VibeKoded.
The agent is going to keep getting more capable and more autonomous. The only question that stays the same is whether the limits on it live somewhere it can argue with, or somewhere it cannot. This week the answer moved, quietly, into a file. Put your rules there too.