Security and data handling
The questions a technical buyer asks before any of this is allowed near real documents, answered before you have to ask them.
How we work
- Your data is not training anybody's model
- Enterprise API tiers from the major providers exclude submitted data from training by default, and configuring that is part of the build rather than an option you have to ask for. Where a provider cannot make that commitment for the tier a project is on, we will say so before the project starts, not in a footnote afterwards.
- An agent's reach is written down before it is granted
- Every tool an agent can call is enumerated, with what it can read, what it can change, and what it cannot touch. Anything with a consequence outside the system stops for a person. The useful question is not what an agent can do, but what it can do wrongly at three in the morning with nobody watching.
- Least privilege, including for us
- We ask for the narrowest access that lets the work happen, on named accounts, never a shared login, and we expect it to be revoked when the engagement ends. If you are handing a supplier a permanent administrator credential, that is worth pushing back on, including when the supplier is us.
- Self-hosting when the material cannot leave
- For documents sensitive enough that the problem is the data leaving your infrastructure at all, we scope a self-hosted option: open-weight models served on hardware you control, with the retrieval layer alongside it. We will also be straight about the cost, because it is usually higher and the quality ceiling is usually lower.
- Secrets stay out of the repository
- Credentials live in a secrets manager and reach the runtime as environment variables, never in code, prompts or evaluation fixtures. Prompts get committed and shared far more casually than code does, which is exactly why a key pasted into one is a problem that outlives the project.
- A record of what ran
- Agent runs are traced: which tools were called, what came back, where a run stopped. When something goes wrong the question is always what actually happened, and reconstructing that from application logs the next morning is not an answer.
What we do not claim
LynchPine holds no security certification. We are not ISO 27001 certified, we have not completed a SOC 2 audit, and we have no penetration test report to hand you. If your procurement process requires any of those from a supplier, we will not clear it, and it is better for both of us to know that in the first conversation than in week three.
What is above is how we actually work, and every line of it is something you can hold us to during an engagement and check afterwards. We would rather publish that than a page of badges that describes a different company.
Send us the questionnaire
If your team has a security review to run, send it early. We answer it straight, including the rows where the answer is no.
Start a project