I Can Build the Thing

I Can Build the Thing

Sailboat resting on stands in a boatyard, seen through an out-of-focus fence.

I wasn’t supposed to be the person who built this.

At least, not on paper if you know what I mean.

I don’t have a computer science degree. I didn’t study cybersecurity. I didn’t spend twenty years moving through increasingly senior security roles before deciding to start a security company. For a long time, that mattered to me more than I’d like to admit. But surprise, surprise….

Computers have never been new to me.

They were one of my first rabbit holes since the dawn of Computown.

As a teenager, I watched Hackers, that 1995 movie where everyone rollerblades, wears leather, hacks Gibson supercomputers, with The Prodigy playing in the background.

I loved it.

And like plenty of teenagers discovering their early internet, I wanted to know how much of that world was real. That question took me into places like TOTSE, into phreaking payphones, deliberately opening viruses, cookie hacking, password cracking, brute force, AOL punters, exploits, underground forums, tools passed around because somebody had figured out something they weren’t supposed to figure out.

Some of it was technical. Some of it was juvenile. Some of it was downright stupid.

Yet the thing that stayed with me has always been:

How does this system actually work?

Not how it’s supposed to work. How does it really work? What if you do this, what if you do that, what about this, and if this changes—how does it affect that? That long hyphen is not ChatGPT, it’s me, and I learned how to write long before AI trained on it (see ‘The Art of Styling Sentences’ on Amazon)

Back to the systems:

What assumptions did somebody make when they built it? What happens if you violate those assumptions? Where are the boundaries? What does the system trust? What happens when that trust is misplaced?

I didn’t have those words for it then. And I for sure wasn’t thinking about threat models, authorization boundaries, delegated authority, or security architecture.

I was a kid just poking at systems that would later make sense.

AOL was particularly fascinating because it felt like an entire little world inside the computer. And naturally, teenagers being teenagers, we discovered ways of making that world misbehave. Punters could knock people offline. Programs and scripts circulated. People learned tricks from other people, modified them, broke them, and passed them along again.

Then there was phreaking, which opened an even stranger door: the realization that the computer wasn’t necessarily the system. The system was everything connected to it. Networks. Phones. People. Procedures. Assumptions.

That idea stuck.

Eventually life went somewhere completely different: I didn’t become a hacker or security engineer.

I became a teacher.

And for more than thirteen years, my systems became human ones.

Communication. Intent. Interpretation. Feedback. Trust. Misunderstanding. The distance between what somebody thinks they said, what another person understood, and what happens next. I worked with people across countries, cultures, companies and careers. I helped people make themselves understood when getting it wrong actually mattered.

The teenager messing around with computers became something I used to be.

Or at least I thought he did.


Then AI and agents started doing things.

AI stopped being only something you asked a question.

Agents could call tools. Send emails. Change files. Execute code. Move money. Take actions in other systems. And something old switched back on in my head with some… Voodoo People playing in the background.

At first, I wasn’t thinking about what else we could make AI do. Everyone was already doing that. Everybody was excited building great and wonderful things. I was thinking deeper and beyond, what holds it all together? What needs to keep it together?

I kept going against the wind.

Yes, where does this break?

What is the system actually trusting? Who gave the agent permission in the first place, and what did they really give it permission to do?

What happens when the human meant one thing and the agent understood another? Or when the credentials say yes, even though the person behind them never would have? What if it’s something else? How do we even find out?

I kept coming back to that final moment, right before something actually happens. An email gets sent. Money moves. Code runs. A file changes.

I kept coming back to that final moment, right before something actually happens. An email gets sent. Money moves. Code runs. A file changes.

Where are the boundaries?

I couldn’t let that question go.

I kept looking for the thing I thought should exist. Something outside the agent that could check the authority, make the decision, enforce it, and leave evidence of what happened. Even then, how can you be sure?

Eventually, I realized I was spending more time wishing somebody would build it than asking the obvious question:

Why not me?

I didn’t know if I could build it. On paper, I probably wasn’t the person you would have picked to try.

But I wanted to find out.

So I started building.

That became Keel.


Cybersecurity, where it breaks

There’s something funny about ending up here.

I had spent years assuming that the lack of a traditional technical education put certain rooms behind glass. I could look inside. I could understand pieces of what was happening. But the people who built infrastructure, security systems, protocols, developer tools? Those were people who had followed a path I hadn’t.

Keel forced me to test that assumption.

It also forced me to learn very quickly that being interested in security and actually building security infrastructure are profoundly different things.

Every ‘kewl’ idea eventually meets an adversarial question.

What if this happens?

What if the agent lies?

What if the credential leaks?

What if approval arrives after the state changes?

What exactly does this evidence prove?

What doesn’t it prove?

Where can someone bypass you?

Sometimes the answer meant changing the architecture.

Sometimes it meant deleting something I’d built.

Sometimes it meant narrowing a claim I wanted to make because the evidence didn’t justify it.

Sometimes somebody produced a counterexample and I had to say: yep, that breaks my argument.

I’ve come to like that.

Because anyone can make something shiny.

I’m interested in what remains true when you try to break it. It’s like traveling too in a way, difficult situations and experiences can teach you a lot. More on that later.

So yes, what’s durable? What holds? Where does it fail?

And what can you put at that boundary to protect everything behind it?


Apparently I’ve always liked shields.

This connection is considerably less intellectual.

When I played World ofWarcraft, I loved being the tank.

Put me in front.

Give me armor. Give me a shield. Let something hit me instead of the people behind me.

There’s something deeply satisfying to me about protection as a role.

Not hiding from the dangerous thing.

Standing at the boundary between it and something worth protecting.

Apparently I never completely grew out of that.

Keel makes more sense to me through that lens.

So does AgentGate, a codename of another security product in the works.

Different systems. Different experiments. Same instinct.

Find the boundary. Understand how it breaks. Build the shield there.


I’m still learning.

I want this part in the story because otherwise everything above becomes too polished.

I’m not a lifelong security professional.

There are people in this field who have forgotten more about security than I currently know.

Keel has repeatedly taken me to the edge of my knowledge and then made me keep walking.

I’ve had to learn architecture, authorization, cryptography, standards, developer experience, policy, security claims, testing, sales, fundraising, and all the uncomfortable spaces between them.

I’ve been wrong.

I’ve rebuilt things.

I’ve watched assumptions fail.

And I’ve learned that saying “I don’t know yet” is considerably more useful in security than pretending you do.

But Keel has changed something else too.

For years there was a part of me that wished I’d had the education, tools, or permission to build systems like this.

Eventually I realized nobody was going to arrive and hand me permission.

So I started building.

Maybe Keel becomes a large company. Maybe it becomes something completely different. I genuinely don’t know yet.

But whatever happens to it, it already answered one question for me.

I can build the thing.


← Back to Writing