If you work at a bank, a fintech, a healthcare company or a government agency, you probably already know the rule: you do not paste proprietary code into ChatGPT, Claude or Copilot, not even to ask "is this secure?". That rule exists for good reasons. But it also means the teams with the most to lose from a vulnerability are the ones cut off from AI code review. A self-hosted LLM for code security is how you close that gap without breaking the rule.
This guide explains why the restriction exists, what the real risks are, the deployment options for private AI, what to evaluate in a vendor, and why an auditable, tamper-evident log of every AI call is the piece that turns "trust us" into proof.
Why regulated teams cannot paste code into public AI tools
Source code is not just text. It contains the design of your authorization model, the names of internal services, database schemas, sometimes test fixtures with real-looking customer data and, far too often, credentials. For a regulated company, it is also intellectual property and, in many cases, information covered by contractual or legal confidentiality.
When a developer pastes a file into a general-purpose AI assistant, several things happen that are outside the company's control:
- The code crosses the perimeter to a third party the security team may not have reviewed.
- It may be retained. Depending on the product and plan, prompts can be stored for abuse monitoring, debugging or history features.
- It may be used for training. Consumer tiers of some assistants use conversations to improve models unless the user opts out. Business and API tiers usually do not by default, but that is a contract term you must verify, not an assumption.
- There is no audit trail on your side. You cannot prove afterwards what was sent, by whom, or to which model.
That is why many regulated organizations block these tools at the proxy, or allow them only through an approved enterprise contract. It is also why "shadow AI", developers using personal accounts anyway, is a real concern.
The specific risks: retention, training and compliance
Data retention
Even when a provider promises not to train on your data, it may keep inputs for a limited window for safety and abuse monitoring. Zero-data-retention arrangements exist for some enterprise API customers, but they are negotiated, not default. For code that includes secrets or customer data, "retained for a while on someone else's servers" is already an incident waiting to be classified.
Model training and memorization
The concern here is not that a model will recite your repository to a stranger tomorrow. It is that once data enters a training pipeline you lose the ability to guarantee where it ends up, and you cannot delete it with certainty. For trade secrets, that loss of control is the problem.
Compliance frameworks
- GDPR: if code, logs or fixtures contain personal data, sending them to an AI provider makes that provider a processor. You need a data processing agreement, a lawful basis and, if data leaves the EU, a valid transfer mechanism.
- HIPAA: source code is not usually protected health information by itself, but test data, logs and database dumps in a repository can be. Sharing PHI with a vendor requires a business associate agreement.
- SOC 2: auditors will ask how you manage vendors that touch sensitive data and how you control and log access. An unreviewed AI tool with no logs is a finding.
- Bank secrecy and financial regulation: banks in many jurisdictions have legal duties of confidentiality over customer information and strict outsourcing rules for any third party that processes it. Security teams usually treat core banking code as in scope.
- Government and defense: data residency and classification rules often forbid processing by foreign or multi-tenant services at all.
Deployment options for private AI code review
"Self-hosted AI" covers several architectures with different trade-offs:
| Option | Where the model runs | Pros | Cons |
|---|---|---|---|
| On-premises LLM | Your own data center or GPUs | Maximum control, works air-gapped | Expensive hardware, you operate and update the model |
| VPC-hosted LLM | A dedicated deployment in your cloud account | Code stays in your cloud boundary, fits existing controls | You still manage GPUs, scaling and model quality |
| Vendor-hosted private model, ephemeral inference | The vendor's own model on short-lived, dedicated infrastructure | No ops burden, no third-party AI provider in the path | You rely on the vendor's controls, so you need proof |
| Third-party API with zero retention | A frontier model provider under a contractual no-retention agreement | Strong general models | Code still leaves to another company; contract-dependent |
| Public chat assistant | Shared consumer service | Convenient | Usually not acceptable for regulated code |
Ephemeral inference deserves a closer look. The idea is simple: an isolated environment is created for a scan, the model analyzes the code there, results are returned, and the environment is torn down. Nothing persists between customers, and there is no long-lived store of prompts to leak later.
What to evaluate before any AI touches your code
- Where exactly does the model run? Your hardware, your cloud account, the vendor's dedicated infrastructure, or a shared third-party API? Get the answer in writing, including region.
- Which model, and whose? Is it the vendor's own model, or a wrapper around OpenAI, Anthropic or Google? Wrappers are fine for many companies, but you must know.
- What is retained, and for how long? Source code, prompts, model outputs, findings, logs. Each can have a different policy.
- Is anything used for training? The default and the opt-out mechanism should be explicit.
- Is there an audit trail of every AI call? Can you see which model processed which files, when, and for what purpose? Can the log be altered silently?
- How good is the model at security? Privacy is worthless if the findings are noise. Ask for results on a repository you know well, and look at false positives and whether findings point to a concrete file and line.
- What happens when an external model is used? Some features, like generating a fix, may use a frontier model. That should be opt-in, explicit and logged.
How a self-hosted security model analyzes code without it leaving controlled infrastructure
A self-hosted security model does roughly what a reviewer does, but inside a boundary you can reason about:
- Fetch the repository with scoped, read-only access into an isolated environment.
- Build context: routes, handlers, data models, dependency manifests, CI workflows, infrastructure as code.
- Reason about attack paths: follow untrusted input across files, check that each sensitive operation has an authorization check, look for injection, unsafe deserialization, secrets and misconfigurations. This is the same reasoning that makes AI code review useful, and it complements classic static code analysis; see SAST vs DAST for how the layers fit.
- Validate and rank findings by exploitability rather than raw pattern matches.
- Record every model call in an audit log, then tear the environment down.
The key property is that no step in the analysis requires sending code to a general-purpose third-party AI provider. That is what makes an AI vulnerability scanner usable in environments where public assistants are banned.
The audit log is the proof
"We don't send your code anywhere" is a claim. An auditable, tamper-evident audit log is evidence. The standard technique is a hash chain: each log entry includes a cryptographic hash of the previous entry, so the log forms a chain that cannot be edited in the middle without breaking every link after it.
{
"seq": 1042,
"timestamp": "2026-09-23T14:02:11Z",
"scan_id": "scn_8f3a",
"purpose": "vulnerability_analysis",
"model": "self-hosted-security-model",
"provider": "self-hosted",
"input_sha256": "9c1e...a7",
"output_sha256": "44b0...1d",
"prev_hash": "e3d9...52",
"entry_hash": "sha256(prev_hash + canonical_json(entry))"
}With a log like this you can answer the questions an auditor or a customer's security team will ask:
- Which model processed our code? Every call names the model and the provider.
- Did any third-party AI see it? Filter entries by provider. If an external model was used, there is an entry for it, with the consent that authorized it.
- Has the log been altered? Recompute the chain. A single edited or deleted entry breaks every hash that follows.
- What exactly was sent? Hashes of inputs and outputs let you verify content without the log itself storing the code.
Verification is cheap. Anyone can recompute the chain:
prev = GENESIS
for entry in log:
expected = sha256(prev + canonical_json(entry.without_hash))
assert entry.prev_hash == prev
assert entry.entry_hash == expected
prev = entry.entry_hashFor stronger guarantees, periodically anchor the latest hash somewhere the vendor cannot rewrite, for example by exporting it to your own storage or SIEM.
How Nurbak approaches it
As one concrete example: Nurbak connects to GitHub and scans a repository with its own self-hosted AI model running on ephemeral infrastructure, so the analysis does not send your code to OpenAI or Anthropic. Each AI call is recorded in an auditable, hash-chained audit trail. The scan reports exploitable vulnerabilities with file and line, checks dependencies against known CVEs, flags GitHub Actions, Docker, Terraform and Kubernetes misconfigurations and secrets in git history, and produces a 0 to 100 security score with plain-language explanations.
There is one place where an external model is involved, and it is opt-in: Nurbak can open a pull request with the fix and a security regression test, and that fix is generated with Claude only after the user gives explicit consent. That consent and the call are recorded in the same audit trail, so the record shows exactly when code left the self-hosted boundary and why. The free scan shows the three most important findings in full; paid plans start at USD 79 per month. You can see how it works on the AI vulnerability scanner page.
A practical policy for AI in your code pipeline
- Classify repositories. Not every repo is equally sensitive. Public SDKs and core banking services deserve different rules.
- Default to self-hosted analysis for sensitive repositories; allow external models only per feature, with explicit consent.
- Require an audit trail of every AI call from any vendor, and export it to your own systems.
- Scan for secrets first. A key in git history is a problem regardless of which model reads it.
- Keep humans in the loop. AI findings and AI fixes go through normal pull request review, like any other change.
- Revisit the policy as models and contracts change. What is true of a provider's retention today may not be next year.
This fits naturally into a DevSecOps program: the same pull request gates, now with an AI reviewer you are allowed to use. Findings map well to categories like those in the OWASP Top 10 2025, and for anything the AI cannot judge, you still have penetration testing.
Bottom line
Regulated teams are right not to paste code into public AI assistants. The answer is not to give up on AI security review, but to move the model to the code: on-prem, in your VPC, or on a vendor's own model running on ephemeral infrastructure, with no third-party AI in the path by default. Then demand proof, not promises: a tamper-evident log of every AI call, including the rare, consented ones that do use an external model. If a vendor cannot show you that log, assume your code is going somewhere you cannot see.