Security 10 min read
Scout is software you install — and why that changes the security conversation
Most AI products are places you go. You open a browser tab, sign in, and your work happens on the vendor’s computers, under the vendor’s controls, changing whenever the vendor deploys. The security conversation that follows is the one every bank knows by heart: where is the data, who administers the servers, what did the vendor change last night without telling anyone?
Scout starts from the opposite premise. It’s software you install — a signed application on a workstation, or on a machine your institution operates — and that one decision quietly answers a whole category of questions before they’re asked. This article is about what actually gets installed, where it’s allowed to run, and the part that deserves the most scrutiny: what an AI application does to the machine it runs on, and how the harness keeps it a well-behaved guest.
What actually gets installed
Scout ships the way desktop software has shipped for decades: as a fixed, signed artifact your IT department can examine before a single user runs it.
On Windows, the installer is signed under VisionFI’s publisher certificate with a trusted timestamping authority, so the signature outlives the certificate. On macOS, the application is signed with Apple’s hardened runtime and notarized — submitted to Apple, scanned, and stapled with a ticket before distribution. Linux gets a self-contained AppImage. In every case the thing that arrives is a specific set of bytes with a verifiable origin: your endpoint tooling can hash it, allowlist it, and vet it the way it vets everything else on the estate.
The macOS build makes the posture unusually easy to audit, because Apple requires an application to declare its entitlements — the OS capabilities it’s permitted to use — and Scout’s declaration is five lines. Two of them are the JIT permissions every Electron application needs to exist. The other three: network access (“for Scout HQ sync and API calls,” says the build file’s own comment), the ability to load its compiled core, and read/write access to files the user explicitly selects — “for opening loan document packages.” That’s the whole list. No camera, no microphone, no location, no blanket filesystem grant. The application asks the operating system for exactly what a document reviewer needs, and the operating system holds it to that.
Updates follow the same philosophy. Scout checks for new versions but never downloads one on its own — the setting in the code is explicit — and installation happens when the user chooses. On Windows, the updater verifies that a downloaded update carries the same publisher signature as the application it’s replacing; an update that fails that check is refused with a plain message: it could not be verified. A hosted product becomes a different program every time the vendor deploys, silently, for everyone at once. Installed software changes when you install the change — and when it does change, the configuration it runs is versioned and fingerprinted, so you can say exactly which version produced which finding.
Where it runs is your call
The default deployment is the one this site describes everywhere: Scout on a reviewer’s workstation, notebooks in their documents, everything about a review living in one file on that machine.
But “your computer” was never meant to mean “one laptop.” The same Rust engine that powers the desktop app also ships as a headless command-line tool — no window, no interface, same catalog, same data directory, same notebooks — built for batch processing on a machine that nobody sits at. And VisionFI publishes runbooks and scripts for running Scout on a virtual machine inside your institution’s own cloud tenant, written for your administrator, not ours. The companion-deployment guide opens by drawing the line in the first paragraph: the Scout application “never authenticates to Azure and never creates cloud resources,” and everything in the guide “runs under your own change control.”
The posture of that reference deployment is worth listing, because each line is the answer to a security-review question: no public IP address. No inbound firewall rules. No listening network sockets on the operating system. Access only over your private overlay network, gated by an allowlist — and until a key is added to that allowlist, the guide notes, the machine “serves nobody”; an empty list “never means open.” The notebooks it produces — the files that contain member PII — sit on a disk in your subscription, under your retention policy, your monitoring, your change control.
One boundary is stated just as plainly. An unattended Scout machine prepares work; it does not finish it. In the deployment guide’s words, it “pulls documents, ingests them and runs a review, then parks a notebook for a person to look at. It commits nothing back to any system of record while nobody is watching.” Automation moves the waiting; a person still decides.
Whichever shape you choose — laptop, headless server, VM in your own tenant — the constant is who owns the hardware and who governs it. There is no deployment mode where the answer is “VisionFI.”
The AI is a guest. The harness is the house rules.
Here’s the question a CISO should ask about any AI application, and rarely gets to: never mind the data for a moment — what does this thing do to the machine it runs on? An application that talks to a frontier model, renders model-generated content, and holds integration credentials is itself attack surface. The harness exists to test the model’s answers; the same harness is also what confines the application on the host.
Start with what isn’t there. Scout’s internal services run inside the application process — the code that wires them up notes there is no TCP listener at all. Nothing on the machine is listening for a connection; there is no port for a scanner to find, on a workstation or on the VM. And there is no analytics or telemetry SDK shipped in the product — no crash reporter, no usage beacon, no third-party tracker. As shipped, nothing on the machine reports to anyone.
Then, what the model’s output is allowed to do. When Scout renders a model-generated report or document, it renders inside a sealed surface whose content-security policy permits no network connections of any kind. The comment above that policy states the intent exactly:
A rendered document physically cannot phone home — so a missed external reference fails as a blocked request in QA rather than leaking on a locked-down workstation.
Even a link inside a sealed render doesn’t navigate anywhere; clicking one copies the address to the clipboard, because “no egress, no navigating away” is, in the code’s words, the safe default for a sealed render. And when Scout does embed a real browser view — for looking at an external site — the application forcibly re-applies the isolation settings on every embedded view, whatever the page asked for, and quarantines it in its own session partition, separate from any notebook.
The same fencing applies to the automation. A recipe runs in a sandbox whose only door to the network is a single function the host controls; the comment on it says the quiet part — egress policy lives in the host, “NOT here, so a recipe cannot choose to bypass it.” Operations that would write to one of your systems of record are disabled by default, per system, behind an explicit opt-in, “so they can’t ship or fire by accident.”
And the credentials. When Scout connects to a system your institution already uses, the secret goes into the operating system’s own keychain — macOS Keychain, Windows Credential Manager, Linux Secret Service — and the code that stores it states the rule in one sentence: “the value never leaves the device.” If no OS keychain is available, Scout does not quietly fall back to a config file; it refuses, loudly. Failing is safer than degrading.
Compiled, and signed end to end
Underneath the interface, Scout’s engine — document ingestion, extraction, recipe execution, verification, the notebook format itself — is compiled Rust, spread across more than two dozen purpose-built modules. The interface layer’s job, as an internal migration document puts it, is to be “a thin pipe.” Why does the language matter to a bank? Two properties, both checkable.
The first is memory safety, enforced rather than intended. Rust’s escape hatch from its safety guarantees is a keyword, and Scout’s build configuration forbids that keyword across every VisionFI-authored module — the compiler rejects the build if anyone reaches for it. The class of vulnerability behind a large share of the industry’s memory-corruption CVEs is excluded as a matter of build policy, not code review.
The second is determinism — the same conviction that runs through the whole product, pushed down into the artifacts. A finished report renders through a pure-Rust pipeline with its fonts embedded, works offline, and deliberately embeds no timestamp, so that — in the code’s words — the byte output is “a reproducible frozen record.” Re-render the same review and you get the same bytes.
Trust in what arrives is anchored the same way. Every recipe travels as a sealed bundle whose cryptographic hash the engine re-verifies on load; one shared routine computes the seal at publish and at load “so routing and hashing can never drift.” Published feature notebooks go further: each is encrypted and signed, and the application verifies the signature against a public key baked into its own binary — because, as the verification code explains, “transport is untrusted by design, so this key — not the connection — is what makes a downloaded assistant’s persona trustworthy.” The order of operations is stated as load-bearing in the same file: verify the signature first, decrypt only after — the application “never processes attacker-supplied plaintext.” Even the VM setup script refuses to install a binary whose digest doesn’t match the published value.
A signed installer, hash-sealed configuration, signature-verified content, digest-pinned deployment. At no point in the chain does trust rest on the network the bytes crossed.
What this buys you in the exam
Pull the threads together and the deployment story compresses into answers an examiner recognizes:
Where does processing happen? On hardware your institution owns and controls — a workstation, a server, or a VM in your own cloud tenant. Never on VisionFI’s.
What did the vendor install? A signed, notarized, fixed artifact your IT vetted, with an entitlement list short enough to read aloud. It changes when you install the change.
What can it do to the machine? Nothing is listening, nothing reports out, rendered AI content cannot make a network connection, credentials live in the OS keychain, and write-access to your systems is off until you turn it on.
What does VisionFI’s cloud know about your machines? It ships configuration down and takes nothing back — and it has no registry of installations at all. Scout presents an institution token, not a machine identity; as VisionFI’s own design notes concede, two laptops at one bank are indistinguishable to HQ. Your vendor cannot tell you which of your machines ran Scout today, because nothing tells it.
The industry default is software that lives on the vendor’s computers and asks for your trust. This is the older arrangement, rebuilt for AI: software that lives on yours, and brings its own fences.