Security 6 min read

What the control plane can see — and what it never can

Every vendor in banking software eventually says some version of “we take your data seriously.” The sentence is free. What costs something is architecture — building the system so the vendor couldn’t see your data even if it wanted to, and being able to point at the code that makes it so.

Scout has a cloud component. It’s called HQ, and this article is about exactly what it holds, exactly what crosses the wire in each direction, and exactly what can never cross it — not as policy, but as plumbing. The short version fits on a card: no PII, catalog only. The long version is more interesting, because the long version is checkable.

Two computers in this story

When your institution runs Scout, there are two machines that matter.

The first is your workstation — the computer Scout is installed on. That’s where documents are ingested, where the text of scanned pages is recovered, where values are extracted, where reviews run, where every notebook file lives. As covered elsewhere in this series, a review in Scout is a single file on that machine, and the review happens where the file sits.

The second is HQ — VisionFI’s control plane. HQ is how your Scout installation knows what it’s allowed to do and how to do it: which review recipes your institution has enabled, what your document-type vocabulary looks like, what persona the assistant speaks with, what your institution’s written policies say.

The whole trust question comes down to one thing: what flows through the pipe between them, and in which direction?

The pipe runs one way

Here is the entire conversation Scout has with HQ. Not a summary — the entire thing. The workstation makes three kinds of requests, and every one of them is a read:

“What version is my config?” — a tiny manifest check, so Scout can skip the download entirely when nothing has changed.
“Send me my config.” — a package of catalog data, scoped to your institution (more on the scoping below).
“Send me my key.” — the credential Scout uses to talk to the AI provider, brokered by HQ so your institution never has to handle it.

That’s it. In the entire codebase, there is no request that sends anything to HQ. Not a form of upload, not a sync-back, not a telemetry beacon. The feedback design documents state the posture in one line: HQ “is read/outbound-only by design” and “stays out of the end-user data path entirely.” The code bears that out the simplest way possible — the write endpoints don’t exist.

This is worth pausing on, because it’s structurally different from a promise. A vendor that pledges “we won’t look at your data” is asking you to trust a decision. A vendor whose cloud has no door for your data to walk through is asking you to check a fact.

What actually comes down the pipe

So what’s in that config package? Opening it up, the contents sort into a handful of categories — and notice what kind of thing every one of them is:

Vocabulary. The shared list of document type names — “Consumer Loan Application,” “Truth-in-Lending Disclosure” — with their aliases, so the labels assigned at ingest and the labels recipes are written against can never drift apart.

Recipes. The sealed, fingerprinted review programs your institution has enabled — the checklists and rules described in the review article, carried whole so nothing has to be looked up at run time.

Personas and templates. The assistant’s directives — described in HQ’s own schema as “inert metadata only” — plus report templates and extraction checklists.

Your institution’s written knowledge. This is the closest HQ ever gets to something that sounds like data, so look at what it actually is. A real entry reads: “Verification of U.S. citizenship is satisfied by either a U.S. passport or a birth certificate.” That’s policy — the kind of sentence that lives in a procedures manual. Not a member, not an account, not a loan.

The architecture documentation calls the dividing line “the load-bearing invariant,” and states it in one breath: institutional knowledge is non-PII and syncs from HQ; customer data is PII and lives only on the desktop — “never syncs, never transits.” “Passport or birth certificate suffices here” is knowledge, so it syncs. A loan tape with Social Security numbers is data, so it never touches the wire.

And HQ is careful even about what it ships down. Before your config package leaves the server, HQ strips out every other institution’s rows, every access token, and the keys that unlock published feature notebooks — the code’s comment explains that shipping those “would hand every workstation the ability to decrypt the entire catalog.” Even the downstream direction is need-to-know.

What never goes up — an inventory

It’s worth being concrete, because “no PII” can sound like a slogan. Every item below lives on your workstation, in files your institution holds, and has no route to HQ:

The documents. Original PDFs, scans, spreadsheets — stored as bytes inside notebook files on the machine.
Everything derived from them. Recovered text, extracted values, findings, reports, conflict flags.
The notebooks themselves. Reviews and their complete audit trails, portable files under your retention policy.
Chat transcripts. Every conversation with Scout is itself a local notebook file — same anatomy, same residency.
Usage records. Scout keeps a call-by-call ledger of every AI request — model, token counts, timing — and writes it inside the notebook it describes. The design document is explicit about the consequence: delete the notebook and the rows go with it. Your usage history isn’t a dashboard on someone’s server; it’s part of the file you hold. And the ledger records only metadata — never the content of what was asked or answered.
Connected-account sign-ins. When Scout connects to a system your institution already uses — a mailbox, a CRM — the sign-in happens directly between your workstation and that system, and the resulting secrets are kept in the device’s keychain. HQ is not in that handshake.

And two things Scout simply doesn’t have: there is no analytics or telemetry SDK anywhere in the product — no third-party trackers phoning home — and HQ keeps no registry of installations, no device list, no heartbeat, no “last seen.” VisionFI’s cloud cannot tell you which machines ran Scout today, because nothing reports in.

What about the AI?

A fair reader has been waiting to object: documents obviously leave the machine when the AI reads them. True — and it’s a different pipe, worth distinguishing precisely.

When a review needs a model to read pages, the workstation sends those pages directly to the AI provider — Anthropic — under a zero-data-retention posture, with inference contracted to run in the United States. HQ is not a relay, not a proxy, not a middlebox; document content never routes through VisionFI’s cloud on its way to the model or back. The pages travel inline inside each request, are read in the moment, and are never stored on the other end — Scout deliberately refuses the industry-standard file-upload APIs, because a stored file is retained data. (The review article walks through the size gymnastics this forces; the constraint is the receipt.)

So the full data-custody picture has exactly one processor of document content — the model provider, transiently, under ZDR — and it isn’t HQ. HQ’s role is narrower and stranger than people expect from a “cloud”: it brokers the key, ships the catalog, and never meets a document.

The stolen-token test

A good way to pressure-test any architecture is to ask: what’s the blast radius if a credential leaks?

Every Scout installation authenticates to HQ with an institution token. Suppose one is stolen. What can the thief do with it? They can impersonate your workstation’s reads — pull down your institution’s config package: the recipes, the vocabulary, the policy prose. That’s a real loss — it’s VisionFI’s workflow IP and your procedures manual — and it’s also the entire loss. The provisioning documentation states it flatly: “There is no agent → VisionFI customer-data path across the boundary.”

The thief gets the recipe book. They cannot get a single document, a single extracted value, a single member’s name — because those things were never on HQ to steal. The worst day for the control plane is a bad day for intellectual property and a non-event for customer data. That asymmetry is the design working.

Why build it this way

The convenient architecture — the one nearly everyone ships — puts the processing in the cloud, because that’s where it’s easiest to operate, meter, and improve. The cost of that convenience is that the vendor’s cloud becomes the place your customers’ data lives, and every security review, every exam, every breach headline flows from that fact.

Scout pays the inconvenience instead. Processing happens on your machines. The cloud component is demoted to a catalog: it distributes knowledge downward and receives nothing upward. The invariant — knowledge syncs, data doesn’t — isn’t a paragraph in a privacy policy; it’s the shape of the pipe.

What can HQ see? Your institution’s name, its token, its configuration, and its written policies.

What can it never see? Everything you’d actually worry about.

Not because we promise. Because there’s no door.