What SOC 2 auditors ask about AI developer tools

SOC 2 has no list of approved editors

This trips people up, so it is worth being blunt. A SOC 2 report is an independent opinion on controls your organisation described, evaluated against the Trust Services Criteria. There is no schedule of permitted tools, and no auditor is going to tell you which editor to install.

What happens instead is that an AI coding assistant lands in the parts of your programme you already run, and it lands in more of them than teams expect:

• Vendor and third-party management, because you have introduced a party that may receive your data.
• Confidentiality, because customer or proprietary code may be leaving an environment you described as closed.
• Change management, because code your team did not write by hand is now entering the codebase, and your description of how changes are reviewed has to remain true.
• Risk assessment, because a new class of tool arrived after the last one was written.

Your auditor will map those to the criteria in whatever way fits your description. The point of the list is not the mapping, it is that the tool question is four questions rather than one.

The requests an auditor makes, and how to answer them

Written as a list you can work down. The second column is what Onyx Code gives you to answer with; the honest gaps are in the next section rather than hidden in this table.

What we do not have, said in the middle of the page

If you are mid-audit you have read enough vendor pages to know where the inconvenient facts usually get buried. Here they are instead.

• We do not hold a SOC 2 report. Onyx Code is a small vendor and has not been through an audit. If your programme requires a report from every vendor without exception, that is a real answer and it may be a no.
• We are not a subservice organisation for your inference. This is the part worth raising with your auditor early: in local mode we do not run infrastructure that processes your data, which is a different shape from the cloud tools your vendor questionnaire was written for. Several questions on it will not apply, and it is better to establish that at the start than to answer them awkwardly.
• The activity log is not tamper-evident. It is a local record on a machine its user controls. It evidences what the tool did; it is not a chain of custody, and presenting it as one would not survive a careful reviewer.
• There is no central management plane. No admin console, no fleet policy, no per-seat reporting today. Controls are configured per workstation and per repository, which suits teams whose repositories are the unit of control and suits large managed fleets less well.

The control nobody writes about: AI-authored changes

Most discussion of AI tooling in an audit context is about data leaving. The quieter question is what arrives: your change management description says how code gets reviewed, and an assistant that writes code has to fit inside that description rather than around it.

Two properties matter more than any policy statement here. The tool should not edit files without showing you, and it should not be able to touch paths you have excluded. In Onyx Code, AI edits are staged as diffs you apply, discard or partially accept, agent runs on the Pro tier can be sandboxed in a git worktree so the working tree is untouched until you accept, and .onyxnoai is honoured by agents rather than only by chat.

The practical consequence is that AI-authored code enters your branch through exactly the review you already described to your auditor, which means your description stays true without being rewritten.

What you can put in front of an auditor

Audit season converts every vendor assurance into a request for a document.

Whatever the framework, a review comes down to the same two questions: what did the tool touch, and can you show it. Onyx Code answers both from the machine rather than from a vendor policy page.

• AI Activity Log. Every prompt, every file the AI read, every edit it proposed, with timestamps, recorded locally.
• Audit PDF export. The same record as a document you can hand to somebody who is never going to open your editor. This is usually the artefact that ends the conversation.
• .onyxnoai exclusion patterns. Gitignore-style paths no AI surface may read: not chat, not the index, not autocomplete, not agents. It lives in the repository, so it is reviewable in a pull request and it travels with the code.
• Prompt sanitizer. Every send and attachment is scanned locally for credentials, keys, tokens and certificates, with redaction offered before the prompt is built.
• Air-Gap Mode. A switch that blocks outbound traffic, enforced in three independent layers, with blocked attempts written to the log.
• No telemetry by default. Nothing to disable and nothing to negotiate.

All of the above are on the Free tier. Privacy and audit features are never behind the paywall, which also means a reviewer can evaluate every one of them before anybody spends money. The air-gapped development page covers the enforcement mechanisms in more depth, and the documentation gives the commands to verify them independently.

Questions

Is Onyx Code SOC 2 compliant?

We do not hold a SOC 2 report, and a tool cannot be compliant on your behalf in any case: the report attests to controls your organisation described. What we can do is answer a questionnaire in writing and give you controls your own engineers can verify rather than take on trust.

Do we have to list the editor as a vendor?

That is your auditor’s call, and it usually turns on whether the vendor receives data. In local mode we do not receive prompts, code or telemetry, which tends to make for a short entry. Raise the shape early, because most vendor questionnaires assume a cloud service.

How do we evidence that code did not leave?

Turn on Air-Gap Mode and demonstrate it: attempt an action that would need the network, show the block in the application log, and check the process for established non-loopback connections. The documentation gives the exact commands, which means the demonstration is repeatable by your own team.

How do we handle AI-generated code in change management?

Keep it inside the review process you already have. Edits are staged as diffs rather than applied silently, agent runs can be sandboxed in a worktree on the Pro tier, and excluded paths stay excluded for agents as well as for chat.

Can we get a written answer to our questionnaire?

Yes. Send it over. We would rather answer a hard question in writing than have somebody guess from a marketing page, including the questions where the answer is that we do not have the thing.