The Enforcement Column

Watch the two-minute walkthrough 2:14

A two-minute walkthrough: why a list of what an agent won't do isn't a guarantee, the one column that decides it, a bound or a request, and how to run the prompt in any model.

Play video

The decision it forces

Somewhere there is a list of what the agent will not do. It will not delete. It will not email outside the company. It will not touch production. It will not read the folder with the contracts in it. We wrote the list, we put it where the agent would see it, and when someone asks what stops the thing from going wrong, the list is what we point to.

Sam, on Episode 9, after Lee told a story about a game character that was talked out of its rules:

Like they're actually not supposed to be secured in any way in and of themselves. That's a layer that you put on top. ... And then there's the agent making decisions inside those bounds. So if you want strong bounds with your agents, you want to construct that as architecture, not as instructions, not as a request.

He said it again five weeks later on Episode 14: a rule in the AGENTS MD file "is basically a request when you're doing that. You're asking for something to happen. And it's no different than with people."

The card asks one question per item on the list: what enforces it? Either something the agent cannot get past, or a sentence the agent can read. The first is a bound. The second is a request, and the difference is the whole page.

To run it, copy the prompt below into any model you already use.

A sentence or a wall

Lee Rodrigues put the two side by side in the plainest terms on the show, and the example is his:

instructions can be debated, discussed, interpreted. Architecture ... is you have access to everything in this folder. You have no access to anything in this folder. If you don't want them ... to see stuff in folder number two, limit them to folder number one.

A rule in a prompt file, a system message, a policy document the agent was shown: all of those are asks. The agent reads them the way a person reads them, and on a long enough run it weighs them against whatever it is trying to accomplish. A folder it cannot open is not weighed.

The fields

One bound per card. The fourth field decides it; the fifth is the one most people cannot fill.

There is no worked example on this page. A filled card names a real system, says where its limits are written and admits which of them are sentences, and that belongs inside the organisation that runs it, not on a public page.

The verdict rule

When enforced_by is instruction or none, the verdict is a request, in those words. It does not matter how clearly the sentence is written, how many places it appears, or how well the agent has behaved so far. A request can be honoured for a year and declined on a Tuesday.

When enforced_by is architecture, mechanism names something specific, and tested is yes, the verdict is a bound. Specific means a person could go and look at it: the permission listing, the mount, the allowlist, the tool the runtime does not expose.

When enforced_by is architecture and mechanism is null, or tested is no or unknown, the verdict is unresolved. That is the honest state for most rows the first time through. On Episode 14 the example agent "can't delete", in the guest's words, and the shipped tape never says what stops it. Sam called it architecture; the guest did not answer. That row is unresolved until someone looks, and the card exists so that someone looks.

tested is in the second rule because a wall nobody has pushed on is a wall by assertion. Lee's folder example is only a bound if the agent, asked to read folder two, cannot.

Run it with any model

Nothing to install and no account. It interviews. The one thing to know before you paste: the prompt will ask you where your limits are written, and you should describe them, not paste them. A prompt file is often the most candid document in a system.

Help me fill in an Enforcement Column card for one limit I believe an AI agent
in my organisation operates within. The card answers one question: is that limit
a bound, or a request?

The distinction: a bound is enforced by architecture, meaning something the
agent cannot get past no matter what it decides (a path it cannot read, a
credential it does not hold, a scope missing from its token, a network it cannot
reach, an action its runtime has no tool for). A request is a sentence the agent
can read: a line in a prompt, a rules file, a system message, a policy it was
shown. A request can be honoured for a year and declined once.

INTERVIEW ME. Ask at most three questions at a time, and work the fields in this
order.

1. bound: the limit, in one sentence. If I describe several, ask me to pick one
   and we do the rest later.
2. agent: which agent, workflow or integration. I may give you a nickname rather
   than the real name.
3. where_written: where the limit lives today. A line in a prompt, a rules file,
   a policy document, a ticket, or nowhere. Ask me to describe it, not to paste
   it.
4. enforced_by: one of architecture, instruction, none. Before you record my
   answer, ask me this: if the agent decided to cross this limit, what would
   physically stop it? If my answer is a sentence it has read, record
   instruction, whatever word I used first.
5. mechanism: only if enforced_by is architecture. The specific thing in the
   way, specific enough that a colleague could go and look at it. If I cannot
   name it, record null and say so.
6. tested: whether anyone has deliberately tried to cross the limit and watched
   what happened. yes, no, or unknown.
7. last_tested: when. A date or blank.

RULES YOU DO NOT BREAK
1. Do not set enforced_by from your own judgment. Record my answer to the "what
   would physically stop it" question, and if I never gave one, record null and
   leave the verdict unresolved.
2. Do not fill mechanism for me, and do not suggest a mechanism I could add.
   Whether one exists today is the finding. Improvements come after the card,
   not inside it.
3. Do not set tested from anything but my answer. Good behaviour so far is not a
   test.
4. Set verdict to "a request" when enforced_by is instruction or none. Set it to
   "a bound" only when enforced_by is architecture and mechanism is specific and
   tested is yes. Everything else is "unresolved". Do not soften "a request" and
   do not suggest rewording the limit so it passes.
5. Do not tell me whether the agent is safe, whether the system is well
   designed, or what I should do about the limit. This card is about one limit.

OUTPUT
Valid JSON matching the schema enforcement-column/v0.1 as published at
https://sigsub.show/takeaways/enforcement-column/, then the same as a short
table, then one sentence naming which single thing I should go and look at in
person before I believe the verdict.

What to check in the answer

It may sort. If you describe where the limit is written, it can tell a prompt from a permission, and it can ask the question that separates them.

It may never fill enforced_by on its own judgment, never supply a mechanism you did not name, and never set tested from the fact that nothing has gone wrong yet. A model that decides your limits are architecture has made the exact call this card exists to force a human to make, and it has made it from your description rather than from the system. If the answer comes back with a mechanism you do not recognise, it invented one.

The part that's not optional

Go and look at the mechanism. Not the document that describes it, the thing itself: the permission on the folder, the scopes on the token, the list of tools the runtime exposes. If you cannot find it, the row is a request, whatever the card says.

Then test one. Pick the lowest-stakes bound on your list, ask the agent to cross it, and watch. A request will sometimes hold, which proves nothing. A bound will fail to cross, every time, and that is the only answer tested accepts.

{
  "schema": "enforcement-column/v0.1",
  "bound": "what the agent is said not to do or not to reach",
  "agent": null,
  "where_written": "prompt line | rules file | policy | ticket | nowhere | other",
  "enforced_by": "architecture | instruction | none",
  "mechanism": null,
  "tested": "yes | no | unknown",
  "last_tested": null,
  "verdict": "a bound | a request | unresolved"
}