The system of record for software change controls
Every code and process change, sealed as audit evidence.
Toevan checks the code in every pull request, records how each change was reviewed, approved and merged, and catches every change to the rules around it. Each fact is signed and chained as evidence your auditor verifies offline with standard openssl, without Toevan software or an account.
- Data processed in the EU
- DPA available
- Verifiable with Sigstore, in-toto and cosign
Works with
- GitHub
- Kosli
- Sigstore
- Slack
- Jira
- Linear
Maps to
- SOC 2
- ISO/IEC 27001
- PCI DSS v4.0
- NIST 800-53 Moderate
- HIPAA
- GDPR
- DORA
- Checks every changeBlocks the merge on a broken rule, with the file and line.
- Records how it got inEvery review, approval and merge, as it happens on GitHub.
- Catches control changesRules switched off, admin bypasses and direct pushes.
- Seals it as evidenceSigned and chained, so your auditor verifies it offline.
Why now
Rules files ask the model to behave. Toevan verifies it did.
AI assistants now write a large share of the code regulated teams merge, faster than any review process was designed for. A CLAUDE.md or .cursorrules file is a request. A merge gate is a control, and the record it writes is the evidence.
How it works
One gate, one record. Every view an audit needs.
Toevan runs on every pull request, on main after each merge, and on every change to your review rules. What it decides, it records, and what it records, your team and your auditors can see.
§1
Gate
Blocks the change and says exactly why.
Every pull request is checked as a GitHub check against the blueprints you adopt. Same change, same rule, same result. No model decides a verdict.
- 28 deterministic constraint types across compliance, security and architecture
- Comments on the line, and posts its verdict as a review
- Exceptions requested from the pull request, with a reason and an expiry
- Suggested fixes, checked by build and blast-radius validation
§2
Record
Records how every change got in.
Each merge, approval and change to your review rules, captured from GitHub as it happens.
- Independent approval on the final commit, and the rules in force at merge
- Review rules switched off, admin bypasses and direct pushes, as events
§3
Seal
Seals every decision as evidence.
Every gate run, merge and rule change writes a signed, append-only record pinned to the commit and the rule-set version in force.
- Hash-chained and signed, with optional anchoring in Sigstore Rekor
- CSV and PDF exports per framework, repository and period
- Kept at least three years (5, 7 or 10 on Enterprise), with a copy in your own repository
Controls
Shows control status the way an audit asks for it.
Track every repository against the frameworks you’re audited for, see exceptions before they expire, and give external auditors a read-only role. Views for engineers, internal audit and external auditors.
Constraint pass rate
96.4%27 / 28 rules with no open finding on mainOpen violations
30 critical · 1 high · 2 mediumGate runs today
1412 passed · 2 blockedEvidence records
4,812last 90 days · append-only · signed| Repository | SOC 2 | DORA | Open exceptions | Last verified |
|---|---|---|---|---|
| payments-api | 6 evidenced | 1 partial | 1 | 17aa93d |
| ledger-service | 6 evidenced | 1 partial | 0 | 91ac03e |
| web-checkout | 1 failing | 1 partial | 0 | 4d2e8b1 |
| partner-gateway | 6 evidenced | 1 partial | 2 | e07f5a2 |
§4
Verify
Your auditor verifies it offline, with standard openssl.
No Toevan software and no account: open standards and stock tools. Three steps, and the answer comes back in plain words. If anything in a record was changed after it was sealed, the check says so.
- Get a copy of the evidence
Evidence lives on a branch in your client’s own repository, next to the code it describes. An ordinary folder of records.
- Confirm the key
Check that the key’s fingerprint matches the key id Toevan publishes at api.toevan.com/v1/public/evidence/keys and prints in every report. One command prints it.
- Check a record from your sample
Run the check on any record. It answers two questions: was the signed statement changed, and is this record the one that was signed?
rec_5b81d4eone record from a sample of 25 · example dataVerified OKThe statement is exactly what was signed with the published key.
record matches the statementThis record file is the one the signature covers. You can rely on what it says.
The lines the evidence branch README prints. They need only openssl and the shell.
- step 2: print the key's fingerprint and compare it with the published one
- step 3a: rebuild the exact bytes that were signed (DSSE v1), then check the signature
- step 3b: is the record file the one the signed statement names?
$ ENV=attestations/<head_sha>/<record_id>.dsse.json
$ REC=records/<head_sha>/<record_id>.json
$ PUB=toevan.pub
$ openssl pkey -pubin -in "$PUB" -outform DER | openssl dgst -sha256
SHA2-256(stdin)= <key id>
$ T=$(sed -E 's/.*"payloadType":"([^"]*)".*/\1/' "$ENV")
$ sed -E 's/.*"payload":"([^"]*)".*/\1/' "$ENV" | openssl base64 -d -A > statement.json
$ sed -E 's/.*"sig":"([^"]*)".*/\1/' "$ENV" | openssl base64 -d -A > sig.der
$ { printf 'DSSEv1 %s %s %s ' "${#T}" "$T" "$(wc -c < statement.json | tr -d ' ')"; cat statement.json; } > pae.bin
$ openssl dgst -sha256 -verify "$PUB" -signature sig.der pae.bin
Verified OK
$ H=$(sed -E 's/.*"record_hash":"sha256:([0-9a-f]{64})".*/\1/' statement.json)
$ if [ "$(openssl dgst -sha256 -r "$REC" | cut -d' ' -f1)" = "$H" ]; then echo "record matches the statement"; else echo "RECORD DOES NOT MATCH THE STATEMENT"; fi
record matches the statement
$ printf 'record %s\n' "$(sed -nE 's/.*"record_id":"([^"]*)".*/\1/p' statement.json)"
record <the record id you picked>
$ printf 'subject %s\n' "$(sed -nE 's/.*"subject":\[\{"digest":\{"([^"]*)":"([^"]*)"\},"name":"([^"]*)"\}\].*/\3 \1:\2/p' statement.json)"
subject git+https://github.com/<owner>/<repository> gitCommit:<the commit you picked>
For auditors
Built for the audit, and honest about its scope.
Every control of every framework in the catalog, mapped: where Toevan gives code evidence, where it gives process evidence, and the much larger part that stays with your organisation.
What your auditor receives
- A report per framework. For any period and repository: a PDF for the file, plus a CSV of the records for testing.
- The full evidence trail. Every code result, waiver, merge, approval and rule change, each pinned to its commit and the rule-set version in force.
- Control changes as they happen. Review rules switched off, admin bypasses and direct pushes, sealed when they happen.
- Read-only access. An Auditor role that reads the evidence, exports and reports, and sees no repositories and no code.
- Instructions that need no account. Verification runs offline with open tools against a published key.
How each fact is labelled
Every fact carries one of six labels, so your auditor knows how far to rely on it.
Both were sealed when they happened, so nothing falls between snapshots. Recount the population yourself with git and the report’s population CSV.
Integrations
Complete on its own. Connected when you need it.
Toevan needs only your GitHub repositories to gate every change, record how it got in, seal the evidence and give auditors what they ask for. Keep Semgrep, Snyk or CodeQL for depth.
- Pull request gate and exceptions with expiry
- Evidence sealed per change, and process evidence per merge
- Audit dashboards and a README status badge
- Runs on your GitHub repositories
Pricing
Start free. Talk to us when the audit is real.
Every plan seals the same evidence and verifies the same way. Plans differ in scope, reports, workflows and where Toevan runs.
Free
For a first repository and a first look at the gate.
- Repositories: up to 2 in an organization, 1 in a personal account
- Seats: up to 3 in an organization
- Sealed evidence trail with export
- Pull request gate and architecture canvas
- Official blueprint marketplace
- AI fixes: 10 a month
Team
RecommendedPriced per governed repository and billed yearly, for organizations with five to a hundred repositories.
- Repositories: 5 to 100, priced per governed repository, billed yearly
- Seats: unlimited
- Frameworks: every framework
- Deep Check, under fair use
- Per-repository roles
- AI fixes: included, under fair use
- Compliance reports in CSV and PDF
- SSO (SAML and OIDC), coming soon
Start with a pilot: one repository and one framework, through one audit cycle.
Enterprise
More than a hundred repositories, or custom terms.
- Repositories: more than 100
- Self-hosted or private-VPC deployment, on request
- Evidence retention: 3, 5, 7 or 10 years, your choice
- Priority support
- Volume terms
| Feature | Free | Team | Enterprise |
|---|---|---|---|
| Evidence | |||
| Sealed evidence trail with export | Included | Included | Included |
| Offline verification with open tools | Included | Included | Included |
| Compliance reports in CSV and PDF | Not included | Included | Included |
| Audit log | Not included | Included | Included |
| Evidence retention | At least 3 years | At least 3 years | 3, 5, 7 or 10 years, your choice |
| Gate and controls | |||
| Pull request gate and architecture canvas | Included | Included | Included |
| Official blueprint marketplace | Included | Included | Included |
| Compliance frameworks | Not included | every framework | every framework |
| Exception workflows | Not included | Included | Included |
| Deep Check pre-merge analysis | Not included | under fair use | under fair use |
| Scale and support | |||
| Repositories | up to 2 in an organization, 1 in a personal account | 5 to 100, priced per governed repository, billed yearly | more than 100 |
| Seats | up to 3 in an organization | unlimited | custom terms |
| AI fixes | 10 a month | included, under fair use | included, under fair use |
| Bring your own LLM keys | Not included | Included | Included |
| Priority support | Not included | Not included | Included |
| Volume terms | Not included | Not included | Included |
| Integrations and security | |||
| Slack and webhook notifications | Not included | Included | Included |
| Per-repository roles | Not included | Included | Included |
| SSO (SAML and OIDC) | Not included | Soon | Soon |
| Self-hosted or private-VPC deployment | Not included | Not included | on request |
There are no list prices yet. Team is priced per governed repository and billed yearly, and we agree it with you.
Questions we hear first
Straight answers on scope, determinism and where your code goes.
Something we haven’t answered?- Write to uspilots@toevan.com
- Ask on a 45-minute pilot callBook a call
- Auditing a Toevan customer?More answers for auditors
Scope and fit
3 questionsDo we have to replace Vanta, Kosli or our scanners?
No. Toevan works on its own for the code layer, and alongside the tools you have. Keep your scanners for depth; Toevan’s own checks give every change a baseline and decide the merge against your rules. Signed verdicts flow into Kosli as attestations, and Toevan’s reports attach to controls in Vanta, Drata or your own register.
What Toevan adds is a sealed record computed from the change itself: what every change does, and since v1.4.0 how it got from commit to production, signed when it happened and checkable offline with standard openssl.
Does a green report mean we’re compliant?
No, and every report says so. Toevan gives evidence for the controls that live in code, and since v1.4.0 in your change process. It never certifies a control or expresses an opinion on whether controls are designed or operating effectively. Access reviews, incident response, resilience testing, third-party risk and governance stay with your process, and every report lists exactly what it doesn’t cover.
Do you only support GitHub?
GitHub today, through a GitHub App with check runs and pull request annotations. Since v1.4.0 it also reads merges, reviews, rule changes and production deployments as they happen. GitLab and Bitbucket are on the roadmap. If one of them is your blocker, tell us and it moves up.
How it runs
3 questionsIs the enforcement really deterministic?
Yes. Blueprint constraints are evaluated against the dependency graph with no model in the loop: same input, same verdict, every run. AI is used to suggest fixes and explain violations, never to decide whether code complies.
Does our code leave our boundary?
Analysis, blueprint evaluation, the pull request gate and evidence signing run on Toevan’s own EU infrastructure, and your source code is not sent outside it. Dependency checks send package names and versions, except those Toevan identifies as private, to public services such as OSV.dev. Optional AI features can send code-derived context to an EU provider or to your own provider key. Rekor anchoring, built in and opt-in per organisation, publishes record hashes only. Self-hosting is available on request. The full statement is on the Security page.
What happens when the gate is wrong?
You request an exception with a justification, scope and duration. The right owner reviews it, it expires on schedule, and the exception itself becomes evidence.
Bring one repository and your next audit.
Pilots start in Q1 2027 with a small group of design partners: regulated teams shipping AI-assisted code, from Series B to enterprise. The first audit cycle is the proof.
- One repository, one framework
- Evidence from the first pull request
- Verifiable without a Toevan account