Trust, access, and disclosure. One document.

The scope is the same in both models. Indexing covers the repository and its history. With your approval, we may also read where intent lives, usually the issue tracker and the support queue. The audit reads. It does not write.

Source code is all the audit needs. We do not ask for secrets, credentials, or production access. If the component needs something to run, such as a license key for a build, we name it at scoping.

Engagement data is encrypted in transit and at rest. Only the people named on the engagement can open it.

We hand back an evidence corpus and an audit gate. The corpus is requirements, findings, and tests, in plain YAML and code. The gate re-runs them in your CI, without us.

The portal is optional. The hosted portal runs on our infrastructure. Record any customer-hosted environment and its telemetry policy in the engagement scope.

Skip the portal and you still get the same views as static reports. Nothing in the engagement depends on it.

Agree hosting, model providers and network access before granting repository access. Customer-controlled deployment is part of Proof’s direction; the engagement must specify the actual environment and responsibility for operating it.

Three subprocessors handle engagement code and model work: Anthropic, OpenAI, and xAI. Client code reaches them only through their commercial APIs. Those terms exclude training on customer data.

Each maintains a SOC 2 program. Attestations are on the trust portals those names link to. If your policy excludes a provider, say so at scoping. The engagement runs only on the providers you allow.

We 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.

This public site runs PostHog (EU cloud) and Google Analytics (measurement ID G-ELLL5G7YW0) for page use. The hosted portal runs PostHog. We can see which pages get opened. We see nothing about your code. In the portal, client data is redacted from what it collects.

If this list changes, this page changes first. Standing clients hear it from us before they read it here.

Two kinds of machine work. Deterministic checks pass or fail. AI may draft, and that draft has to survive the checks. Machines check everything, every time. A person validates every finding before it reaches you.

Which systems see your code follows the access model in section 02 and the provider list above. The fuller disclosure is on the methodology page.

We do not publish private customer corpora, even for marketing. The requirement graph can describe the product almost as completely as the source. The planned open harness and the proprietary factory have separate boundaries. Publishing the harness does not publish customer data. Read the harness and factory direction.

Your NDA is fine. We countersign it the same day. We 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. We typically contract on your template, under your governing law. Your counsel reviews terms they already know.

Your graph is reached with a personal access token. We show it once and store only a hash. You set the expiry. You revoke it.

The token acts as the person who created it. It opens only the projects that person can already open. One tenant. Nothing wider. A project you cannot see and a project that does not exist return the same answer. The endpoint cannot be used to learn what exists.

One anonymous door opens on our public jsonparser demo. It is a seeded open-source showcase, so a team can point an agent at a real graph before anything is installed. It reads a public project. It is not a route into customer work.

The door opens only for projects marked public. Private projects still require a token. Every request is rate-limited by source address.

The tools on the endpoint are read tools. An agent can read requirements and their obligations, findings and known issues, the graph around a node, blast radius, tests, reproducers, change records, and the audited source those records point at.

File reads and code search stay inside the files the audit already references. We strip the absolute paths of our checkout before an answer leaves the tenant.

One write exists, and it is narrow. An agent can post a comment or open a discussion on a finding. That write stays off unless the token carries the write scope. It posts as the account that owns the token. It cannot change a finding's state.

The anonymous door cannot write.

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

Agree approval authority before work starts. Delegate lower-assurance work to agents within a defined scope; reserve higher-assurance intent and consequential exceptions for a person. Changes to these boundaries follow the previously approved policy. A passing check supplies evidence. It does not grant permission to merge or deploy.

The audit starts with scoped read access. Factory work additionally needs explicit permission to create branches, propose patches and run checks. Merge and deployment permissions are separate. Set repository, execution and spending limits before agents begin work.

Record the actor, approved policy, requirement revision and evidence behind each acceptance decision. A changed basis requires renewed evaluation. Read the authority model.

Approved intent is not quietly rewritten. Every lifecycle change is written to that requirement's own history, with the actor, 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. It does not run the audit or the gate. Verification runs where the gate runs, in your CI or with a person on the engagement.

An agent inside your repository can rerun the obligations a change put in doubt. That run stays on your side, under your permissions.

Each call is a usage event. We record which tool ran, which project, whether it succeeded, how long it took, and which token and account made it. We do not record the answer. We do not record any argument beyond the project name. Those events go to the analytics named in section 04.

The endpoint returns context to the client you point at it. It calls no model of its own. If your agent is Claude Code, that context reaches Anthropic under your agreement with Anthropic. The same holds for any other client and provider.

Section 04 covers our engagement work. It does not cover your agent's traffic.

Machines check everything, every time. One person validates each finding before it reaches you. People sign the bar and the promises that need a person's judgment. They decide which misses from public work get published.

The published postmortem carries no personal signature. We say so where we publish it.

Findings get their authority from runnable reproducers. A named principal can stand behind only so much work. The practice takes a limited number of engagements each quarter. Proof is young. The deliverable is built so that limit does not put what you rely on at risk.

The corpus lives in your repository as plain YAML and executable tests. The audit gate runs without us, in your CI, on every release. Nothing you use day to day is hosted by us, or gated on our availability.

The gate can run offline. Release artifacts are checksummed and can be mirrored into internal distribution. Tagged releases are immutable.

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. We work each case with the affected maintainers or vendor.

The public register shows the policy. Where we have not asked for approval, entries are anonymized, and they say so. One live entry says the client is not named because we had not asked permission when it shipped. It will be updated if permission is granted.

We do not hold a SOC 2 report. We do not present Proof as a SOC 2 vendor.

For private work, your code is handled under NDA, as sections 02 and 04 describe. The evidence corpus and the audit gate live in your repository and run in your CI. The hosted portal is optional. The engagement does not need it.

We complete security questionnaires during scoping. If procurement requires a current SOC 2 report before work can start, we say so on the first call. We cannot clear that bar yet. We will not stretch what we have.

When you need a certified penetration test, for SOC 2, PCI, or a customer security review, hire an accredited security firm. Our audit does not replace that report. We say so at scoping.

The same is true for black-box red-teaming, infrastructure testing, and social engineering. Security promises inside the audited component are ours to prove. Those other artifacts are theirs.

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

Work email is required, so we can reply. Anything we should know is optional, and it is on the first screen.

Everything else on the demo form is optional. It 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. We scope a first use of Proof in your existing repo and agent workflow. Scoping is confidential.