The gate that named the wrong door

I run the same safety rules in two AI clients. The second one calls its tools by different names, and my rules check the name. So two gates had been quietly inert there for weeks, including the one that inspects content before it leaves for someone else. In the same period I had removed the confirmation prompt that was standing behind it.

I work in two AI coding clients now. The rules live in one place, on purpose: the same code decides whether to nudge me to search my own memory before reaching for the web, and whether to inspect a message before it goes out to a third party. One brain, two front ends. That was the design and I was pleased with it.

The rules work by looking at which tool is about to run. A gate that inspects outbound content has to know that this particular call is the one that sends. So it matches on the tool’s name.

The second client does not use the same names. Where the first says one thing, the second says another, with a different separator and a different order. Nothing errors. The gate receives a name it has never heard of, finds no match, and allows the call. Allowing is what it does all day; that is the normal, healthy path. There is no log line for a gate that had nothing to say.

I only found it because I stopped inferring the names and captured them. Not read from documentation, not guessed from the pattern: printed from a live call in that client, both directions, and compared against what my code was matching on. Two gates had been dead there. One was the memory nudge, which is a courtesy. The other was the outbound check, which is not.

The part that makes me wince is the timing. Days earlier I had made that client stop asking me to approve its own tools, because approvals were keyed per project and every new folder re-prompted me for things I had already trusted a hundred times. A reasonable convenience. What I did not know is that I had just removed the last human standing between a draft and a stranger, in the one client where the automatic check happened to be blind.

Both halves looked fine in isolation. The gate was armed in the source. The convenience was scoped to my own servers. Neither review would have caught the other.

Two things I keep. A gate that names something the client cannot resolve is not a weak gate, it is no gate, and in the source it is indistinguishable from a working one. Names crossing a boundary have to be captured from the live boundary, because a vocabulary is not a thing you can reason your way to.

The second is about removing friction. When I take away a confirmation step, the honest question is not whether the step was annoying. It is what else was checking, and whether I have verified that it still works in the exact place I just made smoother.