Trust, access, and disclosure. One document.

Whichever model applies, the scope is the same: indexing covers the repository and its history, and, only with your approval, read access to the systems where intent lives, typically the issue tracker and the support queue. The audit reads; it does not write.

Access is minimal by construction: source code is all the audit needs. We do not ask for secrets, credentials, or production access; the rare exception is whatever the component itself requires to run, a license key for a build, named at scoping. Engagement data is encrypted in transit and at rest, and access to it is limited to the people named on the engagement.

The engagement itself runs on our systems; what we hand back, the evidence corpus (requirements, findings, and tests, in plain YAML and code) and the audit gate that re-runs them, runs in your CI without us.

The portal is optional. Hosted, it runs on our infrastructure; a self-hosted installation runs entirely on yours, with no analytics of ours in it; and engagements that skip it get the same views as generated static reports. Nothing in the engagement is gated on it. A full on-premise deployment is available, and the question it turns on is which model provider you point it at — that is your choice to make, and we scope it with you.

Three subprocessors handle engagement code and model work: Anthropic, OpenAI, and xAI. Client code reaches them only through their commercial APIs, under terms that exclude training on customer data, and each maintains a SOC 2 program with attestations available through its trust portal — the three names above link to those portals. If your policy excludes a given provider, say so at scoping: the engagement runs only on the providers you allow. And we will walk your AppSec team through each provider’s current retention posture at scoping, in writing. There are no other subprocessors in engagement work on your code: no offshore review, no data brokers.

Separately, on analytics: this public website runs PostHog (EU cloud) and Google Analytics (measurement ID G-ELLL5G7YW0) for page use. The hosted cloud portal runs PostHog. For you as a visitor that means we can see which pages get opened, and nothing about your code. In the portal, client data is redacted from what it collects. If this list ever changes, this page changes first, and standing clients hear it from us before they read it here.

Two kinds of machine involvement: deterministic checks, which pass or fail; and AI drafting assistance, whose output must survive those checks. Machines check everything, every time; a person validates every finding before it reaches you. Which systems see your code is governed by the access model in section 02 and the subprocessor list above. The fuller disclosure lives on the methodology page.

Proof does not publish private customer corpora, even for marketing, because the requirement graph can describe the product almost as completely as the source itself. We hold our own corpus to the same rule — the engine’s full requirements tree describes the engine, so it stays private too.

Yours is fine. We countersign your NDA, same day, and read no private code before it is in force. A signed data-processing agreement is available at scoping.

Proof is operated by Replay Technologies LTD, registered in Armenia at 36 Manushyan, Yerevan 0012. Engagement contracts name this entity. And your paper is fine here too: we typically contract on your template, under your governing law, so your counsel reviews terms they already know.

Your repository’s graph is reached with a personal access token. The token is displayed once and stored only as a hash, you give it an expiry when you create it, and you revoke it yourself. It acts as the person who created it and resolves to exactly the projects that person can already open: one tenant, nothing wider. A project you may not see and a project that does not exist return the same answer, so the endpoint cannot be used to find out what exists.

There is one anonymous door, and it opens on our public jsonparser demo project: a seeded open-source showcase, published so a team can point an agent at a real graph before anything is installed. It reads a public open-source project, and it is not a route into customer work. The anonymous door opens only for projects marked public, private ones still demand a token, and every request to it is rate-limited by source address.

Over the endpoint the tools are read tools: requirements and their obligations, findings and known issues, the graph around a node, blast radius, tests, reproducers, change records, and the audited source those reference. File reads and code search are confined to the files the audit already references, and the absolute paths of our own checkout are stripped from every answer before it leaves the tenant boundary.

One write exists, and it is narrow: an agent can post a comment or open a discussion on a finding. It stays off unless you mint a token that carries the write scope explicitly, it posts as the account that owns the token, and it cannot change a finding’s state. The anonymous door does not carry it at all.

Proposing a requirement, attaching evidence, and approving all happen in your repository, through your own workflow and your own permissions. MCP gives the agent the model. The agent acts through your repository, CI, and permissions.

Every requirement carries an assurance level, and you set it per component and per requirement. Proof ships open: out of the box an agent may approve at any level, and the record names the agent and the level it ran under. The human line is opt-out, and it is one key in your proof.yaml, under project.approval: agent_autonomous_for. Set all: false and list only the levels you delegate under assurance_levels; an empty list reserves every level for a named person. At a level you have reserved, proof approve refuses the write outright and names the setting that refused it. The full policy is on the methodology page.

Approved intent is not quietly rewritable. Every lifecycle change is written to the requirement’s own change history with the actor that made it, a person or an agent, in the YAML you keep; review entries record the same way. An agent’s edit reads as an agent’s edit, in your repository, without us.

The endpoint cannot start a verification run. It answers from the stored audit and your git objects, and it runs neither the audit nor the gate. Verification runs where the gate runs: your CI, or a person on the engagement. An agent working inside your repository can rerun the obligations a change put in doubt, because that runs on your side of the boundary and under your permissions.

Each call is recorded as a usage event: which tool ran, on which project, whether it succeeded, how long it took, and which token and account made it. No part of the answer is recorded, and no argument beyond the project name. Those events go to the same analytics named in section 04.

The endpoint returns context to whichever client you point at it, and it calls no model of its own. If your agent is Claude Code, the retrieved context reaches Anthropic under your own agreement with Anthropic; the same holds for any other client and provider. The subprocessor list in section 04 covers our engagement work, and it does not cover your agent’s traffic.

Findings derive their authority from runnable reproducers. A named principal can only stand behind so much work, so the assurance practice takes a limited number of engagements each quarter. Proof is young; the deliverable is designed so that limited concurrent capacity does not put what you rely on at risk.

The entire corpus lives in your repo as plain YAML and executable tests. The audit gate runs without us, in your CI, on every release. Nothing you depend on day to day is hosted by us or gated on our availability. The gate runs offline if your environment demands it: release artifacts are checksummed and can be mirrored into internal distribution, and tagged releases are immutable.

And if you stop: you keep everything that runs. The gate keeps checking yesterday’s promises; nobody keeps writing tomorrow’s.

Security-relevant findings follow coordinated disclosure, case by case, worked out with the affected maintainers or vendor.

The public register shows the policy in practice: where we have not asked for approval, entries appear anonymized, and say so on their face — one live entry reads that the client is not named because we had not asked permission when it shipped, and that it will be updated if permission is granted.

We do not currently hold a SOC 2 report, and we do not present ourselves as a SOC 2–certified vendor.

For private engagements, your code is handled under NDA as described in sections 02 and 04 (access models and providers). The evidence corpus and audit gate we deliver live in your repository and run in your CI; the hosted portal is optional and not required for the engagement to work.

We complete security questionnaires as part of scoping. If your procurement process requires a current SOC 2 report before work can start, we will tell you plainly on the first call that we cannot clear that bar yet, rather than stretch what we have.

When you need a certified penetration test, for SOC 2, PCI, or a customer security review, engage an accredited security firm; our audit does not substitute for that report, and we say so at scoping. The same holds for black-box red-teaming, infrastructure testing, and social engineering. Security promises inside the audited component’s scope are ours to prove; those artifacts are theirs.

The six clauses we hold the work to are published, and nobody accredits them. They are a bar we set and can be held to, and they are not a certification scheme. The methodology page states each clause with the machine check that fails when it is broken.

Work email, required: so we can reply. Anything we should know is optional and on the first screen. Everything else on the demo form is optional and only shapes the first reply — your name, your company, the component you would start with, the timing, and whether your code is public or private. You can leave all of it blank.

Every request gets a reply. Scoping is confidential, and private early access is deliberately small: we take on a limited number of engagements at a time.