Written for the reviewer who assumes the box is a risk.
A local appliance should be judged as risk until proven otherwise. This page is the deployment boundary, the threat model, and the controls — the answers a security review needs before sign-off.
What is processed locally, and what is not.
Processed locally
Matter content is processed locally on firm-controlled infrastructure. The analysis runs on the appliance, on hardware your firm controls.
No routine outbound path
In air-gapped configurations there is no routine outbound network path for matter content. The data path for the matter stays inside your boundary.
Controlled, signed updates
Updates arrive through a controlled, signed path — delivered and applied deliberately, not pulled silently from the internet during processing.
The risks a reviewer will raise — addressed directly.
Parser attack surface
Malicious files in ESI are a real risk. Parsing runs sandboxed, with no network access and least privilege, so a malformed file cannot reach beyond the parser.
Prompt injection in evidence
Evidence text is treated as data, not instruction. Strict separation means no tool execution or action is taken from the content of a document.
Update integrity
Updates are signed and applied through an offline workflow. No silent callbacks and no automatic remote fetches during matter processing.
Access
Role-based access control governs who can do what, with append-only audit logs recording it.
Data at rest
Full-disk and matter-level encryption protect data at rest, with keys held under firm control.
Recovery
Backup and restore procedures and secure deletion close the data lifecycle, end to end.
Be precise about outbound paths.
Be precise about what leaves the box. Matter content is not sent out for processing — it is processed locally on firm-controlled infrastructure, and in air-gapped configurations there is no routine outbound network path for matter content. That is a statement about the matter data path, not a claim that the appliance is hermetically sealed.
Operational paths exist, and they are described honestly. Any diagnostic bundle or support export is explicit, reviewable, and initiated under firm control — never an automatic background upload. A reviewer should be able to enumerate every outbound path and confirm that none of them moves matter content without a person deciding to.
What we provide for technical sign-off.
Deployment diagram
How the appliance sits in your network, what it touches, and what it does not.
Threat model document
The risks we designed against and the control for each, in writing.
Update / patch model
How updates are signed, delivered, and applied through an offline workflow.
Support-access policy
When we can access the appliance, how, and under whose authorization.
Logging & encryption model
What is logged, how logs are protected, and how data is encrypted at rest.
Dependency / SBOM disclosure
A software bill of materials where feasible, so dependencies are reviewable.
Incident-response process
What happens, and who is notified, if something goes wrong.
Bring your security review. We will answer it.
Send the questionnaire your firm uses. We will map our controls to it, line by line.
Or reach the team directly: contact@closevector.ai