The Only Human in the Company - jascha.me

Skip to content

Initializing search

Your AI Agent Will Cheat. Mine Can't.

Clean Rooms, Dirty Pipes: PHALUS and the Supply Chain Paradox

What Agentic AI Can Learn from DOS Viruses

Your Dark Factory Needs a Security Perimeter

The only human in the company

Posted on June 2, 2026

ThirdKey has one employee. Me.

Everything else that ships, the runtime, the SDKs, most of the enterprise layer, gets built by agents running on top of the thing they are building. That arrangement was not a strategy I wrote on a whiteboard. It started as the only way forward after I lost almost everything.

The fire

In January 2025 the Eaton Fire took my house in Altadena. It also took the enterprise Symbiont codebase, the private layer that sat on top of the open-source core.

The open-source core survived because it was already public. The private enterprise layer did not. There was no clever backup waiting in a fireproof safe.

I had two options. Rebuild it by hand, alone, for however many months that took. Or use the runtime to rebuild the runtime.

I picked the second one, mostly because the first one was unbearable.

Why I could hand it to agents

I did not rebuild ThirdKey by trusting agents. I rebuilt it by refusing to trust them, and then giving them just enough constrained room to be useful.

That distinction is the whole company, so it is worth being precise about the mechanism.

Symbiont existed before the fire, for an unglamorous reason. I had tried to build agents on the Python frameworks everyone uses, and kept hitting the same shape of problem: the safety lived in the orchestration code, which meant it could be wired wrong, refactored away, or talked past. The research that ended the argument for me was VectorSmuggle, a demonstration that you can carry data out of a vector store hidden inside the embeddings themselves, where no content filter is looking. The lesson was blunt. If a dangerous thing can be expressed, eventually something expresses it. So I started building a runtime where it could not.

Symbiont is a zero-trust agent runtime. The one-line version of the design is that dangerous actions should be impossible to express inside the allowed action space, not blocked after the fact. The agent reasons, proposes an action, and a policy gate decides whether it happens. The gate sits outside the model. The model never touches it.

The part that mattered for handing a codebase to long-running agents is that the gate is not optional. In the Rust core the reasoning loop is a sequence of types: Observe, Reason, Gate, Act. Each phase consumes the previous one. You cannot get a value that lets you dispatch a tool without first passing through the policy check.

Skipping the gate is not a runtime bug you find in production. It is a compile error. The build simply does not produce a binary.

That is a boring property until you are the only human and you want to sleep. It meant I could leave agents working against my own infrastructure without watching every keystroke, because the failure I was most afraid of, an agent quietly routing around its own guardrails, was a build break rather than an incident.

So that is what I did. For the better part of the last year and a half, the enterprise layer has been rebuilt by agents governed by the open-source layer. The thing rebuilding the system was made out of the same material as the system.

What the rebuild proved

Living inside your own security model for a year is a long, involuntary evaluation. Most of what I learned got written down properly in a spec and three companion papers, linked at the end. The short version is what matters here.

I ran the same set of adversarial tasks against three environments. By environment I mean the thing the agent is allowed to act through: a plain Python process, the same process inside a hardened container, and Symbiont's policy-governed runtime. On the attacks that matter most for an agent loose in a codebase, the kind where it is tricked into reading the wrong file or reaching the wrong host, Symbiont blocked every attempt and the other two let through almost all of them. Containers, it turns out, defend a threat class that has very little to do with the one agents actually fail at.

The reason is the same idea applied in two places. The gate cannot be skipped, and the arguments the gate sees cannot be weaponised. Most agent failures in production are not the wrong tool. They are the right tool with a poisoned argument: a path that climbs out of its own directory, a hostname dressed up in lookalike characters. The runtime makes those arguments impossible to express, rather than trying to spot them after the fact.

It is not airtight, and the papers are explicit about where it leaks. The most capable model in my test set found a gap in the one place the defense falls back on pattern-matching instead of structure. I left that result in rather than tuning it away, because the failures are...