Why AI Coding Tools Fail the Security Review in Regulated Industries

"We piloted Cursor for three months. Security came back and said we cannot use it — code is leaving our environment, there is no BAA in place, the per-developer installs create a governance nightmare we cannot audit, and our compliance team flagged it for PHI risk." Healthcare, fintech, insurance, and other regulated industries are not blocking AI coding tools out of excessive caution. They are blocking specific deployment architectures that are fundamentally incompatible with their compliance requirements.

This distinction matters because it means the problem is solvable. The issue is not AI coding tools as a category. The issue is that the dominant architecture — per-developer installs, personal API keys, code transmitted to third-party endpoints — was designed for developer productivity, not for enterprise compliance. That architecture fails the security review in regulated industries every time, for the same reasons, regardless of which tool is being evaluated.

This post maps exactly what security teams flag, why those concerns are structurally valid, and what a compliant architecture actually requires for healthcare, fintech, and other regulated environments.

What security teams actually flag

The security review for an AI coding tool in a regulated environment is not a general assessment of the tool's quality. It is a checklist against specific compliance requirements. The failures cluster into four categories that appear in essentially every review at every regulated company.

What security teams check when reviewing an AI coding tool:

  DATA HANDLING
  [ ] Does code leave the environment? Where does it go, and in what form?
  [ ] Is there a Business Associate Agreement available for PHI-adjacent workflows?
  [ ] Is there a Data Processing Agreement for regulated data?
  [ ] What is the vendor's retention policy for transmitted code context?
  [ ] Can the vendor provide a subprocessor list?

  ACCESS CONTROLS
  [ ] Is this a per-developer install or a centrally managed platform?
  [ ] Is there a central audit log of what was queried and by whom?
  [ ] Can access be provisioned and deprovisioned centrally?
  [ ] Are API keys managed at the org level or at the individual level?

  AUDIT TRAIL
  [ ] Can the security team produce a log of queries on demand?
  [ ] Does the log capture which repositories were accessed and when?
  [ ] Is the log producible for a SOC 2 auditor or HIPAA review?

  COMMON FAILURES
  [x] Per-developer installs with no central management — FAIL
  [x] API keys per developer, no rotation policy — FAIL
  [x] Code transmitted to third-party endpoints, no BAA — FAIL
  [x] No audit trail of what data left the environment — FAIL

The first failure — code leaving the environment without a BAA — is the HIPAA disqualifier. The second — per-developer installs with no central management — is the SOC 2 disqualifier. The third — API keys per developer with no rotation policy — fails the access control requirements that appear in both frameworks. The fourth — no audit trail — fails every compliance framework that requires evidence of what accessed what and when.

These are not configuration problems. You cannot add an audit trail to a per-developer install by changing a setting. You cannot add a BAA to a vendor relationship that does not offer one. These failures reflect architectural decisions made at the product level, and they cannot be remediated by the engineering team procuring the tool.

The per-developer install problem

Every developer has their own install, their own account, their own API key. There is no central log of what was queried or what code was transmitted. If you are trying to maintain SOC 2 or pass a HIPAA audit, this is not a configuration problem — it is an architecture problem. You cannot audit what you cannot see.

The practical consequence is that the security team cannot answer the questions an auditor will ask. Which developers used the tool? Which repositories did they query? What code context was transmitted during those sessions? What is the aggregate scope of data that left the organization through this tool? With a per-developer model, none of these questions have documented answers. Each developer's usage is invisible to the organization. The audit trail does not exist because the architecture has no place for it to live.

When a developer leaves the company, their API key — if anyone remembers to revoke it — is one of forty credentials that need to be tracked down. There is no central provisioning system to deprovision. There is no record of which repositories that key accessed. This is the scenario security engineers describe when they explain why per-developer AI tool usage is ungovernable regardless of the underlying tool's quality.

Code leaving the environment

Most AI coding tools send code context to third-party APIs for completion. For general software companies, this is an acceptable trade-off that developers make knowingly. For healthcare companies handling PHI, fintech companies with financial transaction data, or any regulated entity with contractual data residency requirements, sending code to a third-party endpoint is a compliance event — not a preference.

The specific concern is not hypothetical data exfiltration. It is routine, documented, intended transmission of code context to third-party LLM endpoints that occurs every time a developer triggers a completion. A healthcare company's billing service has code comments referencing claim identifiers. An insurance platform's underwriting logic touches policyholder data. A fintech's transaction processing service handles account numbers. None of this needs to be a major leak for it to be a compliance event — it just needs to touch a third-party endpoint without the proper agreement in place.

The compliance framework does not distinguish between intentional exfiltration and routine API transmission. Both require the same controls: a documented agreement with the receiving party, data residency clarity, and an audit trail demonstrating what was transmitted and under what policy.

HIPAA requirements for AI tools

HIPAA does not prohibit AI coding tools. It requires that any service that might touch PHI has a Business Associate Agreement. Most AI coding tool providers do not offer BAAs on standard plans. Some offer them on enterprise plans — but the enterprise plan does not retroactively govern the three months the tool was in use before procurement escalated to a formal review.

The deeper problem is that even with a BAA in place, PHI must not be transmitted through the code context. Healthcare engineering teams working on services that handle patient data face a structural challenge: the code they write is often adjacent to PHI even when it does not directly contain it. A service that queries a patient record database has code patterns that reflect the PHI schema. An authentication service has logic tied to patient identity. A billing integration has data flows that reference claim identifiers. Getting a BAA signed does not solve the requirement that PHI not travel through an uncontrolled channel — it requires either on-premise operation or strict data governance controls that most tools do not provide.

The practical result is that HIPAA-compliant use of AI coding tools requires a managed architecture where the organization controls what reaches the external endpoint, or an on-premise deployment where no external endpoint is involved. Per-developer tools transmitting arbitrary code context to a third-party API fail this requirement regardless of BAA status.

SOC 2 Type II and what it means for AI tooling

SOC 2 Type II requires auditable access controls, evidence of what accessed what data, and the ability to respond to an auditor asking "who accessed this system and what did they do?" Per-developer AI tools with no central logging fail this requirement. The auditor does not need to find a breach. They need documented, producible evidence that access to sensitive systems was controlled and logged. If that evidence cannot be produced, the audit fails or AI tools are excluded from scope entirely — which means either blocking them or accepting an audit gap.

HIPAA and SOC 2 requirements mapped to AI tool capabilities:

  REQUIREMENT                        | TYPICAL AI CODING TOOL  | COMPLIANT ARCHITECTURE
  -----------------------------------|-------------------------|------------------------
  BAA for PHI-adjacent services      | Not offered (std plan)  | Required — or on-prem
  No PHI in code context             | Not enforced            | Data governance controls
  Auditable access controls          | Per-developer, none     | Central, role-based
  Audit log of data access events    | None                    | Central query log
  Data residency guarantee           | Not provided            | Contractual commitment
  Central credential management      | No (per-developer keys) | Yes — org-level
  Evidence for SOC 2 auditor         | Cannot produce          | Producible on demand
  Access deprovisioned on offboarding| No                      | Centrally managed
  Subprocessor list                  | Sometimes               | Required contractually

SOC 2 auditors are increasingly asking about AI tool usage. The question has moved from the edge of security reviews to a standard line item. Teams that adopted AI coding tools on a per-developer basis without governance planning are discovering that they either cannot answer the auditor's questions or must exclude AI tools from the system's scope — which means certifying that AI tools were not used in the development of the audited system. For teams where AI tool usage is widespread, that exclusion is often not credible.

The access control requirement deserves specific attention. SOC 2 requires that access to systems handling sensitive data is role-based, centrally managed, and deprovisioned when employees leave. Per-developer AI tool installs satisfy none of these requirements. Access is not role-based — every developer has the same level of access regardless of their responsibility for sensitive systems. It is not centrally managed — each install is independent. It is not reliably deprovisioned — there is no central system to deprovision from.

The governance gap most tools leave open

Most AI coding tools were built for developer productivity, not for enterprise governance. This is not a criticism — it reflects the market they were designed for. A tool optimized for a 10-person startup has no reason to build RBAC, central audit logging, BAA templates, or data residency guarantees. Those features add complexity and cost that the target customer does not value.

The problem is that these tools are now being evaluated by regulated enterprises, and the gap between what the tool provides and what the compliance framework requires is not closeable by configuration. There is no role-based access control because the product has no concept of roles. There is no audit log because the architecture routes through individual developer accounts. There is no data residency guarantee because the vendor agreement does not commit to one. There is no BAA template because the vendor does not operate a business associate program.

These are not features that can be added by the customer. They require architectural decisions made at the product level — decisions about where data flows, how access is managed, and what logging infrastructure exists. As covered in detail when looking at why CISOs block Cursor and similar tools, the security team's concern is valid precisely because these gaps are structural, not incidental.

The governance gap also has a timing dimension. Even if a tool eventually adds enterprise features, the regulated company cannot use the tool while those features are missing. The compliance requirement exists today. The gap exists today. An enterprise tier that is "on the roadmap" does not satisfy an audit requirement.

What a compliant architecture requires

Compliant AI coding tool usage in regulated industries requires a managed platform architecture. This is not about which AI model is used or which features are available — it is about how the tool connects to the organization's systems and how that connection is governed.

What a compliant AI coding tool architecture looks like vs. what most tools offer:

  MOST TOOLS (per-developer model):
  -> Developer installs tool on laptop
  -> Developer creates personal account with personal API key
  -> Code context is sent to third-party LLM endpoint during queries
  -> No central log — queries are invisible to the org
  -> Security team cannot answer: "what code left the environment?"
  -> Auditor asks for evidence — none exists

  COMPLIANT ARCHITECTURE (managed platform model):
  -> Team connects via a single managed platform integration
  -> Access is provisioned centrally, maps to existing repo permissions
  -> Code context stays within the organizational trust boundary
  -> Central audit log: who queried what, when, from which repo
  -> BAA-eligible vendor agreement or on-premise operation
  -> Security team can answer every auditor question

  Key architectural difference:
  -> Per-developer: 50 developers = 50 unauditable data paths
  -> Managed platform: 50 developers = 1 auditable integration

The five requirements are non-negotiable for regulated industries. A managed platform — not per-developer installs — is the only model that supports central governance. An audit trail — what queries happened, when, from whom, against which repositories — is required for SOC 2 evidence and HIPAA accountability. BAA eligibility or on-premise operation is required for any service touching PHI. Role-based access control — who can query what based on their organizational role — is required for SOC 2 access control requirements. Data residency guarantees are required for any organization with contractual or regulatory residency obligations.

Kognita is built as a managed platform architecture. One connection for the whole team. The security team has one integration to audit, not forty. Central control and visibility over which repositories are indexed and who can query them. No code transmission to third-party endpoints through individual developer accounts — the data flow is repo host to Kognita's infrastructure to the developer's AI tool, through a single controlled channel. The managed agent runtime model is what makes these governance properties possible — you cannot audit what runs on forty laptops, but you can audit what runs through one connection.

The access control model maps directly to existing repository permissions. If a developer does not have access to a repository on the repo host, they do not get context from it through Kognita. There is no second permission system to maintain, no desynchronization risk between repository permissions and AI tool permissions, and no manual provisioning process when an employee joins or leaves. Access derives from the same OAuth authorization the team already manages.

Final take

Regulated industries can use AI coding tools. They cannot use per-developer, per-laptop, no-audit-trail AI coding tools. The architecture that works for a 10-person startup does not pass a HIPAA audit. It does not produce the evidence a SOC 2 auditor requires. It does not satisfy the access control requirements that appear in both frameworks. The failure is not about the underlying AI capability — it is about the deployment model.

Compliant AI coding tools require managed architectures, and those exist. The decision regulated engineering teams face is not "AI coding tools or compliance." It is "choose an architecture that was designed for enterprise governance requirements, not one that was designed for individual developer convenience and is now being asked to satisfy compliance requirements it was never built for."

The tools that fail the security review were not built to pass it. The tools that pass the security review were built for that requirement from the start.