Handling your data
Security posture
How client data is handled on an engagement: what is asked for, what is refused, where the work runs, how secrets are handled, and how long anything is kept.
What is asked for
- Configuration export
- Serving configuration, model and routing settings, cache settings, retry and timeout policy. Text, redacted of secrets before it is sent.
- Billing summary
- Provider usage and cost breakdown at whatever granularity the provider exposes — typically per model, per day, with token counts.
- Redacted request samples
- A sample of request and response metadata: token counts, timestamps, model, latency, cache read and write fields, error codes. Prompt and response CONTENT is not required for most findings and is not requested by default. Where a finding genuinely needs content — 16 of the library's 56 findings do — the sample is scoped to that route and agreed in writing first.
Contact form submissions are delivered through a third-party form provider named in this site's content security policy, and nothing sent through that form is engagement data.
What is never asked for, and will be declined if offered
- Credentials of any kind: API keys, tokens, passwords, certificates, SSH keys.
- Production access. No console login, no cluster access, no database connection.
- Write access of any kind, to anything. The work is measurement; it changes nothing.
- Customer personal data, and any data subject to a regime this engagement has not been scoped for.
If any of these arrives anyway — pasted into a message, embedded in a config export — it is treated as an incident and handled as described under secrets below, not quietly ignored.
Where the work runs
Wherever the workload allows it, the measurement runs inside the client environment and only the measurements come back: counts, distributions, and the derived figures. The request data does not leave. Where that is not possible — no suitable compute, or a provider whose usage records are only reachable from outside — the scoped export is transferred and processed as described below, and the difference is stated in the engagement letter rather than assumed.
Secrets handling
Everything received is scanned on arrival, before it is read or processed, for credential patterns and high-entropy strings. Anything containing a credential is quarantined, and the client is told which file and which line. The expectation is that the client rotates it. Nothing is quietly deleted and the notification is not deferred to a report.
How long anything is kept
Client data is deleted within thirty days of delivery, unless you ask us in writing to hold it longer. The deletion will be logged and confirmed in writing, naming what was held and what was removed. The window exists so that questions about the findings can be answered against the data they came from; there is no archive and no "anonymised" copy retained.
What is not done with client data
- It is not used to train anything, ours or anyone else's.
- It is not sent unredacted to any third-party API, including model providers.
- It is not used to build a benchmark, a dataset, or a comparison against another client.
- No client is named to another client, or publicly, without written permission.
Where it sits while we work
An encrypted volume is created for the engagement before any client file is accepted, on the workstation that does the work. One folder per engagement, kept apart from every other engagement. It is never committed to source control — our own tree-integrity check excludes engagement files by name, every time it runs. The file is read by tooling running on that workstation. We use AI assistants to build and review that tooling; they are not given your file. The analysis is performed by one named person, named to you before work starts.