Handing an external service read access to your private repository is a bigger act of trust than most connect buttons let on.
The Git repository has the code for your product that you spent months or years building. It describes how your system works, where the sensitive parts live, and occasionally contains things that were never supposed to leave secure storage in the first place. So the questions people ask us before connecting are the right ones. Does lumioguard keep a copy? Could another customer end up looking at my code? Does the AI get to reuse it? Can a scan change something in my repository?
Short answers: no, no, no, and no. But short answers are easy to give and hard to trust, so here is the longer one. When you connect GitHub or GitLab, you pick which repositories lumioguard may touch, and nothing is copied or scanned until you start a scan. The interesting part is what happens after you press that button.
The secure sandbox
Every scan begins with lumioguard building a private sandbox. The easiest way to picture it is a room prepared for a single visit. Your code is brought in, the scan runs, the findings leave, and the room is torn down. Under the hood, the sandbox is built on containers.
The demolition is not conditional on things going well, either. Finish, fail, or cancel, the cleanup is the same: the code copy and the sandbox are deleted.
Keeping the keys away from the AI
Inside the room, there is a wall. On one side sits the AI scanner, which reads your code. On the other sits an access broker, which holds the connection to GitHub or GitLab. The broker is a deterministic process that runs as a sidecar: its job is to use your token to fetch the code from your repository and place it in the sandbox. This way the AI has no way to push changes upstream, even if it decides to go rogue and try to fix things on its own.
Token security
Tokens deserve their own scrutiny, because a token can outlive any single scan if you let it. So why not treat GitHub and GitLab identically? Because the providers themselves don't work identically. GitHub avoids the problem outright: lumioguard never stores a long-lived GitHub token, and each scan gets a short-lived one that expires on its own. GitLab's OAuth token stays available while your connection is active, stored under AES-256-GCM encryption with a key unique to your workspace, and it is revoked the moment you disconnect.
When a scan starts, we generate a fresh encryption key for that scan alone. The token travels over an encrypted connection, sealed so that only the broker inside that specific sandbox can open it. The readable token lives only in the broker's memory while the scan runs.
What leaves the sandbox
Only the findings walk out. We keep what you need to see and act on an issue: what it is and how serious it is, the affected file and line numbers, the few lines of code that show the problem, and the fix we recommend. Before any of that is stored, recognizable secrets are stripped from the evidence.
What we do not keep is everything else. Your repository, its file tree, its Git history, and every file that had nothing to do with a finding all disappear with the sandbox.
You decide when and what gets updated
A scan cannot change your code, and it cannot make a production change. When lumioguard prepares a fix, it arrives as a pull or merge request, which means it sits there until someone on your team reviews it and decides. Your main branch changes only when you approve and merge.
Your code is used to run your scan and for nothing else. If you ever want out, disconnecting GitHub or GitLab removes lumioguard's access on the spot. If you need to get into the details, reach out to us at hello@lumioguard.dev.