What Can Your AI Vendor Actually See?

If you lead a team, or you've ever sat through a security review, this is the essay you've been waiting for through the last three. All that talk about memory and rules and gates raises one question that has to be answered before any of it can touch real code: who can see what?

I'm going to answer it completely. Not with reassurance, with a map. Because "trust us, it's secure" is exactly the phrase that should make you close the tab, and I'd rather earn it than ask for it.

Let me set up the actual question first, because it's more specific than "is it safe."

The one honest constraint

Here's a fact that no product can engineer around, so any product that pretends otherwise is lying to you. For an AI to use your project's context, that context has to be assembled into a request in plaintext. And whatever assembles that plaintext can, in principle, see it. That's not a weakness in a particular tool. It's the nature of sending text to a model.

So the real question is never "can the plaintext be made to never exist." It has to exist, for a moment, somewhere. The real question is: who is the "somewhere," and did using this tool add a new one?

Your code already goes to your AI vendor. You already decided to trust them when you started using their model. Your memory, and often your code too, if they live in a git repo, already live on a git host you already chose. Those parties are already in your circle of trust. The question that actually matters for a new tool is whether it drags in a new party who now also gets a copy. That's the lens. Now here are the options, from most convenient to most locked-down, and exactly what each one exposes.

Option one: the proxy

The most convenient setup routes your AI requests through a proxy that injects your memory on the way to the model. Everything works with every tool, nothing to configure per-tool, memory arrives guaranteed.

What the proxy sees: everything, in the moment. The request passes through it in plaintext, memory and code alike. It doesn't have to store any of it, and a well-built one doesn't. But it passes through. So this option asks you to trust the proxy operator the same way you already trust your AI vendor. For a solo developer on a personal project, that's usually a fine trade for the convenience. For a regulated enterprise, it's often a dealbreaker, and it should be, because you've added a party. This is the most capable option and the one that asks the most trust. Both of those are true at once, and I'd rather say so than bury it.

Option two: hooks, memory hosted

Move up a rung. Use hooks instead of a proxy, so your AI tool assembles the request locally on your own machine, and pull your memory from a hosted service. Now the request is assembled on your hardware. The memory service hands over your briefing and rules, but it never sees the request going to the model, and the model traffic never passes through it.

What's exposed here is narrower: a memory service that holds your project's briefing and rules, but not your live coding sessions and not your full codebase. Smaller surface, but the memory itself still sits on someone else's server. Which leads directly to the next rung, because you can close that gap too.

Option three: hooks, memory in your own repo

Now the memory lives in your own git repository, and the hook pulls from it using your own credentials. The tool provider is out of the storage picture entirely. Your memory sits where your code's history already sits, on the git host you already trust, under your own access controls. Nothing about your memory touches the tool vendor's servers, because the vendor isn't holding your memory, you are.

At this point the only parties who see anything are ones you already chose: your AI vendor, who was always going to see the request, and your git host, who was always holding your repositories. No new stranger. That's the sentence a security reviewer is actually listening for.

Option four: self-hosted, nothing leaves

And the last rung, for the people who need it: run all of it on infrastructure you control. Your memory on a git server in your own building. The delivery and adherence engine, hooks and gates and the ledger, running on your own machines. Automatic memory maintenance, deciding what's worth keeping, still runs in the hosted engine today. Your own model keys, or even your own self-hosted models if you've gone that far.

In this configuration, the tool provider, me, my company, sees nothing. Not your memory, not your requests, not your metadata. There's nothing to send a subpoena for, because there's nothing on our side. The method runs entirely inside your walls.

This is the option a cloud-only competitor structurally cannot offer you, no matter how good their privacy policy is, because their whole architecture assumes the data comes to them. Ours assumes it might never leave you. That difference isn't a feature we added. It's a decision about who the software is built to serve.

The dial, not the switch

Notice that these aren't four different products. They're four settings on one dial, over the same memory, the same rules, the same method. You can start on the convenient end while you're kicking the tires and slide toward the locked-down end as the stakes rise, without relearning anything or migrating your data. A solo dev hacking on a side project and a bank with a compliance department can use the same tool and simply choose different points on the dial.

I built it this way on purpose, and the purpose is a little bit of a confession. I don't want you to have to trust me. Trust is a thing you extend and later regret. I'd rather hand you an architecture where, past a certain point on the dial, trusting me becomes unnecessary, because I couldn't see your data even if I wanted to. The strongest thing I can say about my own product isn't "we'll protect your memory." It's "turn the dial up and we can't reach it." A promise you can verify beats a promise you have to believe, every time.

Why this is the whole game now

Here's why I spent an entire essay on this instead of on features. The AI tools themselves are becoming interchangeable. The models are converging. Everybody can inject context, and soon everybody will. When the capabilities flatten out, the thing left to compete on is trust, and trust is architectural, not promotional. It's not who has the nicest privacy page. It's whose design makes the privacy page unnecessary.

A team choosing an AI infrastructure tool in a year isn't going to ask "which one is smartest." They'll all be smart. They're going to ask "which one can I actually let near our codebase," and the honest answer will be the one whose architecture lets them turn the dial to a place where the vendor can't see in.

That's the bet I'm making. Not that I can build the cleverest memory. That I can build the one you don't have to trust.

Last essay in this series is the strange one, and my favorite. I'm going to show you that I didn't just design this method, I built the whole product using it. A planner and an executor and a verification loop, checking each other's work, catching each other's mistakes, including a few of mine. The method built the thing that teaches the method. Receipts included.

I'm Kevin Rodenhofer, building AI infrastructure under my company OuterData Corporation. If "which one can we actually let near our code" is a question you have to answer, get in touch and I'll show you the whole map.