Governance for a team of one

Governance is one of the four positions I keep coming back to. I've written about it enough times that the position is on record. The catch I haven't written about yet is that everything I've said on the topic has been calibrated against organizations, engineering teams, small shops, the SOC 2 conversation, the MSA exposure, the auditor in the room. The frameworks I've been recommending don't scale down to one person.

That gap matters because a lot of the work I see in 2026 is increasingly solo. A team-of-one consultancy. A side project that uses three frontier APIs and five MCP servers. A founder running a small product with two contractors. The enterprise governance literature has nothing to say to these people that isn't either over-engineered or condescending, and the absence creates a real failure mode: solo operators conclude governance is a big-company problem and skip it entirely.

It isn't a big-company problem. It's a function of leverage. A solo operator with five agents and a frontier API key has more concentrated capability than a 2018 mid-sized engineering team. The blast radius is the same. The accountability surface is just smaller and quieter, which makes it easier to ignore until something goes wrong.

This piece is the lightweight-but-real version of governance, the version I run on my own stack and the version that maps to what one person can realistically maintain. Five things, none of them heavy, all of them earning their keep.

The framing, what governance is for when nobody's watching

Enterprise governance exists for two audiences: the people inside the company who need to coordinate, and the external parties who need to verify. SOC 2 is for the auditor. The internal review board is for the team that's about to build something that touches customer data. The retention policy is for the legal team that has to respond to discovery.

A solo operator has neither audience. The temptation is to conclude that governance, therefore, has no purpose. The conclusion is wrong. The audiences are still there; they're just future-you, and they're a different version of present-you that you haven't met yet.

Future-you is the one who has to figure out what an agent did three weeks ago when somebody (a collaborator, a curious reader, you yourself) asks. Future-you is the one in a hypothetical where a piece of work needs a data-handling attestation and now has to back-fill the evidence. Future-you is the one whose API key got committed to a public repo and now has to know exactly what was sent through it before it was rotated.

The whole frame for solo governance is: build the artifacts that future-you will need, build them at the cheapest possible point, and don't build anything else. Five practices clear that bar.

1. Log every tool call, the cheapest insurance you'll ever buy

I've written this one up at length, so the short version: every tool call my agents make gets logged with timestamp, tool name, arguments, response (truncated past a threshold), and the conversation ID it belongs to. Local SQLite, append-only, rotated weekly into compressed archives.

The cost is fifty lines of wrapper code and a few megabytes of disk per week. The payoff is that I can answer "what did the agent do" for any conversation in the last two years in under a minute. That single capability has saved me from three different "wait, did it actually do what I asked?" moments, including one where it had done exactly what I asked and I was the one misremembering.

For a solo operator this is the load-bearing piece. Skip everything else if you have to; do this one.

2. Redaction patterns at the boundary, not after the fact

The PII conversation I had in November ends in the same place for a solo operator that it does for a small team: the redaction has to happen at the boundary between your data and the model, and it has to be a pattern, not a ritual.

The pattern I run: a small redaction layer in front of every outbound call to a hosted model. It catches API keys, email addresses, phone numbers, anything that matches a few known internal-identifier formats, and substitutes them with stable placeholders that the response layer can re-hydrate if needed. It's regex-and-a-lookup-table; it's not perfect; it catches 95% of the accidents and that's enough.

The thing that makes it real rather than theatre: the redaction layer logs every substitution. So when I want to know what sensitive data has touched a hosted model (across my own work, my homelab pipelines, anything I'm doing on the side) I have a query I can run rather than a guess I have to make.

3. Prompt versioning, git for your system prompts

The reason this matters for solo operators specifically: the prompts ARE the system. There is no codebase that holds the logic; the logic is in the prompts and the tool definitions. If you're not versioning them you're running production without source control.

The setup is boring. A prompts/ directory in every project, one markdown file per prompt, all of it in git. Every prompt change is a commit. Every prompt change has a reason in the commit message. When something starts behaving differently, git log prompts/ is the first place I look.

The real value isn't the version history. The real value is that you stop being precious about iterating on prompts. If the change is in git you can revert it. If you can revert it you'll try things you wouldn't try otherwise. The governance benefit and the velocity benefit are the same benefit.

4. Access boundaries, what each agent can actually reach

This is where solo operators get into trouble most easily, because the tendency is to give every agent every tool. It's faster to set up. It also means a hallucinated tool call from an editor agent can rm-rf production.

The pattern I wrote about for the assistant-without-secrets work generalizes: every agent gets the smallest tool set that lets it do its job, and write-capable tools live behind a confirmation boundary that the agent cannot bypass. A research agent gets read-only filesystem and HTTP. A coding agent gets the repo and npm test but not npm publish. A deploy agent exists for deploys and nothing else.

The principle is: the access boundary is where governance lives, not the prompt. Telling an agent "be careful" is not a control. Not giving the agent the dangerous capability is.

For a solo operator this is mostly about resisting the convenience pull toward one-agent-with-everything. The convenience is real. So is the blast radius.

5. A weekly fifteen-minute audit, the practice that ties it together

Once a week, fifteen minutes. I look at the tool-call log for anything that surprised me. I look at the redaction log for any new categories of data that leaked through. I look at the git log for prompts I changed without thinking about why. I look at the access boundaries for anything I loosened "just for this one thing" and never tightened back.

This is the practice that makes the other four into governance instead of plumbing. The artifacts only matter if somebody looks at them. For a solo operator the only somebody is you, and you have to schedule it or it doesn't happen.

Fifteen minutes a week. About the cost of one cup of coffee. The thing that catches the slow drift before it becomes the incident.

What this isn't

This isn't a substitute for the on-prem conversation, or the SOC 2 conversation, or the framework conversation. Those are organizational things and they remain organizational things. A solo operator who eventually needs SOC 2 will still need SOC 2; what they'll have, if they've been doing the five things above, is most of the evidence trail already in place. That's not nothing.

It's also not a posture. The mistake I want to head off is the solo operator who reads enterprise governance literature, decides governance is impossible at their scale, and ends up with a posture of "I'm too small for that" rather than a practice of "here's the proportional version." The proportional version is what's described above. It's small enough to actually do and real enough to count.

The honest summary

Governance for a team of one isn't the enterprise version with the serial numbers filed off. It's a different shape of practice, sized to the leverage and the audience that solo work actually has. Five things: log every tool call, redact at the boundary, version your prompts, scope your agents' access, audit weekly for fifteen minutes.

None of them are heavy. All of them are real. Together they're the difference between a solo practice that can answer questions about itself and one that can't. That difference compounds, and the cost of building it later is much higher than the cost of building it now.

The principled-user population I keep writing to is the audience for this. The foundation is here, the tooling is here, the leverage is here. The governance has to be here too, proportional, lightweight, but real. Five things. Worth doing. Worth doing now.