Turning a capability off is also a decision — and ours now fails the build

Our endpoint capability registry is a closed allow-list. Nothing runs on a managed device unless that specific capability is registered, enabled, and cryptographically authorized per job. Enabling one has always required an explicit, e-signed governance record naming that exact capability — not a general policy, not a sprint approval, that capability.

In July a change disabled script execution across the platform. No board item, no record, no owner sign-off. The reasoning behind it was defensible — it was a security-motivated change, made by people acting in good faith about a real concern.

It was also a customer-facing capability disappearing without anyone with the authority to remove it having agreed to remove it.

The asymmetry we had shipped

Our rule had a shape we had not noticed: it governed adding power and said nothing about removing it. That felt natural, because adding a way to execute code on thousands of endpoints is obviously the dangerous direction.

But an MSP platform is operational infrastructure. A capability quietly vanishing is not a neutral safe default — it is a technician discovering mid-incident that the tool they planned around is gone, with no record of who decided that or why. "Safer" is a claim about a tradeoff, and a tradeoff someone else is living with is not yours to make unilaterally.

A security concern about an approved capability is a proposal. It is not an authorization to remove the capability while people are depending on it.

What we changed

• The rule is now symmetric: enabling a capability requires a signed record naming it, and disabling an already-approved one requires its own signed record naming it.
• "It is a security fix" is explicitly not an exemption. A security concern about an approved capability gets filed as a governance proposal, the same as anything else.
• The check runs in continuous integration and fails the build rather than emitting a warning. A warning is a thing you merge past at 5pm on a Friday.
• An approved capability sitting disabled with no corresponding disable record is itself a build failure — the state, not just the transition, is checked.

The general version

Most governance processes are written by people imagining someone doing something reckless. The failure that actually happened to us was someone doing something careful. The engineer was reducing risk. The process had simply never considered that reducing capability is a decision with an owner too.

If you run a platform other people depend on, it is worth asking which of your controls only point one way — and whether the direction they leave unguarded is the one where a well-intentioned person can take something away from a customer without anybody signing for it.