This week: thirteen policies, one enabled, and the difference between a rope and a wall

The weekly edition works like this: what I'm doing, what I'm watching, what you should do about it, and one meme. Paid members get the playbook at the bottom. Let's work.

On the bench

Three things this week, and they turned out to be the same thing wearing different clothes.

I spent part of the week inside an organization's security tooling running an assessment. Their console listed thirteen data-loss-prevention policies. Real names, real intent, sensibly aimed at the things a company that size should worry about. One of the thirteen was actually enabled. The rest sat in simulation mode with notifications switched off, which means they watch quietly and tell nobody. Six of the thirteen had no rules inside them at all: named containers with no conditions, structurally incapable of firing under any circumstance.

Nobody lied and nobody was lazy. Someone in the seat before the current team stood most of it up a couple of years ago, turned it on, and moved to the next fire. Everyone who inherited the list read thirteen policies and reasonably concluded the company had data protection. The list was real, and the protection on the other side of it was mostly decorative.

That finding rearranged how I spent the rest of my week, because I went looking for the same shape in my own systems and found it twice.

My field-services business has an outbound message engine that texts and emails customers. It used to be governed by a single file: if the file said sending was enabled, the system would send. This week I tore that out and replaced it with something meaner. Now every lane, customer texts, past-customer texts, past-customer email, needs its own signed authorization artifact that expires in twenty-four hours. It isn't a flag I set once and forget about; it's a lease that dies on its own unless somebody deliberately renews it. And if the artifact goes missing, the system treats the absence as a revocation and refuses to recreate it. The old global switch is still sitting on disk, and the new code explicitly gives it no authority, so it cannot turn anything on anymore because nothing reads it.

The third one is a research system I'm building that runs market experiments with no money at stake. The obvious way to keep it from trading real money is a config setting: live_trading = false. I wrote the rule differently. The repository's constitution says a process must be unable to trade because the capability does not exist. There is no broker client, no wallet interface, and no dormant credential slot waiting for someone to fill it in. It isn't a locked door so much as a room nobody has cut a door into yet. If I ever want that capability, I have to write it, and writing it is a decision somebody has to make on purpose at a keyboard.

The same lesson showed up three times in one week. A setting is a promise about behavior; a structure is a fact about capability. The thirteen-policy console was full of promises, and everyone who looked at it saw facts.

The gauges

Three things I watched this week, and what I actually think.

A security researcher put clean language around the thing I kept bumping into all week. Chris Hughes published a breakdown of a new paper on agent isolation: Agents Have Boundary Issues. His framing is soft guardrails versus hard boundaries. Soft guardrails are instructions, system prompts, and training, all probabilistic, all capable of being talked out of their behavior by anyone sufficiently motivated. Hard boundaries are permission systems, sandboxes, and network rules that sit outside the model and do not care how persuasive the text is. Should you pay attention? Yes, and it is the single most useful vocabulary upgrade I picked up this month. Most of what small businesses call "guardrails" on their AI tools are soft: a line in a prompt saying don't email customers without asking. That is a request, not a fence. The line I keep coming back to is his source paper's claim that safety improves when boundaries are enforced structurally rather than left to prompt instructions. Ask which kind you have. If your only answer is "I told it not to," you have a rope.

Microsoft published guidance on least privilege for AI agents, and buried the most relatable sentence in the middle. Least privilege for AI agents: identity, access, and tool binding. The scenario they describe: a team gives an agent a broad read-only role because it is fast and the use case looks harmless. Then the work grows to include fixing what it finds, so it needs write access, and rather than redesigning the role they grant something broader and move on. Their words for how it goes wrong are "quiet, incremental, and rarely revisited." Should you pay attention? Yes, because that is not an enterprise problem, that is a Tuesday. The small-business version is handing your assistant your admin password because the read-only account could not do the one thing you needed at 9pm. The enterprise version has a change-review board and still ends up here. You have no board. Assume you drift faster, not slower.

An operator on r/agenticAI ran an unattended agent against real infrastructure and wrote up what it could not do. My unattended agent hits a permission wall every single time and stops. That's the feature. Real cluster, not a sandbox, doing scheduled restore tests to prove the backups would actually come back. The interesting part of the writeup is not the automation, it is the author treating the wall his agent slams into as the product rather than a bug to file. Should you pay attention? Yes, and mostly as a permission slip. Everyone building with agents right now feels a low hum of embarrassment when their system stops and asks. It reads as unfinished. It is not unfinished; it is the only part you can point to when someone asks what stops it. I would go one step further than he does: the wall only counts if the agent cannot route around it. A stop the agent can argue with is a suggestion.

Your move

Fifteen minutes this week. Get a sheet of paper and make two columns.

Left column: every meaningful thing your AI tools, automations, or agents are technically able to do. Send email as you. Text customers. Move money. Change prices. Delete files. Post publicly. Read the whole shared drive.

Right column, for each one, write what stops it from happening at the wrong time. Then look at what you wrote and sort it honestly into two buckets. Bucket one: something structural stops it, meaning the credential does not exist, the integration was never connected, the account has no permission, the code path is not written. Bucket two: a setting, a prompt instruction, a checkbox, or a habit stops it.

Everything in bucket two is a rope. Ropes are not worthless, and some of your ropes are fine where they are. But you now know which of your controls survive a bad afternoon and which ones survive only as long as everyone stays careful. If a line in bucket two would end a customer relationship or cost real money when it fails, that is your project for next week. Move exactly one item from bucket two to bucket one, and pick the expensive one, not the easy one.

The meme

Thirteen policies on the list. One of them armed. Twelve buttons nobody pressed.

The playbook: the setting-versus-structure audit

Operators: this is the audit I ran on my own stack after the thirteen-policy console rearranged my week. It converts soft controls into hard ones in the order that matters, and it is deliberately boring. Run it against anything with your name on the outbound side: agents, automations, integrations, a virtual assistant with your logins, a scheduling tool with your calendar.

1. Inventory capability, not intention. Write down what each system can do, not what you set it up to do. The gap between those two is where every surprise lives. The practical version: open the integration's permission screen and read the granted scopes out loud. Most people have never done this once. You will find at least one tool holding a scope you never consciously granted, usually because it came bundled in a login prompt you clicked through eleven months ago. Bundled scopes are the small-business version of the quiet, incremental role creep Microsoft describes, and there is no security team to catch it.

2. For each capability, name the thing that stops it, then classify it. Structural stops: no credential exists, the account genuinely lacks the permission, the integration was never connected, the code to do it was never written. Behavioral stops: a config flag, a prompt instruction, a policy document, an approval step you added, a habit. Behavioral stops fail in three familiar ways. Someone flips the flag during a busy week. A second system reaches the same capability by a different path that never reads your flag. Or the model gets talked past the instruction, which is the entire soft-guardrail problem compressed into one sentence.

3. Hunt for the second path before you trust the first stop. This is the step everyone skips and the one that has bitten me hardest. Disabling a gate disables that gate's lane, not every lane. I once had a send gate correctly showing DISABLED while a leftover scheduled job on the same machine had been firing every sixty seconds for over fifteen thousand runs, calling the old code, which had never heard of the gate. The gate's status was accurate and meaningless. Before you trust a control, go find every other thing on your systems that holds the same credential or touches the same channel. Old scripts, old scheduled jobs, an integration you replaced but never disconnected, a vendor account you stopped paying attention to. Then kill them structurally: revoke the token, delete the job, disconnect the app. "Replaced" is not "retired."

4. Convert with the least effort that actually removes capability. Ranked by how much protection you get per hour spent. Revoking a credential or disconnecting an integration is the cheapest and strongest: five minutes, and the capability is gone. Scoping a permission down is next, meaning a separate account for the AI with only what it needs, rather than yours. Then rate limits and quiet hours enforced by the provider rather than by your code, because the provider's limit holds when your code has a bad day. Everything below that line is a rope, and prompt instructions sit at the very bottom. That last one is worth saying plainly: an instruction in a prompt is the weakest control in the entire stack, and it is the one most small businesses are relying on exclusively.

5. Put an expiration date on anything you cannot make structural. Some permissions have to stay on, and those should get a lease rather than a grant. The mechanism I shipped this week: an authorization file per channel, twenty-four hour lifetime, signed with who authorized it and why, and if the file is missing the system treats the absence as a revocation and refuses to invent a replacement. That last clause matters more than it sounds, because a control that quietly recreates itself when it goes missing is not really a control, it's a preference. The cheap version of this without writing any code is a calendar reminder on every elevated access you grant, with the default set to off. Standing access with no renewal date drifts into permanent access within a month, every time.

6. Test the boundary the way an adversary would, which mostly means the way a busy Tuesday would. Do not test whether the control works when everything is normal. Test the three states where it fails. What happens when the system cannot tell whether an action succeeded? What happens when two components disagree about whether sending is allowed? What happens when someone asks the agent to do the forbidden thing with a plausible business reason attached? A boundary that only holds under polite conditions is a rope with good posture.

7. Write the sentence you would say out loud. For every capability that could embarrass you, finish this: "It cannot ___ because ___." If the second blank is a noun, meaning no credential, no connection, no permission, no code, you are done. If the second blank is a verb about someone's future behavior ("because I check it," "because it's set to off," "because it's told not to"), you have found your next project. That sentence takes ten seconds and is the most honest security review most small businesses will ever run.

Steal this: the thirteen-policy console was not a security failure at the moment it was built. It became one the day everybody started counting policies instead of counting enforcement. Whatever you have that shows a list of protections, your AI tool's safety settings, your automation's approval steps, your permissions page, count the ones that are actually armed and write that number down next to the total. The gap between those two numbers is the real inventory. Everyone else is reading the bigger number.

Hit reply and tell me what's on your bench this week. I read every one.

— Justin