Prem Cyberscan: How Enterprises Use AI Security Agents to Find Critical Code Vulnerabilities

A security audit tells you what your code looked like at the time it was reviewed. Once development continues, the code changes with it. A dependency update or even a relatively small change to an existing feature can introduce a vulnerability that was not there during the audit.

The problem is that scheduled reviews may not catch these issues until the next assessment. For teams that release changes regularly, this can leave a meaningful gap between when a vulnerability enters the codebase and when it is actually identified.

The Coldcard incident on July 30, 2026, is a good example of how quickly a security issue can become significant and draw attention across the crypto security community. According to TRM Labs, an attacker took more than $116 million in bitcoin from over 5,200 wallets, in four waves across a single week.

That kind of speed doesn't leave room for a scheduled review to catch up. If your only line of defense is a periodic audit, you're defending against yesterday's threat model.

This is why more enterprises are adding a continuous, AI-assisted review layer that sits alongside formal audits and human review, not instead of them. To help enterprises get there, Prem is launching Prem Cyberscan. In this article, you'll get to know everything about it, how it works, and how you can put it to use in your own security program.

What is Cyberscan and who is it built for?

Cyberscan is an AI security agent built for continuous code review. Instead of scanning your repository once and calling it done, it treats security as an ongoing process, one that keeps pace with your codebase as it actually changes.

You connect it to a repository like Github, and from there it works the way a dedicated reviewer would if that reviewer never slept and never lost context between sessions. It looks at your code in the context of the whole system, not as isolated files, and it keeps running as new commits come in.

It's a direct answer to a problem every engineering team recognizes: audits happen a few times a year, and your code doesn't wait for the calendar.

Who is Cyberscan built for?

Cyberscan is relevant to a fairly wide set of people, because "who reviews code for security" touches more roles than it used to:

• Engineering and development teams who want issues caught close to where they're introduced, not months later
• AppSec and security teams looking for a way to extend coverage without extending headcount
• Infrastructure and platform teams responsible for systems where a single missed flaw has outsized consequences
• Teams managing large or fast-changing repositories, where manual review simply can't keep pace
• Organisations running security-sensitive systems, where the cost of a miss is measured in more than developer time
• Enterprises that already run formal audits but want a way to watch the code that changes between them

Where does Cyberscan fit alongside existing security processes?

CyberScan adds a layer, it doesn't replace the layers you already have. It doesn't compete with your audit firm or your internal security team. It covers the day-to-day changes that happen between scheduled reviews, the space those processes can't watch continuously.

A formal audit is thorough but occasional. Continuous AI-assisted review is lighter per pass but constant. You want both, at different points in your development cycle.

Why your code needs security review between formal audits

Most security programs face a practical challenge: security reviews happen at specific intervals, while development continues in between. As the codebase changes, new issues can appear after one review and remain unnoticed until the next, creating a security gap that teams need to account for as part of their development process.

The security gap between two audits

An audit tells you about your codebase as it existed on a specific day. The moment that report is finalized, your code keeps changing underneath it.

New commits, refactors, dependencies, config changes, and new features can all introduce new vulnerabilities. Even a small change can bring back a security issue that was fixed in an earlier review.

That is why a codebase that passed a security audit once is not automatically secure forever. Software keeps changing, and its security needs to be reviewed as it changes.

What the Coldcard incident tells us about continuous code security

The clearest recent illustration of this gap is the Coldcard incident referenced in Cyberscan's own launch materials. A firmware regression introduced in March 2021 left a build-time check unable to do its job: the check was meant to guarantee the wallet used its hardware random number generator, and instead it silently allowed a fallback to a deterministic software PRNG during seed creation. Every wallet seed produced that way became predictable.

For roughly five years that flaw remained in the codebase, on an open-source repository, through prior reviews. Then, at the end of July this year, attackers began draining funds from thousands of affected wallets in fast, coordinated waves. The attacker rebuilt private keys offline, without ever touching a device.

The broader takeaway is that security review cannot always be treated as a one-time exercise. A review reflects the codebase at a specific point in time, while the code itself continues to change. New commits, dependencies, configurations, and features can introduce new risks between formal reviews, which is why ongoing security checks can add another layer of coverage.

Why human review alone can leave gaps

The challenge is maintaining consistent security coverage as a codebase continues to change. A small security team, however skilled, can only hold so much of an evolving codebase in their heads at once, and they have other work competing for their attention.

In a conversation on The Starting Block, Casa's Jameson Lopp and Foundation's Zach Herbert discussed exactly this tension after the Coldcard fallout: manually verifying every layer of complex hardware and software isn't realistic for most teams, and that's before you account for how much code changes week to week.

Automated vulnerability detection isn't there to replace that judgment. It's there to be another set of eyes that doesn't get tired, doesn't lose context, and doesn't need to context-switch back into your codebase every time something changes.

From periodic audits to continuous security review

The process looks a little different with Cyberscan. In the traditional model, you have a formal audit, the code changes over time, and then there is a gap before the next audit. During that gap, new security issues can go unnoticed.

Cyberscan adds continuous review to that process. As the code changes, it keeps reviewing the code and surfaces potential issues. Your team can then validate the findings and fix what needs attention. The gap between formal audits still exists, but it is no longer left completely unmonitored.

Prem Cyberscan: how it finds vulnerabilities in your codebase

Formal audits check your code at one point in time, but new commits, dependencies, and configuration changes keep arriving long after that report is signed off.

Prem Cyberscan is built to keep reviewing your code through all of that ongoing change, instead of waiting for the next scheduled audit to catch what slipped through. It doesn't ask you to change how you ship code. Here's what actually happens once you connect it.

Connects with your repository

You start by connecting your GitHub repository to Prem Cyberscan. The GitHub App issues a short-lived token for the repository you select. It works against your actual codebase as a whole, not against snippets you manually pull out and submit. That matters, because vulnerabilities often live in how pieces of code interact, not in any single function on its own.

Examines potential vulnerabilities and attack paths

Once connected, Prem Cyberscan examines your repository for potential vulnerabilities and attack paths, looking at code in the context of the broader system rather than reviewing each file in isolation. This is closer to how an experienced reviewer thinks: not "is this line safe" but "what can reach this line, and what happens if it's compromised."

Keeps running as your code changes

Prem Cyberscan doesn't run once and stop. You review the code again as the repository changes, and each review starts from a clean checkout of the exact commit you choose. Reviews are also checkpointed as they run, so a review interrupted partway through continues from the last usable point rather than starting over.

For a codebase that's actively being developed, that persistence is the difference between a one-time snapshot and something that actually tracks drift over time.

Prioritizes potential vulnerabilities

Findings include severity ratings and file-level references, so your team can quickly see where the issue is and how urgent it may be. This helps them decide what needs attention first.

Instead of giving your team a long list of possible issues with no clear priority, Prem Cyberscan highlights the findings that matter most. This makes it easier to focus on important security risks rather than spending time sorting through less relevant findings.

Fits into your development workflow

Findings from Prem Cyberscan are formatted for GitHub code-scanning alerts and issues, so they land in the environment where you already manage code rather than a separate dashboard you have to remember to check. It's also available through an API and via MCP, so it can plug directly into development tooling you've already built around, instead of asking your team to adopt something new just to see the results.

What Prem Cyberscan checks for

Prem Cyberscan reviews every supported file in the repository and reports what it finds with evidence attached. If your codebase touches money, permissions, or anything cryptographic, this is the exact surface area you'd want a second reviewer watching.

What comes back isn't a vague warning either. Every finding arrives as something closer to a review receipt: the file, the line, the evidence, and a way for your team to verify it themselves rather than take the finding on faith. Each review produces a versioned report, and token usage is visible as it runs.

Reviews are checkpointed as they run, so if a scan stops partway through, it resumes from where it left off instead of starting over and re-billing you for work it already did.

You can pull results straight into your own tooling through the API and MCP.

Which region Prem Cyberscan runs in

Your run stays inside the EU. The worker that scans your code and the model it talks to are both routed through Prem's EU North infrastructure, so you know which region your code is processed in before you start a review.

How Prem Cyberscan isolates each run

Every scan gets its own worker, spun up for that run alone. Each review starts from a clean checkout of the exact commit, and reviews never share a working copy, so you're not sharing infrastructure with anyone else's codebase and nothing from one run carries over into the next.

What happens to your code after a scan

The temporary checkout is not part of your workspace record. CyberScan keeps run status, usage, findings, decisions and reports. Automatic expiry, self-service deletion and independent proof of worker cleanup are not available yet.

Prem Cyberscan pricing

You're billed per token, so the cost tracks the actual work Prem Cyberscan does on your repository. There's no flat fee that leaves you guessing what you got for it, and no surprise charge for a scan that never really ran.

Why the model behind an AI security agent matters

Not every AI model reasons about code the same way. Vulnerability detection depends on how well a model can trace relationships across files, follow an attack path from entry point to impact, and hold a large codebase in context without losing the thread.

Two models can read the exact same repository and walk away with very different findings, and that difference is exactly why model choice deserves attention rather than a footnote.

Prem Cyberscan's model choice

Prem Cyberscan is built around open-weight models, and you can choose which model runs a given scan rather than being locked into one option by default.

The model options are Kimi K3, our purpose-built build of DeepSeek V4 Flash 0731, and Qwen, with requests handled through Prem Router in EU North, the infrastructure layer that routes your scan to whichever model you've selected. That choice matters for a few practical reasons:

• Reasoning quality, since some models trace multi-step logic and attack paths more reliably than others
• Code understanding, particularly across languages and frameworks that aren't equally represented in every model's training
• Context capacity, which determines how much of a large repository a model can actually hold in view at once
• Scan speed, which affects how quickly a review can run against a fast-moving repository
• Cost, since routine scans and high-stakes reviews don't need to run on the same budget
• Independent validation, since running a different model against the same code gives you a genuine second opinion rather than the same blind spot twice

Why you may want to run more than one model

A finding from a single model shouldn't be treated as unquestionable truth, no matter how confident the output sounds. This is where running a second model for assurance earns its place, especially on higher-risk code. In practice, that can look like:

1. Run an initial security analysis across the repository
2. Investigate the highest-priority findings that come back
3. Run a second, capable model specifically against those critical areas or findings
4. Have your security engineers validate the result before anything gets treated as confirmed

This is a more honest way to think about AI code auditing than claiming any single AI security audit can definitively certify code as secure. An AI-powered security audit is strongest when it's treated as a fast, thorough first pass, not a final verdict, and when the AI security review that follows brings a second model and a human into the loop on anything that actually matters.

What Cyberscan does not replace and where its limits matter

Cyberscan is designed to strengthen your existing security processes, not replace them. Prem Cyberscan is one part of a security program, not the whole of it, and knowing where it stops is just as important as knowing what it catches.

Cyberscan does not replace your security experts

Formal audits still matter. Expert security review still matters. Penetration testing and specialised testing still have a role no automated pass can fill on its own. Your developers and security team are the ones who ultimately validate findings and decide what gets remediated and how.

AI security findings still require validation

No detection layer is perfect, automated or human. Cyberscan's findings can include false positives, and, just as importantly, they can miss things too, false negatives, especially where a flaw depends on business logic or application context the model wasn't given. This is a known pattern across AI-assisted security tooling generally.

A recent post on Simon Willison's newsletter about AI-generated security reports flooding open source maintainers made the point well: volume of findings isn't the same as value, and a small amount of human verification on top of automated output changes the outcome dramatically. Running a second model for assurance on critical findings, and treating Cyberscan as a complement to expert review rather than a stand-in for it, is the right posture here.

Data handling and retention need scrutiny

Before you connect a repository to any AI security tool, there are a few direct questions you should get answered first. Where does your source code get processed? What gets retained, and for how long. Who can access it? Does any of it reach external model providers, and could it end up used to train a model you have no relationship with. Where does the analysis actually run?

Open-weight models like DeepSeek and Qwen change this calculus in a useful way. When you can choose the model doing the analysis, you're not locked into routing every scan through one vendor's closed system.

That flexibility starts to matter more once review becomes continuous instead of occasional, because the volume of code passing through that pipeline only grows from here. If your team handles regulated or highly sensitive code, this is a question to settle with any vendor before you connect a production repository, not after.

Where continuous AI code security fits into your enterprise security workflow

Getting the balance right means being clear about where continuous review fits within your existing security processes. It works alongside code reviews, human validation, formal audits, and specialized testing, adding another layer of security as your codebase changes.

Cyberscan as one layer of your security lifecycle

Picture the full loop: a code change happens, it goes through peer or code review, then Cyberscan's AI security review runs against it, a potential vulnerability gets flagged, your developer or AppSec team validates it, remediation happens, and formal audits and specialised testing continue on their normal schedule alongside all of this. Nothing here replaces a step you already trust. It just adds a layer that's watching in between.

When continuous AI code security can be particularly useful

This kind of continuous layer earns its place fastest in a few specific situations: large codebases where manual review can't scale, repositories that change frequently, applications where the underlying data or funds are especially sensitive, high-value infrastructure, teams shipping on fast release cycles, and AppSec teams that are stretched thin relative to the size of what they're covering.

It's also useful in both directions around a formal audit, tightening things up before one, and keeping watch in the months after one closes.

The real question about your codebase isn't only "when was this last audited." It's "what's reviewed the code that's changed since."

Start securing your codebase with Prem Cyberscan

The gap between audits is where a lot of risk builds up, and it's exactly the space Prem Cyberscan was built to cover.

It runs against your repository as the code changes, surfaces vulnerabilities with clear severity and file-level detail, and slots into the workflow your team already uses.

Prem Cyberscan is in beta now, with $25 in free credits for new users to get started.

Sign in with your GitHub account, connect a repository, and let Prem Cyberscan run. If you want to see how it performs on your own codebase, you can use the available credits to scan a real repository and review the findings for yourself.