PII stays in the field.

There’s a question every information-security officer asks in the first ten minutes of any vendor call, and it’s the right question: where does our data end up? Most modern software has an uncomfortable answer wrapped in a comfortable phrase — “in our secure cloud” — which translates to: your members’ Social Security numbers now live on infrastructure you’ve never seen, governed by controls you have to take on faith, in a pile alongside every other client’s.

Scout’s third principle is the opposite answer. Borrower data stays in the field — on the workstation where the review happens, inside notebook files on hardware your institution already owns, already patches, already encrypts, and already knows how to defend. VisionFI doesn’t operate a vault of your members’ data, because the architecture never accumulates one.

This isn’t one big feature. It’s a hundred small refusals, and this article walks through the ones that matter.

---

Where the data actually is

Ask “where is the borrower data?” of a Scout deployment and the answer is a folder you can open. Reviews live as .scoutnb notebook files — by default in a Scout Notebooks folder inside the workstation’s own Documents directory. Each file is the complete review: the original PDFs as bytes, the recovered text, every extracted value, every finding, the full audit trail. The notebook article covers the anatomy; what matters here is the residency. The file sits on your disk, under your operating system’s full-disk encryption, inside your endpoint controls, subject to your retention schedule.

And there is no shadow copy. Scout keeps a few shared local databases — configuration synced from HQ, sync state, an index of notebook names and paths — and none of them holds a member, an account, or a document. Even Scout’s usage accounting refuses to centralize: the call-by-call ledger of every AI request is written inside the notebook it describes, so when you delete the notebook, the usage history goes with it. Your activity isn’t a dashboard on someone’s server. It’s part of the file you hold.

Delete the file and the review is gone. That sentence sounds trivial. Ask your other vendors to say it about their cloud and count the qualifications.

The discipline of never picking things up

Keeping data in the field is less about walls and more about habits — a codebase-wide reflex of not collecting things in the first place. The examples are small and telling.

When your loan system signals that a loan is ready for review, the signal arrives as an email in a mailbox your institution controls. Scout reads it, parses out the loan reference, and records a work item — and the work item deliberately omits the borrower’s name, even though the email contains it. The code’s reasoning is worth quoting, because it’s the whole principle in one line:

A value that is never extracted cannot leak into a log, a UI row, or a support export.

The raw email is never copied into Scout’s records at all — it stays in the mailbox, under your retention rules, and Scout keeps only a pointer back to it. The same reflex shapes the logs: Scout’s operational events carry model names, token counts, timings, and error codes — never document content, which lives only in the notebook. And two whole categories of leak simply have no machinery to leak through: there is no analytics or telemetry SDK in the product, and no crash reporter shipping stack traces to anyone. Nothing phones home, because there’s nothing installed that could.

The keys stay in the field too

Data isn’t the only sensitive thing on a workstation — there are also the credentials that reach data. Scout’s custody policy sorts every credential by one question: does it grant standing access to a system of record full of member PII? The ones that do — your LOS login, your core’s API key — are, in the policy’s words, keys to the vault, and they never leave the field either. They’re stored in the workstation’s operating-system keychain, and when Scout uses one, the connection runs directly from your workstation to your vendor. VisionFI’s cloud is not in that handshake, doesn’t broker it, and couldn’t replay it.

That’s the quiet second half of the principle. A vendor breach at VisionFI can’t expose your members’ data or the keys to the systems that hold it — neither was ever there.

The two pipes out, named honestly

“Stays in the field” invites a fair audit: what leaves the workstation, ever? Two pipes, both covered in depth in the control-plane article, both summarized honestly here.

The HQ pipe carries no data at all. The workstation’s entire conversation with VisionFI’s control plane is three kinds of download — a version check, a configuration package, a brokered key. There is no upload endpoint on the other end to receive borrower data, which is a stronger statement than a promise not to use one.

The model pipe carries documents, transiently, to exactly one processor. When a review needs the AI to read pages, those pages travel directly from your workstation to the model provider, inline in the request, under a zero-data-retention arrangement — read in the moment, never stored, and processed in the United States under contract. Scout deliberately refuses the industry’s file-upload APIs because an uploaded file is retained data; every document travels inside the request that needs it and exists nowhere on the far side afterward. One processor, no storage, no middlebox — and never VisionFI’s cloud.

So the precise claim isn’t “nothing ever crosses the wire.” It’s this: borrower data rests in the field, and only in the field. The one system that ever processes it elsewhere does so in transit, statelessly, and keeps nothing.

Your perimeter, not a second one

There’s a subtle payoff to field residency that security teams appreciate more than anyone: Scout doesn’t ask you to trust a new perimeter. It inherits the one you already run.

The notebook is an ordinary file, so your full-disk encryption already covers it at rest, your endpoint monitoring already watches it, your data-loss-prevention rules already govern where it can be copied, and your backup and retention systems already know what to do with a Documents folder. When someone shares a notebook, it moves through your email or your Teams, so the same DLP applies in motion. Scout adds no parallel sharing service, no separate account system, no second set of access rules to audit.

Why “the field” is the right place

The convenient architecture centralizes: pull every client’s documents into one cloud, process them there, and let the vendor’s security team defend the pile. It’s easier to build, easier to operate — and it makes the vendor’s infrastructure the most interesting target in your supply chain, one breach away from every client’s members at once.

Scout distributes instead. Every institution’s data stays on that institution’s hardware, inside that institution’s perimeter, in files that institution can count, archive, and delete. There is no pile. A worst-case day at VisionFI — covered in the control-plane article’s stolen-token test — exposes configuration and recipes, not a single member’s name, because the names were never collected.

Bankers have run on this model for a long time: the branch holds its own records, the vault sits behind the institution’s own walls, and the vendor who built the vault door doesn’t keep a copy of what’s inside. Scout just declines to treat the cloud era as a reason to change that. The data was born in the field, it works in the field, and it stays there.