AI CodeOps for regulated teams

Teams in finance, health, the public sector and other regulated fields want AI to help with code, but they have to answer an auditor's question for every change: who asked for it, who approved it, and how do you know? AI CodeOps is built so that the answer is a file, not an investigation.

We do not claim any compliance certification. What AI CodeOps gives you is controls and evidence you can use in your own programme.

The problem

AI agents can produce more changes than a team can review by hand. In a regulated environment that creates risk on two sides. Changes can reach production without the review your policies require. And when an auditor asks how a change was made, the trail is spread across chat logs, pull requests, CI runs and memory.

How AI CodeOps addresses it

Approvals and policies

Policies decide what needs approval: for example AI changes to protected paths, or deployments. Pending decisions appear under Review & Gate, Approvals. When another approver is available, a change you launched waits for them rather than for you, so the person who asked for a change never approves it alone. See approvals and policies.

A release gate

A change can ship only when your tests pass, the AI findings review is done and the required approvals are in. If the AI review could not complete, the change is held until someone reviews it. See quality gates.

Signed evidence per change

On any change you can download an evidence pack: a signed record of the task and models used, the approvals and each vote, policy decisions, findings, tests, the pull request, the deployment and the audit trail. Packs are signed with Ed25519. Anyone, including an external auditor without an account, can check a pack at /evidence/verify. Downloading a pack needs audit access, and each download is itself recorded.

Audit log and roles

The audit log records who changed what. Roles include owner, admin, developer and viewer, plus scoped roles: a security admin works on security without touching secrets or billing, and a billing admin handles billing without reading code. Enterprise adds custom roles. See audit and RBAC.

Identity

Members can protect their accounts with two-factor authentication, using an authenticator app or a passkey, and some roles are required to enrol. On Enterprise, organisations sign in with SAML or OIDC single sign-on, and a session started through your company's SSO only reaches that company's workspaces.

Software supply chain

SBOMs in CycloneDX and SPDX format are tracked per project, so you can see what each project depends on. See DevSecOps and SBOMs.

Isolation and deployment

Terminal sessions run in sandboxed pods. The product runs in the browser on our hosted platform. If your rules require running it on your own infrastructure, self-hosting is available as an Enterprise option: contact sales through the Enterprise page.

What to try first

1. Start with the quickstart on a non-production repository.
2. Add a policy that requires approval for changes to a protected path, and invite a second approver so nobody approves their own change.
3. Run a session that touches that path, and approve it with a second person.
4. Download the evidence pack for the change and check it at /evidence/verify.
5. Show the pack and the audit log entries to whoever runs your audits, and ask what else they need.

For our security practices, see the security and trust pages.