What happens to your code when a tool reads it

Connecting your repositories to an outside tool is a real decision, and the honest first reaction is a pause. You are about to hand over the thing your company is mostly made of. "Trust us" is not an answer to that pause, because trust is not a mechanism — it is what you are left with when there is no mechanism to point at.

So the useful questions are not about intentions. They are structural: what actually gets stored, what is allowed to leave the process, and what keeps one customer's code from ever reaching another. Those have answers you can check, and they are the answers worth asking any tool for — this one included.

Reading is not the same as keeping

The first question is what persists after the tool is done. WeaveSpec clones a repository the cheap way — a shallow, single-branch, blobless clone onto ephemeral disk — analyses it, and deletes the clone when the job ends. The source code itself is not kept. What persists is derived: text chunks and their embeddings, a summary, the relationships between services. The working copy of your code exists for the length of one analysis and then it is gone.

The second question is what the tool is even permitted to do while it is in there. WeaveSpec connects through a GitHub App that requests read access and nothing else — repository metadata and contents, read-only. It does not ask for write access, it cannot open a pull request, it cannot touch your Actions workflows, and it never requests your secrets. The permissions it deliberately does not hold are as much a part of the design as the ones it does. Access is scoped to the repositories you select, not your whole organisation, and disconnecting the App stops all further access immediately.

That distinction — reading is not writing — is not a footnote. A tool that only ever reads has a much smaller blast radius than one that can change your code, and the boundary is enforced by what GitHub will let the App do at all, not by a promise about how it behaves.

The things that must never leave

Repositories contain material that should never be sent anywhere: a private key, a database URL, a committed .env. The design assumption is that this material will appear, and the job is to catch it before anything crosses the process boundary.

WeaveSpec scans for it with a local rule engine that never calls a model — because asking a model to classify a secret would mean transmitting the secret to do it. The scan runs in the worker, on the ephemeral clone, before any content is embedded, shown, logged, or sent to a provider. And it fails closed: if a detector errors or cannot run, the file is excluded rather than waved through. When it flags something, the report carries a count, a path, and the name of the rule that fired — never the value, the line, or the matched text. A flagged file owns no searchable chunks at all, and that exclusion is checked by the database test suite, not just intended.

Tenants that cannot see each other

The last question is the one multi-tenant products most often get wrong: what stops one customer's data from surfacing in another's results. WeaveSpec draws that boundary at the project, and enforces it in the database rather than in application code. Every table has row-level security on; a read only succeeds if you are a member of the project the row belongs to.

The reason this is worth stating is that it is tested adversarially. The database test suite puts a user who belongs to one project up against another project's rows — naming the other project's id directly, the way a bypass attempt would — and confirms they see zero repositories, zero integrations, zero jobs, zero audit entries, and that a cross-tenant write changes nothing. The credentials your integrations use are locked down harder still: the columns that hold them carry no read grant to ordinary users at all, so no policy has to defend them — the database simply will not return them. A deleted project is deleted, not merely hidden; a search from another project returns nothing of it, in one transaction.

What to actually ask any tool

• What persists after analysis? "The working copy is ephemeral; only derived artifacts are stored" is a very different answer from silence. Ask for the specific one.
• What can it do besides read? Read-only, least-privilege access with the write permissions explicitly declined — and scoped to the repositories you choose — is the shape to look for.
• Where is isolation enforced? In the database, provable by tests, beats "in the application" every time, because application code is where isolation bugs live.
• What is claimed vs. verified? Prefer a guarantee someone can point a test at over a reassurance someone is asking you to take on faith. On what leaves for a model provider, read the provider terms the claim rests on rather than the adjective in the headline.

None of this asks you to trust a stranger with your code. It asks you to check the mechanism — and a tool worth connecting is one that has published the mechanism to check. That is the bar WeaveSpec is built to clear, and the bar you should hold every tool in this position to.