A page you can hand to whoever vets your vendors. Straight answers to what a careful buyer, their security team, or their AI advisor asks before giving a small, independent verifier access to source code. Including the questions where the honest answer is "not yet," and one option where the answer is "your code never leaves your perimeter at all." If a verifier won't answer these plainly, that is itself the answer.
I'm a small, new, independent practice. I do not hold SOC 2 or ISO 27001, and I won't pretend otherwise. Claiming a certification I don't have would fail my own audit. So engagements are built so you don't have to extend that level of trust: run it in your environment (above), or grant the least access that lets the work happen, with every commitment on this page written into the contract. The method needs no write access, no production systems, and no secrets. The right amount of trust to give a new verifier is "enough to read a sandboxed copy," or none at all, if you run it on your own machine.
A named individual, not a faceless brand. SK, with full legal name and contracting entity provided at NDA stage, before you share anything; real identity, public work history you can read commit by commit. Engagements are contracted in writing under the law of a Canadian province. I know an NDA signed by a pseudonym is worth little to your counsel. That is exactly why the in-environment option above exists: it lets you proceed on the strength of a machine you control, not on how much you trust a name.
Not yet on private code. I'm new, and I won't invent references. What I can show instead is public, verifiable proof-of-work: independent verification engagements on real open-source systems, disclosed responsibly, at least one reproduced and confirmed by the project's own maintainers. Plus my own live trading systems, run under the same verification I sell, in public, mistakes included. You can check every claim yourself rather than take a reference's word, which is more than a testimonial gives you.
Transfer is your choice: a read-only repository collaborator scoped to one repo, a read-only deploy key, or an encrypted archive you send, whichever your team prefers, over a channel you pick. "Deleted" means a secure wipe of the working copy and any local backups within 30 days of the retest, confirmed with a signed deletion certificate on request. The one thing that survives is the verification receipt, a timestamped hash of the attack plan and results. The receipt's hash persists; your code's content does not. There is no cloud repository, shared drive, or backup service holding a copy to outlive the window.
Two parties, named: me, and Anthropic (the Claude commercial API the method uses to analyze code). That's it: no other model provider, no offshore team, no third-party contractors, no undisclosed subprocessors. Anthropic's Commercial Terms and Privacy Policy state that API inputs and outputs are not used to train models; read them yourself rather than take my summary. That's the point of naming the subprocessor precisely. If any LLM processing is unacceptable, a no-LLM engagement removes Anthropic entirely, at a different scope and price.
In the default (send-a-copy) mode: on one dedicated, full-disk-encrypted machine under my sole control, located in Canada. Not shared, not a family computer, no one else with an account or physical access. Processed only through the Anthropic commercial API. No cloud repository of your code, no shared drives. In the in-environment mode, your code is stored and processed on your hardware and never touches mine. Data residency: if your code carries EU or other regulated personal data, tell me at scoping; the in-environment mode keeps residency entirely under your control.
Read-only access to the directories in scope and nothing else; a sanitized, scoped copy or private fork rather than your primary repository (you create the fork, so you control what's in it; I never verify your sanitization for you); ephemeral local clones removed on completion; no write access, no CI, no production, no admin. The work reads and reasons about code and runs tests in a sandbox; it never needs to change your systems.
No; see "the one thing to know up front." I'm too small and too new for those to be honest claims yet. Rather than a certificate, you get a structurally minimal-trust engagement (in your environment, or read-only / sanitized / no-credentials / ephemeral / securely deleted) and every commitment here written into the contract. When the practice is large enough for a real assessment to mean something, it'll have one. Today it doesn't, and I'd rather you know that than be told a comfortable half-truth.
Yes to both. I'll sign your NDA before you describe anything specific, and a data-processing addendum where your code carries personal data. If you'd rather start from a template, I have a mutual NDA and an engagement agreement ready to send; yours governs if you prefer it.
Yes, unambiguously. Your code, your strategies, and everything produced in the engagement (findings, tests, reports, reproductions) is your property. I retain no license to your material and claim no ownership of anything the work generates about it. This is stated plainly in the engagement agreement.
If I become aware of any unauthorized access to or loss of your material, I notify you without undue delay and within 72 hours, tell you what is known, and cooperate on remediation. This is a written clause in the engagement, not a good intention. (In the in-environment mode the surface barely exists: the code was never on my machine to begin with.)
Not yet, and I'd rather say so than imply a policy I don't hold. For a practice this new, the honest answer is that the engagement is built to shrink the loss a policy would need to cover: read-only or in-environment access, no write path to your systems, no production credentials, a scoped copy you control, and a secure-deletion window. So the realistic worst case is a confidentiality lapse, met by the NDA, the signed deletion certificate, and the 72-hour breach clause above, not by a claims process. Structural limits are a weaker instrument than a policy for some risks and a stronger one for others; I'd rather you weigh the real trade than see a checkbox ticked. As the practice grows into work where a policy is the right instrument, I'll carry the appropriate cover and say so here, dated, like everything else.
No. I won't run concurrent engagements for direct competitors. If a second party in your space approaches while yours is live, I decline or wait until yours has closed, and I'll tell you plainly if a conflict exists rather than quietly juggle both. "Never traded on, never referenced" applies to your material; "never played against you" applies to your engagement.
Yes. That's the preferred setup, and its strongest form is the in-environment mode at the top of this page. Short of that, give me a sanitized fork or isolated copy with secrets, credentials, production configs, and customer data stripped, containing only the subsystem in scope. The method works fully on that; it never needs your primary repository or your live environment.
The minimum: read-only access to the specific repository or directories in scope. No write, no admin, no organization-wide access, no access to other repositories, no CI or deployment permissions, no production tokens. A read-only collaborator scoped to one repo, a read-only deploy key, or a zipped sanitized copy: any of those is all I need. In the in-environment mode, even that grant is to your VM, not to me.