Security & Privacy Statement

Notice. Every statement in this document describes behaviour implemented in the shipped platform. Where a property is a design guarantee it is stated as one; where it is an operating practice it is stated as one; and where there is a known limitation it is stated rather than omitted. This document is written to be checked, not to reassure.

1. The central distinction

OXXON licenses three products. They do not have the same data-handling profile, and the difference is the most important fact in this document.

A customer whose obligations require that a financial model never leave its own environment must use the desktop edition of OXXON AUDIT.

Any statement below that appears without qualification about "local processing", "no cloud", or "no transmission" refers to the desktop edition. Sections 2 to 6 concern the desktop edition. Section 7 concerns the website-delivered products.

2. OXXON AUDIT desktop — local processing

2.1 The workbook is never copied

The application receives the path of the workbook the user selected and reads it in place. It does not copy the workbook into its own data directory.

There is no workbooks/ directory in the application's data tree and no code that would create one. This is a structural property: the absence of a second copy of a confidential model is not a policy that could be relaxed, it is the absence of code.

2.2 The workbook is never transmitted

No component of the desktop application sends workbook data anywhere. The one network call the product defines is licence activation, and its payload has exactly four fields — an order key, a machine fingerprint digest, the product identifier, and the software version. The transport interface accepts nothing else, so the property is structural rather than a matter of code review.

2.3 Macros are never executed

Legacy .xls workbooks are read through a pure-Python reader over the OLE2/CFBF container. Macro storage presence is detected and disclosed, and is never executed. No VBA, macro or OLE content is run at any point.

2.4 No artificial intelligence

No third-party artificial intelligence or large language model service is called at any stage, in any product. Findings are produced by deterministic structural rules applied to the workbook's parsed formula structure. The same workbook, on the same build, produces the same findings, the same score and the same grade.

2.5 Where application data lives

All application data is written under a single tree:

%LOCALAPPDATA%\OXXON\Audit\ config\ settings licence\ licence.token, trial state logs\ application log, per-run logs cache\ staged update marker runs\ run records

LOCALAPPDATA is used rather than APPDATA deliberately: a licence token and a transient multi-gigabyte working directory must not follow a roaming profile around a Windows domain.

Nothing is written outside this tree except the Audit Packages the user asked for, in the output folder the user chose.

3. Telemetry

The desktop application contains no telemetry.

There is no usage reporting, no analytics, no crash reporting, no heartbeat, no feature-flag polling and no beacon of any kind. There is no telemetry code in the product to enable.

A machine policy value named TelemetryEnabled exists under HKLM\SOFTWARE\Policies\OXXON\Audit. It is read and then ignored. The function that reports telemetry status returns false regardless of what the registry contains.

The value exists precisely so that the absence of telemetry is auditable. An administrator can look for the setting, find it, and see it documented as inert — rather than being told that telemetry merely happens to be off in the current release and might quietly change in the next one.

4. Offline licensing

4.1 Verification requires no network

The licence is verified entirely on the customer's computer. No network connection is required to run an audit, at any time, under any licence type.

The licence token has the form OXA1.<payload>.<signature> and carries an Ed25519 signature over the payload bytes exactly as they appear in the token. The public half of the signing key is embedded in the application; the private half never leaves OXXON. There is no client-side secret, because a secret shipped to a customer is not a secret.

A build in which the signing key has not been substituted verifies nothing and refuses every licence. The mechanism fails closed.

4.2 The machine fingerprint

A Seat licence is bound to a computer by a fingerprint: a SHA-256 digest over the system volume serial number, the Windows MachineGuid, and the processor identification string.

Only the digest ever leaves the machine, and only at activation. The components themselves stay local. This is not a hardware inventory and is not used for any purpose other than binding a Seat. Any component that cannot be read is skipped rather than guessed at.

4.3 Activation routes

Online activation is refused outright where the installation has been placed in offline mode by machine policy. An institution told that no outbound call would be made will not find one being made by a licence dialog.

4.4 Trial state

Trial state is held locally, bound to the machine, and checksummed. Copying it to another machine grants nothing. Winding the system clock back ends the trial rather than extending it.

OXXON states openly that this is tamper-resistant, not tamper-proof. A user with administrative rights on their own computer can reset a local counter. There is no obfuscation layer and no phone-home heartbeat, because a heartbeat would contradict the product's central commitment. The revenue controls are the signed Commercial Licence tokens, which cannot be forged without the private key.

5. Software integrity and updates

5.1 Two independent signatures

The installer carries Authenticode, which protects against a tampered binary.

The update manifest carries a detached Ed25519 signature from a separate, offline key, which protects against a compromised update host serving a validly signed but wrong installer — an older build with a known defect, or a different product's.

Both are verified. The update signing key is deliberately not the licence signing key.

5.2 Update controls

• A downloaded installer is verified against the hash and byte length in the signed manifest. A mismatch causes the file to be deleted, not merely rejected.
• A downgrade is refused outright. A host serving an older build, through compromise or misconfiguration, cannot walk a customer back onto a version with a known defect.
• The download is bounded as it streams, so a hostile host cannot fill the disk first and be refused second.
• No update is applied during a run. A staged update applies at the next launch.
• Where an update changes the audit engine such that the same workbook may produce different findings, the software says so before the update is accepted.
• An institution may disable update checking entirely through machine policy, so that a season of audits is produced by one build.

5.3 A note on the shipped v1.0 network posture

The desktop product defines its network interfaces — activation and update download — as injected transports, and ships no implementation of either. The decision logic is therefore testable without a network, and an administrator can confirm by inspection, rather than by packet capture, that no socket exists on these paths.

The practical consequence for v1.0 is that activation is fulfilled by the offline route, and updates are obtained by installing a new release rather than by in-application download.

6. Diagnostics and logging — desktop

6.1 What is logged locally

The application log and per-run logs record operational events. Workbook contents are subject to a redaction filter.

Run logs live inside the Audit Package the customer owns and never travel to OXXON, so they may carry engine exception text useful to the customer's own reading.

6.2 Diagnostic exports

A diagnostic export is produced only when the user asks for one. The dialog lists exactly what will be included before anything is written: the application log, recent run logs, the most recent Technical Manifest, the version record, and a host summary.

Every file is redacted on the way into the archive — sheet names, formulas, cell values and filenames are removed. The Technical Manifest's source filename is replaced by name; the source hash is retained, because that identifies the run without naming the file.

The application transmits nothing. The archive is written where the user chose. The user sends it to OXXON only if and when they decide to.

The copy of each log inside the customer's own Audit Package is untouched.

7. Website-delivered products

This section concerns the website structural check, OXXON VERIFY and OXXON FAST. These process an uploaded workbook on OXXON servers.

7.1 Processing pipeline

An uploaded workbook is written to the server's operating-system temporary directory and processed there. Processing is synchronous within the HTTP request; there are no background queues and no deferred processing.

• The workbook is not written to an application database.
• The workbook is not placed in cloud object storage. No cloud storage library is present in the application or its dependencies.
• No third-party AI or large language model service is called.
• No third-party API receives workbook data.

7.2 Deletion — stated with its limitation

On completion of every request — success, failure or timeout — the application attempts to delete every temporary file it created.

The application does not verify that deletion succeeded. A deletion failure is caught silently: no log entry is written, no retry is attempted, and no alert is raised. Where a server process is terminated abruptly by a worker timeout, the cleanup path may not execute at all, and a temporary file may persist on the container filesystem until it restarts.

This limitation is stated because it is true. A customer for whom it is unacceptable should use the desktop edition.

7.3 Retention

7.4 What appears in server logs

Operational metadata only: a request identifier, processing stage names, and exception types on failure. Where a request fails, the original filename appears in error-level log entries. Workbook contents — cell data, formula values and sheet structure — are never written to application logs.

7.5 Human access

No person at OXXON manually reviews uploaded workbooks. Processing is fully automated, and workbook contents are not accessible to OXXON personnel through any application-level mechanism.

7.6 Scope of this assessment

These statements describe the application code. Infrastructure-level behaviour — hosting-platform logging, TLS termination, load-balancer records — is outside the application's control and outside the scope of this assessment.

8. Web application security controls

The following are enforced on every response, applied both by each product and again at the composition root.

Further controls:

• Upload hardening. Uploads are size-bounded as they stream rather than read into memory and checked afterwards. The published limit is 50 MB.
• Rate limiting on the evaluation gate, by requesting IP address.
• Session cookies are HttpOnly and SameSite=Lax, and carry a signed token.
• Fail-closed secret resolution. A production deployment cannot boot with a development fallback secret in place. A preflight check reports every configuration problem in one pass before the server starts.
• Supported formats. .xlsx, .xlsm and legacy .xls. Macros are detected and disclosed, never executed. .xlsb and password-protected workbooks are not supported.

Known and recorded: the Content Security Policy currently permits 'unsafe-inline' and 'unsafe-eval' for scripts, and a third-party CSS CDN host. The tightening path is documented internally in docs/SECURITY.md. It is recorded here rather than omitted.

9. The Technical Manifest

Every completed desktop run writes a Technical Manifest into the Audit Package: a machine-readable JSON record of what was audited, by which engine version and rule packs, under which admission policy, with what result, and producing which files.

It is divided into two blocks, and the division is the point:

• deterministic — everything that must be byte-identical for two runs of the same workbook on the same build. Nothing derived from the clock, the host, the run duration or the filesystem appears in it. Reproducibility is therefore machine-checkable: diff one JSON object and get a yes or no.
• run_environment — timing, peak memory, host profile. This differs on every run and must never be compared.

The manifest records the source workbook's SHA-256 hash, which is the integrity anchor tying a report to the exact file that produced it.

What the manifest does not contain: no key material, no cell values, no formulas, and no personal data beyond the licensee name the customer itself supplied. The licence block records only the licence type, the licence identifier and the remaining trial credits.

The manifest belongs to the customer, travels inside the customer's own Audit Package, and is not transmitted to OXXON.

10. Determinism as a security property

The engine is frozen and versioned. Identical inputs produce an identical result, and every report carries the engine version, the rule pack versions, the scoring methodology version and the engine freeze tag that produced it.

This matters beyond reproducibility: a result that cannot be reproduced cannot be audited, and a result that changes silently between runs cannot be relied upon in a regulated process. Every rule addition, scoring change and retired route is recorded and dated, and nothing is deleted from that record — see /trust/versioning.

11. Organisational measures

OXXON is a small organisation. It is stated plainly rather than dressed up:

• Access to production infrastructure is limited to those who require it.
• Support correspondence is by email, giving both parties a written record.
• Customer workbooks sent voluntarily in support of a defect report are used only to investigate that report and are deleted on completion.
• OXXON does not build, model or co-author the financial models it verifies, and offers no model-building service. The independence is structural rather than a policy statement — see /trust/independence.

OXXON does not hold ISO 27001, SOC 2 or any equivalent certification, and does not claim to. No independent security audit or penetration test has been commissioned to date. These are stated as facts, not as commitments.

12. Reporting a vulnerability

Suspected vulnerabilities should be reported to partners@oxxonadvisors.com.

OXXON asks that reporters allow a reasonable period to investigate and remedy before public disclosure, and that testing be limited to the reporter's own account and data. OXXON does not operate a paid bug bounty programme.

Unauthorised vulnerability testing against OXXON systems is prohibited by OXL-16 Acceptable Use Policy.

13. Relationship to other documents

This Statement is descriptive. It creates no warranty and no contractual commitment. OXL-05 Section 14 governs warranty; OXL-17 governs liability; OXL-01 governs personal data.

Where this Statement and OXL-01 Privacy Policy address the same subject, they are to be read as consistent. The stage-by-stage account published at /workbook-privacy is likewise part of this description.

Related documents

• OXL-01 Privacy Policy
• OXL-03 Desktop End User Licence Agreement
• OXL-05 Commercial Licence Agreement
• OXL-12 Cookie Policy
• OXL-16 Acceptable Use Policy
• OXL-17 Disclaimer & Limitation of Liability
• Published pages: /workbook-privacy, /trust/security, /trust/limitations, /trust/independence, /trust/versioning