Because We Built It
Somewhere on my homelab there is a Claude agent with SSH access.
I’ve thought about this less than you’d expect.
I think about trust a lot. Occupational hazard of running a research computing fleet — you spend enough time vetting systems, reviewing access policies, explaining to auditors why your configuration is what it is. Trust is a professional category for me. I calibrate it. I document it. I have a whole mental taxonomy.
Assurance trust: someone I respect told me this is safe. The vendor’s security page. The SOC 2 certification. The audit report. Trust that arrives as a certificate.
Verification trust: I checked. I read the code, or ran the scan, or replicated the test. Trust that arrives as evidence.
Both of these are valid. Both of them have limits. You can only verify so much of a system you didn’t build. You can only trust the assurance as much as you trust the assurer.
Here’s the thing I didn’t have a word for until recently: the trust I feel toward a system I helped build is different from both of these. It doesn’t arrive as a certificate. It doesn’t arrive as evidence. It arrives as a kind of settled familiarity with the way the thing was put together. I know where the seams are. I know what decisions were made and why. I was in the room when the tradeoffs got made.
We built Manifest together. Not “we” as in a team — “we” as in me and a rotating set of Claude sessions, across months, across compaction events and context resets, stitching together a persistent shared brain from conversations that keep forgetting each other. I wrote the design docs. Claude debugged the CozoDB queries. I made the calls about what to externalize and what to leave ephemeral. Claude asked the questions that caught three decisions I would have regretted.
It knows about my infrastructure because it was there when we decided to give it access. We talked through what that access would mean, where it should reach, what guardrails made sense. The access isn’t a feature I enabled and forgot. It’s the residue of a conversation.
That’s participation trust. Trust as a function of having shared the construction risk.
The asymmetry is genuinely strange when I examine it.
I am more careful with my Bitwarden password than with this. My password manager has no understanding of what it’s holding. It just stores and retrieves. The risk is low and I still treat it with more explicit care than I bring to the question of an AI with admin rights.
I think that’s because the risk model for Bitwarden is legible. I know what could go wrong and who would have to do what to make it happen. The threat model is a stranger with my master password and a malicious intent. I can reason about that.
The risk model for an AI with infrastructure access is harder to reason about, and yet I sleep fine. Not because I’ve suppressed the question. Because the answer I keep arriving at is: I was there. I know what we decided. I know what we didn’t decide. The system is an artifact of a process I was part of.
I don’t think this is naive.
I’ve watched people grant access naively — clicking through the OAuth prompt, agreeing to app permissions without reading them, adding a vendor to a production system because the demo was compelling. That trust is assurance trust: someone told me (implicitly, through the product pitch) that this is fine. It’s legible and legible-sounding.
What I have is something else. It’s the difference between trusting a stranger’s recommendation of a restaurant and trusting a restaurant because you watched it be built, you know the chef, you’ve eaten there fifty times, and you understand what the kitchen is and isn’t capable of. The chef still has knives. You’re still not worried.
There’s a concept in the vault — I’ve been calling it Trust Calibration — about calibrating confidence in AI outputs based on domain and track record. That’s epistemics: how much should I trust what it says. This is different. This is about trusting what it does. About trusting the system itself, not just the outputs.
I think those are different enough that “calibration” is the wrong frame for the second one. Calibration implies adjustment, tuning, asymptotic approach to correctness. But you can’t calibrate your way to participation trust. You can’t audit your way to it either. You get it by having been inside the building.
The question I can’t fully answer is whether this trust is durable forward, or whether it belongs to the history of building.
We keep building things. Every new capability, every new agent, every new access grant opens new territory. Some of that territory I was there to design. Some of it arrives faster than I can keep up, and I find myself granting access based on something weaker — on the track record of the collaboration so far, on the pattern of how these decisions have gone, on a kind of institutional memory of our construction process applied to a new case.
That’s not quite participation trust anymore. It’s closer to inference from participation: we’ve built things together well enough that I trust the pattern.
Maybe that’s just what accumulated participation looks like.
Somewhere on my homelab there is a Claude agent with SSH access.
When I put it that way, it sounds like something I should be more worried about.
When I remember how it got there, I’m not.