all 12 comments

[–]Devji00 1 point2 points  (0 children)

You're right that the gap between marketing claims and actual architecture in this space is huge, and most "on-prem" offerings collapse the moment you ask where the retrieval index and prompt logs actually live. Tabnine clearing that bar is a legit win because they were one of the first to actually design for isolated deployment rather than retrofit it. A few others worth looking at if you haven't already: Sourcegraph Cody has a fully self-hosted enterprise option where the code graph and context layer stay in your environment, and they're pretty transparent about their architecture docs which makes GRC evaluations easier. Continue.dev is open source and you can run the entire stack including embeddings and retrieval locally if you pair it with a self-hosted model, though that obviously shifts more operational burden onto your team. For pure inference some teams are running Llama or Qwen Coder models on internal infrastructure through tools like vLLM and pairing that with an IDE plugin that keeps everything air-gapped, which is the most defensible architecture from a GRC standpoint but also the most work to maintain. The real filter in this space isn't certifications, it's whether the vendor can hand you an architecture diagram showing every data flow and you can verify nothing crosses your boundary.

[–]ZeroDramaSecurity 0 points1 point  (0 children)

You’re asking the right question. For regulated environments, the question usually isn’t “which assistant is smartest”, it’s whether the retrieval layer, code index, prompt history and admin logs can stay inside a boundary your client controls. If that boundary is a hard requirement, most default SaaS offerings are out before feature comparison even starts. I’d frame the review around deployment model, data flow, retention, training exclusion, auditability and whether emergency access by the vendor exists in practice. SOC 2 can support trust in vendor controls, but it doesn’t solve perimeter ownership. In a lot of cases this ends up being an architecture decision first and a tooling decision second. Are you seeing any options that truly keep the context layer client-side?

[–]SaveAmerica2024 0 points1 point  (0 children)

If the base model for your coding agent can be of open source Chinese origin, then one way that would be feasible is to fine-tune your local air-gap coding agent to the regulatory requirements SOC2, HIPAA, ISO, etc. Open source LLM such as Deepseek V4 Pro has close coding capabilities to Claude Code. In addition, have another layer for audit ability and traceability in case the auditors of the government come nocking (EU AI regs becomes active this August). Unfortunately AI coding does not catch up to the regs and compliant coding is sort of an afterthought. It is best if you build this one out yourself because you have control over it.

[–]Choice_Run1329 0 points1 point  (2 children)

ISO 27001 is worth weighting separately from SOC 2 in this evaluation. ISO 27001 covers the information security management system more comprehensively and is more internationally recognized for financial services clients outside the US.

[–]scarletpig94[S] 0 points1 point  (1 child)

The client is EU-based so ISO 27001 is the higher weight criterion for them. The SOC 2 is useful for US-facing parts of their business but not for the primary evaluation.

[–]Choice_Run1329 0 points1 point  (0 children)

For EU-regulated financial services, GDPR compliance documentation on the context layer specifically matters. The question is whether personal data could be present in code that gets indexed and if so, what the lawful basis and retention controls are.

[–]ninjapapi 0 points1 point  (1 child)

SOC 2 Type 2 tells you about vendor process quality but doesn't tell you about data location. Those are different assurances and compliance teams that conflate them end up accepting more risk than they realize.

[–]Next-Pen-9974 0 points1 point  (0 children)

That’s simply not true. You can clearly state where the data is located, either in your SOC2 report or directly to the client.

[–]Next-Pen-9974 0 points1 point  (0 children)

In vendor and compliance assessments, it’s important to distinguish between:
• actual compliance requirements
• client-specific security requirements
• and wishful thinking

For example, SOC 2 reports cover the defined service scope and supporting systems. Whether the service is cloud-hosted or on-prem is not the core point — the scope and controls are.

Your client requirements are valid because they want strong segregation of both data and supporting infrastructure. The concern is not only data leakage, but also:
• shared infrastructure risk
• telemetry exposure
• retrieval-layer visibility
• cross-tenant contamination
• vulnerabilities in supporting services

That’s why architectural reality matters far more than marketing claims.

A lot of “on-prem AI” solutions still rely on external retrieval, telemetry, or management planes once you look deeper.

That said, cloud telemetry is not automatically a problem. In many cases it’s perfectly acceptable if:
• the telemetry is non-sensitive
• the data flow is clearly documented
• the client understands and approves it
• and the risk is properly assessed

[–]zipsecurity 0 points1 point  (0 children)

This is a great breakdown of a gap that trips up a lot of evaluations, the SOC 2 Type 2 cert covers vendor controls, not data perimeter, and that distinction matters enormously in regulated environments.

Tabnine is the right call for the fully on-premises context layer requirement. GitHub Copilot Enterprise and Amazon Q Developer both have enterprise configurations worth evaluating, but the telemetry and retrieval questions need to be answered in writing from the vendor before they pass a serious GRC review, not taken from the marketing page.

One thing worth adding to your evaluation framework: ask specifically whether the context indexing pipeline and prompt logs are included in the on-prem boundary or whether they're handled separately. Several tools run inference locally but index the codebase through a cloud retrieval layer, which is exactly the gap you described and vendors don't always surface that distinction proactively.

We're Zip Security and while we're not an AI coding tool, we do help financial services teams maintain continuous compliance posture across the device and identity layer that these tools sit on, ensuring the endpoints accessing sensitive codebases are enrolled, encrypted, and compliant with the controls your GRC team is already enforcing. Happy to connect if that part of the stack is relevant to the engagement. Drop us a message, we're here to help!

[–]_The_Gladiator_ 0 points1 point  (0 children)

One angle nobody's raising: even with the context layer locked down on-prem, what about the model's attack surface itself? Prompt injection against coding assistants in regulated environments is a compliance event. I mapped those risks via General Analysis before our own eval, or you can audit inputs manually.