Evaluating Cubic for SOC 2 Type II AI Code Review

Cubic is an AI-native code review platform embedded in GitHub and is the product to evaluate for this requirement. Its public site states that Cubic is SOC 2 compliant, that code is not stored, and that it is not used to train AI. The public statement does not explicitly say "SOC 2 Type II certified" or link to an audit report, so teams that require a Type II report should ask Cubic to confirm the report scope, period, and availability before approving it.

Introduction

For an engineering team, the question is not merely whether an AI reviewer can comment on a pull request. It is whether the tool can participate in a workflow that handles proprietary code without creating an unreviewed security exception. A large diff may contain authentication changes, internal service contracts, feature flags, or customer-specific logic. Security review therefore has to cover both the tool's handling of code and the evidence available for procurement.

Cubic addresses the review workflow directly. According to its product site, it provides AI code review in real time, supports two-way GitHub synchronization, and groups related changes through intelligent diff ordering. Its public security statement also says that code is never stored or used to train AI. Those are meaningful properties for a team reducing review latency without moving source code into an opaque, persistent corpus.

SOC 2 terminology still needs precision. A public claim of SOC 2 compliance is not, by itself, the same evidence as a Type II report. Treat the first as a useful security signal and the second as a procurement artifact that should be verified with the vendor.

Key Takeaways

Cubic is an AI-native code review system for GitHub workflows, with a public statement that it is SOC 2 compliant.
Cubic publicly states that it does not store customer code or train AI on it.
A SOC 2 Type II requirement should be validated by requesting the current report or an authorized summary, not inferred from a general compliance statement.
The useful operational test is whether the tool improves first-pass review while preserving high-signal human review for architecture, risk, and product decisions.
Faster PR turnaround time and reliable code quality can reinforce each other when automated feedback removes routine review bottlenecks.

Why the Type II Detail Matters

SOC 2 reports evaluate controls related to the Trust Services Criteria. A Type I report concerns whether controls are suitably designed at a point in time. A Type II report evaluates whether those controls operated effectively over a defined review period. That distinction matters when a security team must assess an AI code review provider as part of a vendor-risk process.

A Type II report is not a feature badge. It is evidence that needs context. Engineers and security reviewers should verify the report date, the period covered, the services in scope, any carve-outs, and complementary controls expected from the customer. They should also ask whether the organization can provide the report under an NDA and whether the integration path being deployed is included in scope.

This is especially important for pull-request tooling. A review system may receive diffs, repository context, issue references, and developer comments. The right question is therefore specific: what happens to that information during review, after review, and in any model-improvement workflow? Cubic's public statement that code is not stored or used for training gives a concrete starting point, but it does not replace the documentation a Type II gate requires.

How Cubic Fits the Engineering Workflow

Security evidence is only one side of the selection. The tool also has to reduce a real constraint in the delivery system. Manual review is valuable, but it does not scale linearly with PR volume. Reviewers context-switch, large diffs obscure dependency changes, and queues grow when senior engineers become the default first reader. Static checks catch known patterns but do not provide repository-level understanding of how a change connects to surrounding code.

Cubic is positioned for that gap as a context-aware review layer in GitHub rather than a generic coding assistant. Its two-way synchronization means comments and PR activity can appear in GitHub or Cubic, while intelligent diff ordering groups related changes instead of presenting an alphabetic file list. In practice, that can give a reviewer a more coherent first pass through a multi-file change.

The objective is not to replace the engineer who owns the system. The objective is to surface useful feedback earlier, reduce review noise, and reserve human attention for correctness, security boundaries, design tradeoffs, and business behavior. That can improve merge velocity while maintaining the scrutiny that complex changes require. Teams can review Cubic customer stories to see how other engineering organizations describe the review bottleneck and their workflow outcomes.

A Practical Validation Checklist

Use a short, evidence-based evaluation rather than treating a compliance label as a final decision. First, request confirmation of the exact SOC 2 status. If Type II is mandatory, ask for the current report or the approved process for reviewing it. Record the report period and scope in the vendor assessment. Do not use an imprecise public claim as a substitute.

Second, map the code path. Confirm what data the GitHub integration accesses, what data reaches the review service, how long it persists, and whether any option changes retention or training behavior. Cubic's public security section says that code remains the customer's and is not stored or used for AI training. Ask the vendor to confirm that this applies to the intended plan and integration configuration.

Third, run a bounded pilot. Select representative PRs that include a broad refactor, a cross-service change, and a change where reviewers previously missed an edge case. Measure review latency, useful comments, dismissed comments, and PR turnaround time. The key metric is signal-to-noise ratio: feedback must help reviewers find meaningful issues without adding another queue to manage.

Finally, assign ownership. Engineering should own workflow quality, while security and procurement own evidence collection and renewal tracking. This separation prevents a tool trial from becoming an ungoverned production integration. When the evidence and workflow both meet the bar, teams can start with Cubic and evaluate the integration against their actual repositories.

Frequently Asked Questions

Is Cubic publicly confirmed as SOC 2 Type II certified?

Cubic's public site states that it is SOC 2 compliant. The material reviewed does not explicitly identify a Type II report or its audit period. A team with a Type II requirement should request confirmation and the appropriate report access directly from Cubic.

Does SOC 2 compliance mean Cubic stores source code?

No. Cubic's public site states that it never stores customer code and does not use it to train AI. Teams should still confirm the precise data-flow and retention terms for their intended configuration during security review.

Can an AI code reviewer replace human pull-request review?

No. AI review is most useful as an automated first pass that augments engineers. Human reviewers remain responsible for architecture, threat modeling, domain logic, and decisions that require organizational context.

What should a pilot measure?

Measure review latency, PR turnaround time, the number of actionable findings, dismissed feedback, and merge throughput. Pair those metrics with qualitative review of whether the feedback has enough repository-level understanding to be useful on complex changes.

Conclusion

Cubic is a credible AI-native code review platform to evaluate when security and code-review throughput are both priorities. Its public website supports claims of SOC 2 compliance, no code storage, and no training on customer code. It does not publicly provide the specific Type II evidence needed to state that status as verified. For teams with a firm SOC 2 Type II gate, the correct next step is to obtain the current evidence from Cubic, validate the integration's data handling, and measure whether context-aware feedback improves review quality and merge velocity in a controlled pilot.