Why is a project like SecureCoder needed?
More than 90 percent of software developers now use AI-powered coding assistants, and the trend is accelerating. At the same time, systematic studies consistently show that a significant portion of AI-generated code contains security vulnerabilities — buffer overflows, insecure API calls, missing input validation. This is not because AI is careless. It is because these models were trained to optimize for correctness and productivity, not security.

The standard response has been to add post-hoc checking tools: static analyzers, vulnerability scanners. But this is the wrong paradigm — it treats symptoms, not causes. SecureCoder asks a different question: what does an AI system need to look like so that secure code is the natural output, not the result of after-the-fact correction? Our guiding analogy is strongly typed programming languages: not catching errors in testing, but making entire classes of errors structurally impossible to write. That is security by construction.

The urgency is only growing as software development becomes increasingly agentic — AI systems that autonomously plan, write, test, and deploy code, often with minimal human oversight. In such pipelines, a single security flaw introduced by one agent can propagate silently across an entire system before any human has reviewed a single line. SecureCoder is explicitly designed to address this emerging challenge: not just securing individual code suggestions, but securing entire AI-powered development workflows.

How does your technique differ from existing AI models?
Our technical choices are direct responses to the limitations of existing architectures for secure code generation. Most large language models use Transformer architectures with autoregressive generation: code is produced token by token, left to right, with no ability to revise earlier decisions once committed. This is a fundamental mismatch with what secure code reasoning actually requires — security properties often depend on interactions between distant parts of a program, demanding holistic reasoning, not incremental commitment.

We explore two architectural alternatives. First, State Space Models (SSMs): models with linear rather than quadratic computational complexity, capable of reasoning over entire codebases — hundreds of thousands of lines — without prohibitive cost. SSMs maintain an explicit, updatable internal state that maps naturally onto the structured, dependency-aware reasoning security analysis requires. Second, Diffusion Language Models, which generate code not in a single left-to-right pass but through iterative refinement — from a noisy initial draft toward clean, secure output. At each refinement step, a constraint mechanism can make known vulnerability patterns structurally impossible to produce.

Training is anchored by off-policy reinforcement learning with verifiable rewards: symbolic tools — type checkers, static analyzers, formal verifiers — run in parallel as evaluators, providing concrete, verifiable training signal without the bottleneck of human annotation. The combination of an SSM backbone, diffusion language model, and constrained decoding, and off-policy reinforcement learning with verifiable rewards as an integrated system is, to our knowledge, unprecedented for this purpose.

Your project draws on expertise from different fields. How does it fit together?
What makes SecureCoder genuinely interdisciplinary is the recognition that security in AI-generated code is an inherently multi-layered problem — and that the layers interact. Compromised training data undermines even the best model architecture. A sound model trained on clean data can still generate insecure code if the generation process has no security awareness. And a well-designed generation mechanism can be circumvented by adversarial inputs without runtime enforcement. Treating one layer while ignoring the others creates a false sense of security.

We bring together expertise in programming languages and formal verification, machine learning and NLP, and cybersecurity. The four main components — curated training data, security-first model training, constrained decoding, and security RL-based critic models — are not a pipeline but a feedback loop: critics identify failures that improve training data; constraint engines derive their rules from the same security knowledge base that shapes prompting; benchmark results drive iterative model refinement.

We are also explicitly extending this architecture to agentic development environments. In a multi-agent pipeline — with orchestration, generation, retrieval, verification, and memory agents — security must be engineered into the interactions between agents, not just into individual generation steps. This means security critics that monitor across agent boundaries, constraint mechanisms governing tool access and execution scope, and audit trails that make the full pipeline's behavior interpretable and accountable.

How exactly is the generated code made more secure?
Security intervenes in SecureCoder at multiple points – and these points are interconnected.

Before training, the training data is cleaned of historical vulnerabilities and enriched with security knowledge from sources such as the MITRE CWE catalogue, OWASP guidelines, and the CVE database.

After pre-training on this curated data, the model is fine-tuned to security standards using Off-Policy Reinforcement Learning with verifiable signals from symbolic software quality assurance methods – such as type checkers, static analysis tools, and formal verifiers.

Developer prompts are automatically enriched with security-relevant context – even when the developer does not explicitly ask for it.

During generation, Constraint Decoding enforces security properties. This is not a soft nudge: certain patterns – known-unsafe API calls, forbidden memory operations, missing validation steps – can be made structurally impossible, much like a type system prevents type errors from arising in the first place. Hard constraints enforce absolute prohibitions; soft constraints steer the model towards safer idioms without sacrificing flexibility.

After generation, dedicated Security Critic models review the output – not in isolation, but in the context of the entire codebase. A vulnerability that is invisible in an isolated function can become apparent once its interaction with the rest of the system is examined.

In agentic development workflows, this multi-stage security architecture also operates across agent boundaries: a Critic can inspect the code produced by a generation agent before a deployment agent executes it.

Is your approach unique worldwide?
In several respects, yes. State Space Models have been explored for natural language, but their systematic application to secure code generation is largely uncharted territory — our work on the CodeSSM model, on which SecureCoder builds, was among the first to establish a foundation here. The combination of SSMs, diffusion language models, Off-Policy RL with verified rewards and constrained decoding as an integrated security system is, to our knowledge, new.

But what we consider conceptually most significant is the overarching framing: treating security not as a post-hoc quality criterion but as a structural property that must be built into every phase of AI-powered development — from data curation through training and generation through runtime guardrails. This places SecureCoder closer to the tradition of programming language research, where safety properties are enforced by construction, than to the tradition of software testing, where they are checked after the fact.

Where we are furthest ahead is in territory that is barely charted at all: the security of agentic software development pipelines. No existing framework systematically addresses the security implications of multi-agent code generation — vulnerability propagation across agent boundaries, the security of inter-agent communication, or the governance of autonomous tool use. We are building the conceptual and technical foundations for this, and we believe it is one of the most important open problems at the intersection of AI and cybersecurity.

What I want to highlight at this point is that the SSM backbone of our system requires significantly less compute power and storage, and can learn from less data, than comparable transformer backbones. Our hope is to thereby deliver a system that can be trained and hosted in-house on a company’s own data.

What is next for SecureCoder?
Immediately ahead: scaling and validation. By the end of this year, our model grows from one billion to seven billion parameters, followed by a 32-billion parameter version — trained on hessian.AI's infrastructure and hosted in Germany, ensuring European data sovereignty. Our open benchmark suite — covering multiple programming languages and drawing from CWE, CVE, and community-mined vulnerability examples — will be released as a shared evaluation resource for the research community.

But the more significant next frontier is extending SecureCoder's paradigm to agentic software development. AI agents are already writing, testing, and deploying code autonomously — often in multi-agent pipelines with minimal human oversight. This creates fundamentally new security challenges: an orchestrating agent can be manipulated through prompt injection to generate malicious code; vulnerabilities introduced by one agent can propagate silently through the pipeline; tool access granted to a generation agent can create privilege escalation risks. These are not hypothetical — they are already occurring in deployed systems.

We are extending SecureCoder's core components — security critics, constraint engines, formal verification anchors — to operate within multi-agent architectures, not just at the individual model level. The goal is a verifiable security perimeter around the entire AI-powered development workflow, from prompt to deployment. This connects directly to the broader agenda for trustworthy AI: the more autonomy AI systems are granted in high-stakes domains, the more important it is to build security and accountability in from the start.

For more information about SecureCoder, see at  ATHENE  Missions Projects and at https://securecoder-project.github.io/.

show all news