Security work you can prove.

Three products, one authority boundary.

Self-service scanning brings work in. The authorised-testing control plane is where consultancies and MSPs run client engagements. The governance workspace turns the same activity into regulator-facing evidence.

A job is inside the authorised boundary, or it does not run.

Written authorisation, executor-verified ownership, an immutable scope version, then a signed manifest executed through an enforcing egress proxy. Every step is a record. How a job gets authorised

Exit gates: the Phase 0 governance baseline was signed on 2026-09-08 by an independent approver and is Sigstore-verified in CI. Phase 3 containment approval is still required before the broader active engine touches a customer estate.

The authority boundary is the thing that runs the job.

Five records stand between a request and a packet. Any drift in authority or assets invalidates the jobs, schedules and reports that depended on it.

Monitor the estate, triage the noise, keep the record.

Vulnerability and asset management, ML intrusion detection, a SIEM, and analyst agents that read and draft but structurally cannot approve, block or execute. Detection benchmark

Near-perfect on its own distribution. Honest about the rest.

The IDS benchmark as we ran it, failures included. Read it as a ceiling for a model trained on your own sensor traffic. It is not a promise about ours.

Near-perfect on the distribution it was trained on; cross-year transfer works only for families that look alike; synthetic to real collapses. That is the honest reason to retrain on your own sensor traffic, and the ingest loop ships in the box. Measured by one hand-run pass of python -m ids.benchmark on CICIDS2017 and CSE-CIC-IDS2018, recorded in services/ids/BENCHMARK.md; not reproduced in CI, no live-capture evaluation yet.

Evidence from live activity, not a spreadsheet updated by hand.

A tenant-scoped register of AI systems and risks, control assessments that collect evidence from what the platform actually did, and the obligation artefacts an EU AI Act or ISO/IEC 42001 programme is built on. Next to them, the three assurance sections of the console: SOC 2 and ISO/IEC 27001 readiness workpapers, the records a GDPR controller or processor must hold, and signed control observations you can show a customer. For compliance & risk teams

Walk into the audit with evidence, not assertions.

You have to demonstrate control over your AI systems and security posture, and the proof usually lives in stale spreadsheets. checkii generates it as you work.

1. Prepare for an EU AI Act review

   Keep the register current; generate obligation timelines and Article 11 skeletons. Arrive with the paperwork pre-structured.

2. Prove a control actually operates

   Assessments auto-collect evidence from live activity. Backed by real events rather than a checkbox ticked last quarter.

3. Show data never left the boundary

   Forced-RLS isolation, envelope-encrypted evidence, tamper-evident audit chains. A defensible chain of custody.

4. Enforce retention and deletion law

   Region-bound retention, legal holds, approved deletion. Purged content returns HTTP 410; custody metadata retained.

5. Prepare a SOC 2 or ISO/IEC 27001 programme

   Record your controls against the criteria, attach the documents, treat the risks, and let the workspace generate the Trust Services Criteria catalogue and the Statement of Applicability. The auditor receives workpapers, not a checklist you typed the week before.

6. Keep the records a GDPR controller must hold

   Processing activities, sub-processors, impact assessments, rights requests and breach records, each a revision-chained assertion with a second reviewer where the regulation expects one. Deadlines are computed from the dates you record; the judgement stays yours.

7. Answer a customer's security questionnaire with evidence

   Collectors observe your GitHub and AWS configuration and sign what they saw. Reviewed claims cite those observations, and a customer reads them through an expiring access code. Built and qualified; not yet used with a customer on the hosted beta. A claim is withdrawn the moment its evidence goes stale.

Two planes, one control plane.

Defensive and offensive share identity, tenancy, evidence and governance through one control plane, while their executable workers and network paths stay isolated.

Select a node to see what it may reach. Paths come from the network-policy manifest applied to the hosted cluster on 6 October 2026; "verified" means a connection was attempted from inside the live pod that day.

Every action leaves a sealed artifact.

The same ledger that drives your operators is the evidence your auditors sign off on, with nothing re-collected and nothing missing.

1. Scope is versioned and re-approved on every change.
2. Artifacts are hash-sealed at the moment of capture.
3. Export a signed evidence bundle on demand.

Agents draft. A human approves. The work is done where it belongs.

checkii does not patch, block or isolate anything on its own. It runs the governed path around the fix: a drafted ticket or patch, an independent approval, a hand-off to the people or the system that own the change, and a separately authorised retest that closes the finding on evidence.

1. Nothing moves without a named approver who is not the author.
2. The relay that reaches your tracker or repository holds the credential; the control plane never does.
3. A finding closes on a fresh retest, not on a status change.

1. Draft

   The ticketing agent turns high-risk findings and open alerts into tickets with a recommended fix, a suggested owner and a due date, and for tickets raised from IDS alerts the triage loop appends its evidence to the note before anyone opens it. For code, a remediation-mode job proposes a unified diff to existing files on a temporary branch; it cannot create, delete, rename or merge. The agents' client code can create and annotate. It has no method to approve, assign or close.

2. Approve

   A security approver who is not the ticket's author approves it, or rejects it as accepted risk. A proposed patch gets an independent review and a separate security review before it can be published. Every transition is audited and idempotent; the audit chain is per tenant and HMAC-sealed.

3. Hand off

   Approved tickets are queued in a transactional outbox and delivered by an isolated relay to Jira, GitHub, GitLab or Azure DevOps issues, or to a signed webhook. A reviewed and tested patch is published as a draft pull request on GitHub, the one provider the patch path supports today, which the relay creates and nobody at checkii merges. Your engineers, or the system that owns the asset, do the work.

4. Retest and close

   Only a done ticket with an independent approver can be retested, by a new assessment job linked before it starts and bound to the same tenant, finding and scope. The outcome is recorded against the original finding with its evidence, and a retest report carries that lineage. A finding closes on a fresh result, not on a status change.

Point checkii at code and sites you own.

Prove ownership once, with a well-known file on the site or the checkii verification app on the repository, and the hosted platform runs the assessment: signed manifest, egress-enforced worker, findings with remediation guidance. Start free with source scanning, then pay only when you need active testing. Running for customers today: SAST, SCA, secret scan, IaC, SBOM and validation scenarios. Web pentest requests are accepted on every plan and queue until Checkii Native is released to customer traffic; no allowance is used until a pentest runs. Container image scanning runs for authorised engagements through the console's archive upload; the self-service image-reference route is not wired yet.

After payment we provision your workspace by hand and email your sign-in details, within two working days. Payment unlocks requests; it never starts a scan.

Already subscribed? Open your workspace · Sign in to the console

Billed monthly by Stripe. To cancel or change a plan, email info@checkii.ai; there is no self-service billing portal yet. Your plan includes a set number of authorised, read-only assessments each month against repos or targets you own. Testing systems you do not own needs the authorised-testing control plane: written authorisation, asset verification, and the containment exit gate.

Request your workspace.

Enter your details and choose a route. Self-service subscriptions include source assessments and tier-based web pentest requests. Payment enables requests; it does not start a scan. Web pentests require target verification and independent approval in the assessment workspace before execution; source assessments require repository verification through the checkii verification app and then run on the commit you choose, with no approval step because nothing is sent to your systems. Offensive testing needs written authorisation and asset verification, so it opens an authorisation request. Nothing runs until it clears, and no payment is taken for it here.

Start free. Pay for what is scarce.

Source scanning is commodity, so it is free within a monthly ceiling. Active testing, evidence bundles, retests and client tenants consume real capacity, so those are what you pay for.

Team and MSP plans are delivered in the hosted console at console.checkii.ai: scope, authorisation, testing, results, operations, governance with its Audit & Assurance, privacy-records and trust-assurance sections, and the read-only defensive views, in one tenant we provision for you. Self-service plans sign in to the same console with a narrower set of sections.