There's an old idea from G.K. Chesterton that I think about more than almost anything else from twenty years in this work. He puts it as two people looking at a fence across a road. The first says, "I don't see the use of this. Let's clear it away." The second says, "If you don't see the use of it, I certainly won't let you clear it away. Go and find out why it's there. Then come back and tell me, and maybe I'll let you remove it."
That's it. Don't tear down a fence until you know why someone built it.
Every infrastructure and security team lives inside a version of this, and most of them get it wrong at least a few times a year.
You've seen the artifacts. A firewall rule that allows a port to a host nobody can identify. An IAM policy with a grant that looks over-broad and has no ticket attached. A cron job on a box that's been running since before anyone currently on the team was hired. A security group rule that's obviously too permissive and has been that way for years.
Someone eventually finds one of these during a cleanup or an audit, doesn't understand it, and concludes it's cruft. So they remove it. And then, sometimes immediately and sometimes three weeks later when a quarterly job runs, they find out what it was for. The fence was load-bearing. It was the one thing holding a dependency nobody had written down.
The failure mode isn't stupidity. It's the opposite — it usually comes from competent engineers doing exactly what good engineers are supposed to do: reduce surface area, remove what you can't justify, clean up.
Here's the trap. The rule looks dumb precisely because its context is gone. The person who wrote it understood a real constraint — a legacy integration, a vendor's hard-coded source IP, a compliance requirement, a 2am incident that this rule was the fix for. That understanding lived in their head, or in a Slack thread that's been deleted, or in a ticketing system three migrations ago. The rule outlived the reasoning. So what you're left with is the artifact stripped of its why, and an artifact with no visible justification looks exactly like a mistake.
There's also a particular kind of security arrogance worth naming, because I've had it myself. You come into an environment, you see an old control, and the reflex is: this is obviously wrong, whoever did this didn't know what they were doing. Sometimes that's true. But "this old rule is obviously dumb" is one of the more expensive sentences in this field, because the person who says it usually hasn't done the thing Chesterton asked for — gone and found out why it's there.
The wrong lesson to take from this is "never touch anything." That's how you end up with an environment nobody can change, where the over-permissive security group stays over-permissive forever because everyone's too scared to be the one who broke it. That paralysis is its own risk, and it's the one that actually kills teams slowly. Fear of removing the fence is not the same as understanding it.
The real fix is memory.
The reason you can't safely remove the fence is that you inherited the artifact without the reasoning. So the discipline is simple to state and hard to actually do: every time you build a fence, record why. Every change — every rule added, every policy scoped, every job scheduled — should carry its reason forward, attached to the thing itself, so the next person doesn't inherit a bare artifact. They inherit the argument.
That's what an audit trail is actually for, when it's done right. Not the compliance version, where you can prove that a change happened for the auditor. The useful version, where the next engineer can see why it happened — who made it, what it was protecting against, what depended on it. Those are the signs on the fence. They're the thing that lets the second person in Chesterton's story eventually say "alright, now that you understand it, take it down."
I care about this because the whole point is to be able to change things. An environment where every control is a black box you're afraid to touch is not secure — it's just frozen, and frozen environments rot.
You can remove the fence once you can see why it was built. That's the whole trick, and it's not caution and it's not courage. It's institutional memory that survives the person who had it. If the reasoning travels with the change, the next person isn't guessing. They're deciding — with the same information the original builder had.
Most of the bad infrastructure decisions I've watched happen weren't reckless. They were made by people who genuinely couldn't see the fence for what it was, because nobody left them a sign.