AI12 November 20267 min read

AI in the pipeline without code leaving the building: Secupipe with a local LLM

Many companies would like AI to fix their vulnerabilities but will not send source code to a cloud provider. They do not have to. The Secupipe AI agent runs on your CI runner and can work with a language model hosted on your own server. Code, error logs and prompts then stay entirely inside your network.

What holds companies back from AI

Data leakage: source code is a trade secret. Nobody wants it stored with a third party or fed into training.
Data protection: almost every repository holds personal data, such as names and email addresses in commits, test data or samples from customer systems.
Control: an AI that acts on its own needs clear limits and a human who approves.

A local model answers the first two points technically. Secupipe already solves the third: the agent opens a pull request and never merges.

What GDPR requires when code goes to an AI provider

As soon as a repository contains personal data, handing it to an AI service is processing by a third party. That brings obligations:

Topic	AI provider in the cloud	Local LLM
Processor (Art. 28 GDPR)	Contract with the provider required, sub-processors to be checked	Not needed for the model: you process the data yourself
Third-country transfer (Art. 44 ff. GDPR)	Providers outside the EU need a legal basis, such as an adequacy decision or standard contractual clauses	Does not happen
Trade secrets	Confidentiality depends on the contract and the provider's settings	Code stays in your own environment
Training on your data	Excluded depending on plan and contract, has to be checked	Technically excluded: the model learns nothing from requests
Security of processing (Art. 32 GDPR)	Shared between the provider and you	Entirely yours

The last row belongs to an honest calculation: a local model removes contracts and transfer assessments, not the responsibility. The processing still belongs in your record of processing activities (Art. 30 GDPR), and the server running the model has to be secured. The EU AI Act also requires that staff who work with AI are sufficiently trained (Art. 4). This post is a technical overview and not legal advice.

The architecture

Architecture: repository, CI runner with the Secupipe agent and the local LLM sit inside your network. Secupipe only receives the result; no AI provider in the cloud is needed. — **Everything that sees source code sits inside your network.** Secupipe supplies jobs and receives the result.

Secupipe knows your findings from the SBOMs and creates jobs: package, version, vulnerability.
The agent on your CI runner picks up the jobs, checks out the repository, bumps the dependency and runs build and tests.
If the update breaks the build, the agent asks the local LLM. Code and error log go to your own server, and the answer comes back from there.
The agent opens a pull request. Your team reviews and merges.
Secupipe only receives the result: file, line, description, status and the link to the pull request. No source code.

The same picture applies to the AI code scan: the agent reads the repository on the runner, the model answers from inside your network, and Secupipe only receives the findings.

Which model fits?

The agent works in many small steps: reading files, running commands, writing changes. The model therefore has to handle tool calls reliably and offer a large context window. As of November 2026, two open models stand out:

Model	For whom	Hardware	License
Qwen3-Coder-Next 80 billion parameters, about 3 billion active	Our recommendation if you have a GPU server. Built for coding agents, 256,000 tokens of context.	about 48 GB of GPU or unified memory	Apache 2.0
Devstral Small 2 24 billion parameters, by Mistral AI in Paris	The entry point on small hardware. Often enough for the typical adjustment after a version jump.	one 24 GB graphics card	Apache 2.0

According to their makers, both models solve around 70 percent of the tasks in the SWE-bench Verified benchmark. The best cloud models score higher, mainly on changes that span many files. For Secupipe this matters less than it sounds: the model does not decide on the fix, your build and your tests do. If they do not turn green, the result is a draft pull request with the error log, and a human takes over.

If you want both, combine them: a local model for repositories with sensitive code, a cloud model in a European region for the rest. The model can be set per pipeline.

How to set it up

You need a server running the model, for example Ollama from version 0.14 or vLLM, and a CI runner of your own that can reach it. The agent speaks the interface Ollama offers out of the box. In GitHub Actions:

jobs:
  autofix:
    runs-on: self-hosted # your own runner inside your network
    container: ghcr.io/costa-chown/secupipe-autofix:1
    steps:
      - uses: actions/checkout@v5
      - run: secupipe-autofix
        env:
          SECUPIPE_TOKEN: ${ secrets.SECUPIPE_TOKEN }
          GITHUB_TOKEN: ${ github.token }
          REPO: ${ github.repository }
          ANTHROPIC_BASE_URL: http://llm.intern:11434 # your LLM server
          ANTHROPIC_API_KEY: lokal   # placeholder, not checked locally
          KI_MODEL: qwen3-coder-next
          ANTHROPIC_DEFAULT_HAIKU_MODEL: qwen3-coder-next
          CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC: 1

Three notes for operation:

Context window: set at least 64,000 tokens on the LLM server. With less, the agent loses track in larger repositories.
Network: the LLM server needs no internet access and should only be reachable from the runner.
Trial run: let the agent work with DRY_RUN=1 on a non-critical repository first. It then pushes nothing and opens no pull request; the log shows how far it gets.

We set this up with you on request, including the choice of model and hardware. How fix PRs work in general is covered in Vulnerability found, pull request opened.

Start for free Request setup