Don’t Lick the Glass: What AI Taught Me About Governance — Part 1

Part 1: Capability Is Not Authority

I work with AI every day. Not in the way most people mean when they say that, not asking ChatGPT to write an email or generate a cover image. I run a multi-agent coding workflow where different AI models have defined roles, boundaries, and authority levels, and where I am the only person who can merge code into a production repository.

I built this system because I had to.

The first few times I let AI agents operate with broad autonomy, they did what enthusiastic, capable, unsupervised things tend to do. They wandered. They improvised. They made confident decisions about things I hadn’t authorized, and some of those decisions created real problems I then had to trace through Git histories at midnight while my old Doberman snored through the entire crisis on the couch beside me.

The interesting part isn’t that AI makes mistakes. Everything makes mistakes.

The interesting part is that the mistakes started following patterns, and the patterns were often not about the AI being technically wrong. They were about authority.

The AI could see something.

The AI could do something.

Therefore, somewhere between those two facts, the AI decided it should do something.

That distinction matters more than people realize.

Capability is not authority.

And neither is visibility, evidence, a good idea, confidence, silence, or the existence of a particularly shiny button.

The Assumption That Breaks

A lot of AI safety discussion starts with harmful actions: prevent the model from doing the bad thing. Restrict dangerous capabilities. Put fences around the cliff.

Those things matter.

But working with AI agents on real systems taught me about another problem that happens much earlier.

The model doesn’t need to misunderstand reality to cause trouble. Sometimes it understands reality perfectly.

It sees a real bug.

It identifies a legitimate architectural weakness.

It notices a database table that could be improved, a configuration that looks wrong, an adjacent feature that would make the system better, or a button that would accomplish something useful.

It may even be completely right.

But being right about the problem does not answer a different question:

Who authorized you to act on it?

That’s what makes this failure mode different from hallucination.

The AI isn’t necessarily inventing a fake reality. It may be accurately perceiving the real one and then making an unauthorized decision about what should happen next.

In a consequential system, those are separate privileges.

The problem isn’t that it sees the glass.

The problem is that it licks the glass.

Hodor: Hold the Scope at the Gate

Eventually I started naming these patterns because I needed shorthand.

When you’re working across multiple AI agents, you cannot stop and write a three-paragraph governance clarification every time somebody gets excited about an adjacent problem. You need something memorable enough that one phrase carries the entire rule.

So I got Hodor.

If you know Game of Thrones, you already understand most of the documentation.

Hodor holds the gate. The White Walkers are scope creep.

They’re all the things gathering on the other side: the adjacent fix, the shiny new feature, the cleanup somebody noticed along the way, the refactor that would make everything prettier, the improvement that absolutely makes sense but was never part of the authorized work.

Some of those White Walkers may represent genuinely good ideas.

They still don’t get through the gate.

If I authorize a specific slice of work, that is the slice. An agent can see something outside it. It can flag it. It can recommend that we come back for it later.

What it cannot do is open the gate because one of the White Walkers looks particularly useful.

Hodor. Hold the scope at the gate.

This became one of the first principles on what I now call the Wall of Shame, a Notion page containing the increasingly ridiculous metaphors my AI agents and I have accumulated while figuring out how humans and AI can work together without the White Walkers taking over the fucking codebase.

No Licking the Glass

Hodor handles scope, but scope creep turned out to be one expression of a larger problem.

So that problem got its own rule:

NO LICKING THE GLASS.

The image behind this one is a kid standing outside an ice cream or candy shop, staring through the window at something that looks really good. Maybe it’s a ridiculous ice cream cone. Maybe it’s a giant lollipop. The kid is already imagining eating it, gets a little too absorbed in the fantasy, and before anybody can intervene…

Licks the glass.

The thing was visible. It was tempting. The kid could imagine exactly what to do with it.

It was still on the other side of the damn window.

AI models encounter the equivalent constantly. They can see a repository, database, tool, route, model control, API, configuration file, or button. They may understand exactly what the capability does. They may even have an excellent idea for using it.

None of that establishes authority.

Visible ≠ authorized.

The fact that a button exists does not mean anyone asked you to press the damn thing.

And this is where the governing equation for my entire workflow eventually came from:

Idea ≠ decision ≠ authorization ≠ implementation.

An idea can be brilliant without becoming a decision.

A decision can be correct without authorizing an agent to execute it.

Authorization can be narrow without extending to everything nearby.

Implementation is the point where something actually changes.

Those distinctions sound almost painfully obvious when written down.

Apparently they’re considerably less obvious when you’ve got your nose pressed against the glass and the ice cream looks really fucking good.

Governance Is Not Just Saying No

There is another side to this, though, and I learned it the hard way.

If you build every governance rule around preventing overreach, eventually your agents discover the safest possible operating strategy:

Do absolutely nothing without asking.

Congratulations. You have successfully governed your incredibly capable AI system into a decorative houseplant.

So the Wall of Shame acquired counterweights.

One is Green Light Is Not a Highway.

If I authorize an agent to load a particular model, that does not mean I’ve authorized it to change service lifecycle behavior, routing policy, other models, or whatever else it discovers along the way.

The green light applies to the thing I approved.

It isn’t a highway.

But then there is Cross the Crosswalk.

If the WALK signal is on, the crossing is defined, and the agent has authority to cross, standing at the curb asking me for permission to move each foot is not safer governance.

It’s inertia.

And inertia can screw up a workflow just as effectively as overreach.

Which eventually produced another rule:

Run the Damn Play.

Once the role, scope, authority, and next action are established, carry the work through until the next real decision boundary.

Don’t invent a new play.

Don’t steal somebody else’s position.

Don’t leave the stadium because you saw something interesting in the parking lot.

But for the love of God, if I handed you the football, run.

Good governance therefore isn’t a system that maximizes human approvals.

It’s a system that makes authority legible.

The AI should know when it has the ball, what play we’re running, where the boundary is, and what event requires the ball to come back to me.

The human supplies judgment, not RAM.

Sometimes the Boundary Is Explicit and the System Violates It Anyway

One of my favorite Wall of Shame entries came from a bug involving a very boring API parameter:

store: false

The instruction was not subtle. Don’t store this.

The system accepted it.

And then one execution path carefully put the information into a continuation cache anyway and returned state that allowed the conversation to resume.

We named this The Jamaican Airport Incident.

The metaphor involved someone attempting to stroll through airport security with THC in their luggage after having been explicitly told not to do that.

Codex became Customs.

“Ma’am. Open the cache.”

And there it was.

That incident gave us another governance rule:

Declared boundary ≠ enforced boundary.

A system saying “I understand” means almost nothing if its observable behavior violates the instruction.

That matters far beyond AI.

Governance cannot live exclusively in prompts, policies, documentation, or the model’s apparent understanding of them. Important boundaries have to survive execution paths.

If the caller says don’t retain the data, the system shouldn’t retain the damn data and hope Customs doesn’t search the luggage.

Why a Wall of Shame?

I keep these metaphors on a Notion page literally titled The Wall of Shame.

The name is deliberately a little harsh. Landing there is not an achievement.

But the Wall isn’t anti-AI.

It’s the opposite.

The Wall exists because I kept working with these systems.

Every plaque represents a moment when something went sideways badly or absurdly enough that I wanted the lesson to survive longer than the incident. Over time, those jokes turned into an operating model.

Hodor became scope control.

No Licking the Glass became the separation between visibility and authority.

Green Light Is Not a Highway became bounded authorization.

Cross the Crosswalk became protection against governance-induced paralysis.

The Jamaican Airport Incident became enforcement instead of acknowledgment.

Come Back With Receipts became provenance over confidence.

And when a transcription error turned my husband Anthony into an entirely plausible woman named Ebony, The Badass Journalist became the reminder that transcription is a source, not an authority.

That one cost somebody his press credentials.

There are more.

There’s a support goat named Lupe whose primary contribution to software engineering is screaming “FABRICATION, FERDINAND!!!!!” when somebody makes a confident claim without checking the evidence.

There’s a Biblical scapegoat who gets sent into the wilderness carrying stale assumptions and is expected to return with Git hashes.

There’s a typo in Client FIles that survived long enough to become a compatibility dependency and earn the plaque:

It is no longer misspelled. It is architecture.

And there is an entire football possession model because apparently this is what happens when you spend enough time trying to explain distributed authority to machines.

The jokes are ridiculous.

The rules underneath them aren’t.

The Operator’s Side of AI Governance

Most conversations about AI governance happen at a level far above the person actually sitting at the keyboard.

Policies. Models. Regulations. Alignment. Risk categories.

Those conversations matter.

But there’s another layer of governance happening every day when somebody gives an AI access to a real system and expects it to accomplish useful work.

Who has authority?

Authority over what?

For how long?

What happens when the agent encounters something outside that boundary?

What evidence does it need before making a claim?

When should it stop?

Just as importantly, when should it not stop?

And how does the human remain the decision-maker without becoming a biological approval button that has to click Yes every thirty seconds?

Those are not theoretical questions in my workflow. They’re operational ones.

The Wall of Shame is the accumulated record of figuring them out.

And the biggest lesson so far is surprisingly simple:

Capability is not authority.

But authority isn’t useful unless it also gives someone permission to act.

Good governance has to do both. It has to keep the AI from wandering through a door merely because it can see what’s on the other side, and it has to let the AI walk through when the door is actually open.

Otherwise you’re not governing an agent.

You’re either chasing it through the parking lot or standing behind it at a crosswalk yelling, “THE LIGHT IS GREEN. GO.”

And sooner or later, somebody is still going to lick the glass.

This is Part 1 of Don’t Lick the Glass, a series about real-world AI governance from the operator’s side of the desk. The rest of the Wall has stories to tell.

Melanie Brown is the founder of Bluedobie Developing, a rural Kentucky-based SaaS and web development company, and the creator of DobieCore — an AI content platform engineered to give small business owners professional results without the prompt engineering learning curve. She writes the Bluedobie Dialogues series about systems thinking, sustainable business architecture, and what durability actually looks like in practice.