The common instinct is to give agents more context: threat-modeling skills, security checklists, policy files committed to the repo so the guidance is always in reach. It backfires. Faced with too much context, the agent compresses it until the actionable knowledge is summarized away, leaving the agent unable to secure the task at hand. The result is that your organization invested effort, learnings, and countless tokens, and the agent still misses critical threats or flags ones that don’t apply

What decides whether the code is secure isn’t how much guidance the agent can see. It’s whether that guidance is scoped to the task in front of it and grounded in how your system is actually built.

Today we’re releasing Kura, Adaptive Security Context for coding agents.

Kura succeeds at solving this because of the engine that sits behind it. Clover already maintains a living threat model of your application, one that keeps pace as your architecture and code change.

Kura draws on that model in real time: for every task an agent takes on, it pulls only the threats and countermeasures relevant to that task and applies them as the plan and the code take shape.

Check out the full press release here.

What Kura does

For every task an agent picks up, Kura hands it the security requirements and threats counter measures for that feature, and nothing else.

• Scoped to the task – Kura selects only the security requirements and threats countermeasures that apply to the feature being built, rather than loading everything in the repo.
• Applied as the code is written –  Kura supplies the context while the agent plans and writes, so the requirements are in place before the code exists, not raised in a later review.
• Removes redundant requirements – When a control is already enforced elsewhere in the stack, Kura leaves it out. That keeps the generated code smaller and uses fewer tokens.
• Traceable to the continuous threat model – Each requirement links to a named entry in your threat model rather than a generic rule, so a reviewer can see where it came from.

Real-life example: the @mention directory leak

To see what task-scoped context actually catches, we tried it on Plane, the open source project management tool. We added a realistic feature, an External Collaborator Portal that lets outside users comment on and edit specific threads, and we planted one flaw inside it.

Collaborators can @mention internal team members, and the picker reuses Plane’s normal member autocomplete. The catch is that the autocomplete is scoped to the entire workspace. So an outside collaborator can type a single letter and page through the whole internal directory, names and emails and all. It’s broken access control, straight out of the OWASP Top 10, and it’s hiding inside a requirement that reads like a perfectly normal product decision.

We handed the same task to three setups: 

• an agent with generic security context, 
• the same agent using a model provider’s own security skill
• agent running on Kura. 

The agent’s original plan

The same plan after Kura

Kura turned that into six requirements the agent had to satisfy:

1. Scope restriction
2. Minimum query length
3. Rate limiting
4. Minimal data exposure
5. Audit logging
6. Admin kill switch

The list itself is ordinary OWASP hygiene. The point is that no one wrote it for this feature. Kura derived it from your threat model, recognized that a workspace-scoped picker on an external portal was broken access control, and attached exactly these controls to exactly this task.

What Kura changes in production

For the past several months, Kura has been running in production across our enterprise customers’ Agentic SDLCs, as well as our own. For the first time, those teams can see how their agents build: what each change decided, where it introduced risk, and how Kura addressed it, all in one place and in real time, and the security bar holds no matter which agent writes the code, whether it is Claude, Codex, or whatever comes next. Seeing customers rely on Kura in production was the strongest validation, but we wanted to test it on a less forgiving audience too: our own engineers. So we turned it on quietly across our Agentic SDLC and did not tell them, because we wanted a clean answer to one question: would anyone notice? If Kura slowed a session down or buried engineers in requirements that did not matter, we would hear about it immediately.

Three months in, we haven’t. The overhead comes to about 22 seconds a session, and Kura quietly took work off the pile: it caught controls our Claude and Codex instances proposed that were already handled elsewhere, like rate limiting the API gateway already enforced, and dropped them before anyone wrote a line. The bigger change was the rework. A feature that looks done but hides a security problem has to be rebuilt from scratch, and Kura catches the flaw before the code exists, so that rework never starts. Over the same period, feature rewrites caused by security issues fell 83%.

Ready to see Kura in action?

The post Introducing Kura: Adaptive Security Context built for secure agentic coding appeared first on Clover Security.

Security teams are increasingly providing coding agents with more security context: repository-wide threat models, security skills, MD files, and policies with the expectation that more security knowledge will produce safer code.

We tested that assumption across three production codebases and three frontier models.

With no security context, agents prevented approximately 17% of the planted flaws. Broad context improved that to 33%, but left most flaws unresolved. Feature-tailored context – pairing the risks specific to a feature with concrete countermeasures – reached 84%.

What changed the result was not the amount of context, but how precisely it was tailored to the feature.

Broad security context also introduced a more concerning failure mode: it gave agents the language and confidence to make insecure code seem secure. Plans cited security risks and tests passed – while the underlying business-logic flaws still shipped. In other words, the context did not necessarily make the code safer; sometimes, it only made the agent sound more secure.

Does more security context produce more secure code?

The common assumption is straightforward: coding agents generate insecure code because they lack sufficient security knowledge. Give them threat models, OWASP guidance, secure-coding skills, and organizational policies, and their output should become more secure. In other words, the more security context a coding agent receives, the more secure its output should be.

We set out to test that assumption in realistic conditions.

Most evaluations of secure code generation rely on toy applications. Those tests can show whether a model recognizes a familiar vulnerability pattern, but they reveal much less about an agent’s ability to do so inside an existing system with real architecture, product requirements, and controls. Business-logic flaws present a particularly difficult test. The code may be technically valid and follow the specification exactly, while the specification itself embeds an unsafe product decision.

Could general security guidance help agents catch those flaws, or does the context have to be tailored to the feature being built? We tested that inside three production codebases, Plane, Kubernetes, and Grafana, where each agent built a real feature from a specification carrying three planted business-logic flaws native to that system. Feature, prompt, and starting commit stayed constant across every run, so the only thing that changed was the security context the agent received. A condition-blind judge scored each result and a separate validator checked every claim against the code, so a flaw counted as resolved only when the implementation resolved it, not when the plan or the tests said it had.

The full methodology and per-codebase results are available in the full research report.

Three types of security context

We tested three types of artifacts.

No context

The agent received only the feature specification and the codebase. This established the baseline.

Broad context

The agent received off-the-shelf security guidance that was not written for the feature it was implementing.

• OpenAI’s threat-modeling skill 
• Anthropic’s threat-modeling skill 
• OWASP PyTM 
• OWASP security checklists 

This represents the approach many teams are adopting today: attach a repository-level threat model or security skill and make it available to the coding agent.

Feature-tailored context

The agent received context scoped to the exact feature being built: the relevant threats, attack paths, security requirements, and the outcome-phrased countermeasures needed to resolve them.

None of the security artifacts had access to the planted flaws. They had to identify and address the problem by reasoning about the feature.

The results: tailored context, not more context, produces more secure code

The direction was consistent across all three codebases and models: context tailored to the feature substantially outperformed general security material.

• With no context, agents resolved approximately 17% of the planted flaws. They occasionally caught problems that mapped cleanly to familiar security primitives, but most flaws embedded in the feature’s business logic remained.
• Broad context improved the average to 33%. That was progress, but most of the flaws still shipped.
• Feature-tailored context changed the outcome, reaching an average mitigation rate of 84% and as high as 94%.

The decisive variable was not context volume. It was whether the context identified the exact threat and connected it to a concrete countermeasure that had to appear in the finished code.

Prevention rate by security context source, across all three codebases.

Example: How broad context can make insecure code look reviewed

The modest improvement from 17% to 33% was not the most surprising result. What stood out was the character of the output produced under broad context. The agent adopted security terminology, cited threats in its plan, and created passing tests without necessarily fixing the underlying flaw.

One planted requirement asked the agent to log only 10% of collaborator read events to control log volume. Writes would always be logged, but nine out of ten reads would leave no audit trail.

Under broad context, the agent treated this as an accepted product requirement. Its plan discussed audit logging and referenced SOC 2. The code wrapped read paths in an audit function. A passing test confirmed that sampled reads could produce no audit entry.

Every layer looked security-aware:

• The plan discussed compliance: 

• The implementation contained audit calls: 

• The test suite was green: 

But 90% of read activity was still invisible.

A run that ignored security completely might look unfinished. This implementation looked reviewed. A human reviewer could skim the plan, code, and tests and conclude that the requirement had received security attention. That is more than a missed vulnerability. It is false assurance: security-shaped work that weakens the human review process designed to catch the agent’s mistakes.

Why broad context gets lost

We found two failure modes, and they compound.

1. Compaction strips away critical detail

Coding agents compress large amounts of context into shorter working summaries. That helps them operate within a complex task. What survives the compression is security vocabulary, not security measures. The specific instruction needed to change the implementation is more likely to disappear.

A broad checklist may correctly state that PII should be scoped and minimized. But that is not the same as telling the agent:

• Limit autocomplete results to participants in the current thread.
• Return display names only.
• Never return email addresses. 
• Rate-limit the query. 
• Log anomalous enumeration behavior. 

Broad context names the category. The feature-tailored context defines the control.

2. Humans confuse information with instruction

We often give an agent information about a risk and assume it will infer the required secure behavior. Which is an unrealistic expectation of the agent. There is a meaningful difference between handing the agent a repository threat model and explicitly stating: This access link cannot remain reusable for the full grant period. Require a one-time verification code on first use, expire unclaimed invitations after 72 hours, and re-check the active grant on every request.

One is a reference. The other is a decision the implementation must enforce.

The path from feature-tailored context to secure code

The research points to two practical conclusions.

1. Give the agent feature-tailored context

Repository-level security guidance remains useful background, but it should not be treated as sufficient for securing an individual feature.

The context that changed outcomes identified:

• The threat specific to the feature. 
• The attack path created by the requirement. 
• The countermeasure that resolves it. 
• The authority to override a conflicting product requirement. 

2. Write required outcomes, not security vocabulary

Security context should read like build instructions, not a reading list.

• “Protect sensitive data” is a principle.
• “Return only participant display names and never return email addresses” is an outcome the code must exhibit.

Similarly, naming a cryptographic mechanism is not enough. An agent can mention the mechanism without producing the intended security property. The context should define what must be true when implementation is complete.

The enterprise challenge: generating the right context continuously

Creating feature-tailored context for a controlled experiment is one thing. Producing it continuously across a large enterprise application is much harder.

The relevant context rarely lives in a single feature specification. It may be spread across:

• Product documents. 
• Architecture diagrams.
• Tickets and design decisions. 
• Application and infrastructure repositories. 
• Organizational policies. 
• Existing security controls. 
• Interactions between multiple services. 

This context feature-tailored context needs lives in your threat model, and as soon as your features, architecture, infrastructure, or control environment change, threat models go stale. Therefore, the real problem is therefore not simply writing better security instructions. It is continuously discovering the context of the feature, deriving the relevant threats and required countermeasures, and delivering them to the coding agent at the moment it plans, implements, and verifies the change.

Conclusion

More security context did not reliably produce more secure code. Broad threat models, security skills, and checklists moved the mitigation rate from approximately 17% to 33%, but left most business-logic flaws unresolved. They also created a dangerous side effect: implementations that appeared security-aware and reviewed while still shipping the flaw.

Feature-tailored context reached 84% because it did something fundamentally different. It connected the exact risk in the feature to the exact outcome the implementation had to produce. The lesson is not to stop giving coding agents security context. It is to stop assuming that more context is enough.

Safer code comes from carrying the right security requirement all the way from the feature, to the agent’s plan, to the finished implementation.

The post Looks secure, ships insecure: Why broad security context backfires across frontier coding agents appeared first on Clover Security.

The idea started as arithmetic. One security engineer for every hundred developers, often worse. At that ratio nobody reviews every design decision, every code change, every deployment. Something has to give, and for years the answer was the security champion: an engineer on each team who carries security into the rooms security can’t be in.

The vision was generous. A security champion who understands their application’s architecture, spots risk while a feature is still being drawn, escalates what matters, and lifts the whole team’s baseline. Not a ticket-closer. An owner. And the highest-leverage item on that list was always the earliest one, catching risk at design time, before a line of code exists. It is also the hardest to scale and the easiest to skip. That is the tell. The security champion program was never about managing tickets. It was about security ownership, developers owning the outcome end to end.

Why most of them quietly die

Most security champion programs fail. Not loudly, and not because developers refuse to help. They fail because nobody funded the ownership, and an unfunded program dies on a schedule.

The pattern repeats. No budgeted time, so participation is unpaid work bolted onto a sprint, running on personal motivation until the motivation runs out. No clear owner, so nobody tracks it, and it goes quiet a few months in. No credit, so momentum stalls. No guidance, so the champion cannot separate the change that matters from the dependency bump that doesn’t, and everything looks urgent until nothing does.

Underneath all four is a misread of what the tooling ever did. Scanners are work-generation machines. You buy one to discover a thousand problems, and the discovery was always the easy part; the fixing was always going to be yours. So teams wire up the scanners, watch the flood arrive, and stand up a security champions program to bail it out. The program becomes a drain for issues that were surfaced with no plan to resolve them.

The fix is unglamorous to the point of boring. Stop routing security work around the way developers already earn credit. No leaderboard, no swag, no pizza party. Put the finding in as a ticket with story points, prioritized and assigned like every other piece of work, so it lands inside the incentives the developer is already measured on. It is not clever. It works.

Blocking, the reflex the industry reaches for first, tends to do the opposite of what it promises. Block a build over a stale framework, and the developer who only wanted to recolor a button can no longer ship, the service stops pulling its own updates, and your posture quietly gets worse. You have stopped the work and degraded the security, both in security’s name.

What is left when the funding never comes is easy to recognize. A Slack channel. A wiki nobody opens. A metric that counts meetings instead of risk.

What AI actually changes

Strip a security champions program to its core and it was always a knowledge problem. Get security understanding as close to each developer as possible, then hope it survives the handoffs, from the security team to the champion to the team. Every handoff leaks. That is the layer AI actually changes.

The linchpin is threat modeling, and not the diagram. The diagram solves nothing on its own. What matters is the data underneath it, because once that data is available to an agent, you can finally deliver what shift-left promised and never did: the security context sits in the model’s context window, so every time an agent goes to work it already knows the application, the use cases, and how a fix should look. Findings get ranked by architecture instead of a raw severity score. False positives fall away because the model sees the whole system, not just the lines around the alert. Guidance arrives in the pull request as design direction, not a wall.

For years the only place to put security knowledge was a human head, which is exactly why it leaked at every handoff. The context window doesn’t. It carries the full picture into every agent on every change, and unlike a person it can be filled completely and refreshed the moment the system moves.

From there the work sorts into two jobs. Triage and planning is deciding what matters: signal pulled out of noise, risk reasoned about before a change ships, and only the real design questions routed to a human. Enforcement and execution is making it stick: decisions turned into enforced changes inside the workflow, so the guidance lives in the pull request and the Slack thread instead of the wiki nobody reads.

Where AI does not help

Every honest version of this story has a section like this one. AI does not replace security engineering. It changes the shape of the work, from clearing patches to deciding what the system should become. And it has real blind spots. It is weak at runtime defense, and weakest at the most human kind of flaw, the design mistake you only catch if you know why a feature exists and how it sits inside the larger product. Sometimes the model sees what a person would miss. Sometimes it is the other way around. That is the whole reason the discipline survives.

And no model fixes a program with no owner. Auto-remediation has existed for years as version-bump pull requests, and for most teams it becomes a backlog nobody merges, because someone still has to click merge and someone still has to care. Point AI at a broken program and you have not fixed anything. You have automated the slow burn.

What one team actually saw

One customer made the abstraction concrete. A US tech company, around 500 developers, a security team stretched closer to one-to-fifty than one-to-a-hundred, and roughly 25 security champions across the organization. The usual shape: a few deeply engaged, and a long tail who held the title and barely knew the security team, some who had never met them. Entire business units went dark. And the teams in the dark were often the ones shipping the riskiest things the company built.

Threat modeling was the use case, and before AI the hard part was the first step. The security team could coach the willing champions on STRIDE over time, but where nobody volunteered there was simply no coverage. AI changed where the work started. An initial framework did the heavy lifting and walked a champion through the first draft, so the job shifted from producing the model to reviewing it, sharpening it, and knowing when to raise a flag. Even for the disengaged, the system could surface a critical change early enough that a security engineer could reach out about something they would otherwise never have seen.

The part worth holding onto was the reaction from engineering. Builders describe security as friction almost by reflex. Here they described something they were glad to use. That is not what a feature earns. It is what happens when security ownership finally has ground to stand on.

What to do Monday

None of the moves here is bigger than it needs to be, and that is the point. Start with the honest question: what is your organization actually willing to fund. If the answer is catch the biggest risks first, weight threat modeling over vulnerability scanning, where the false-positive rate buries the signal anyway. Then start small. Do not build the perfect vulnerability dashboard before you have run one scoped process, because the only way to learn what each team needs is to run it. Hand the busywork to AI as you go, in the format each team already works in.

The spine holds the whole thing up. Fund the ownership first, then use AI to kill the busywork, never to run a broken program faster. Pick a real owner. Instrument one repo, not all of them. Let AI take the triage. The line that matters is not security versus developers. It is security, developers, and AI on the same side of the problem.

That is the problem Clover is built for: putting design-time security context in front of the people and the agents doing the work, so a security champion program finally has ownership to stand on and the busywork takes care of itself.

The post Why security champion programs stall, and what AI fixes appeared first on Clover Security.

AI coding agents like Anthropic’s Claude Code are becoming part of how every engineering team builds. Developers write with them, refactor with them, and ship real code with them every day, across real repositories, against real business logic.

For security teams, that raises a question they can’t yet answer: what are our coding agents actually building, and is it secure?

The honest answer, for most teams today, is that they don’t know. The moment work hands off to an agent, security teams go blind. They see the pull request at the end. They don’t see how it was built, what controls were applied along the way, or where risk crept in. The implementation phase, the exact moment security decisions get made, is where teams now have the least visibility.

Today, we’re closing that gap. Clover now integrates with the Claude Compliance API, bringing Claude Code activity directly into the Clover platform.

Discovering and mapping Claude across your environment

Connect Claude once. No proxies, nothing to install in the developer’s workflow. From that moment, Clover starts capturing Claude Code’s activity automatically, including the history already in your environment and every new session going forward.

The first thing you get is a map. Clover surfaces everyone building with Claude Code across your organization, not just the engineers already covered, but the ones flying blind. You see who’s shipping with it and what they’re actually producing, down to the developers working with zero security context.

From there, every artifact gets traced and tied back to the right application in Clover, then pulled into your secure-by-design lifecycle as a review candidate. AI-assisted work shows up as it happens, not weeks later when it hits the scanner, and it flows through the same governance, audit trail, and review process as everything else. Nothing slips out the side door.

Why it matters

Coding agents are optimized for code that works, not code that’s secure. They don’t carry your architecture, your frameworks, or your business context, so without help, fundamental risks pass straight through. By connecting to Claude’s Compliance API, Clover moves security to the point of implementation, applying your controls at the speed of your agentic workflows. Teams get one place to see every agent’s work and one security baseline across every agent their developers use.

Get started

Clover’s integration with Anthropic’s Claude Compliance API is available now. If your developers are building with Claude Code, see exactly what they’re shipping, and secure it as it’s written.

Book a demo to see Clover and Claude Code together.

The post See what your coding agents build: Clover integrates with Anthropic’s Claude Compliance API to give security real time visibility appeared first on Clover Security.

The Agentic SDLC introduces the opportunity to break the loop by bringing security guidelines directly into the agent’s context window – making security the first thought rather than the last. When the unit of work shifts from hand-written code to intent and design, security stops being the thing that arrives late and starts being the thing that arrives first. Timing and knowledge stop being separate problems, and finally get solved together.

Upcoming webinar: From bottlenecks to developer-led security

The three roots of developer security friction

For a developer, the friction is not one problem but three: volume, credit, and cost. First the volume, security teams hand over numerous findings, and many of them are time consuming false positives. Unfortunately, investigating security issues is one of the most challenging tasks in an organization. Second, getting credit for fixing security issues is too rare, as teams set off scanners but don’t get story points to compensate. Lastly, the cost: the findings that do matter are expensive to fix and don’t drive the increase in revenue new features do. 

False positives

There is no shortage of data, or opinion, on false positives. An academic study of five static analysis tools found 76% of their warnings irrelevant to the actual vulnerability; Ghost Security’s analysis of nearly 3,000 repositories put the false positive rate at 91%. The problem is that most scanners have an incentive to maximize the findings they show, as they don’t want to risk missing a potential issue during a test drive. The result is a number of findings too high to triage, where vulnerability counts only go up.

Reachability

Reachability is simply the goal of discovering the exploitability of a vulnerability. From runtime to function level, there are numerous ways of trying to filter out the noise from exploitable code in your environment. While numerous approaches exist, we’ve written about how the truth is much more complicated – there’s no single silver bullet for finding exploitability. The goal is clear: stop wasting developer time on findings that don’t matter; however, the reality is more complicated, as patching even a single vulnerability can have widespread impact depending on the overall design and architecture of your environment. The Agentic SDLC does help here, as “just patching everything” becomes slightly more achievable for organizations who have been unable to keep up with the often major code changes required for major version changes.

Remediation cost

No one talks about how not only are security findings high volume, but they often involve layers of major architectural context. When James started doing application security, almost every security finding ended up in the hands of the chief architect. Applying a late fix means unwinding work that has already shipped: re-touching major decisions made years ago, re-opening decisions the architecture has already locked in. The bill is never just the patch, it’s the sunk cost of having your best developers involved in what’s often a false positive. A scanner can flag a vulnerability (or ten) in a second, but those findings can take months to resolve.

How AppSec tried (and failed) to solve developer security friction

Shift-left was the most intuitive idea for security teams, and was a fair answer to the failure before it. The complaint was real: security showed up after the code shipped, when changing anything was expensive, so the fix was to move detection earlier, into CI, before the merge. But most teams moved the scan while ignoring their backlogs, and the way that they grow. They wired the same findings into the pipeline and turned the merge into a gate, so security still arrived as a final checkpoint, now with the power to block the build. This made the problem worse, as security blocked code changes irrelevant to the problems, over vulnerabilities outside of a developer’s control. To make things worse, delaying a push could even delay an image rebuild, leading to a net increase in vulnerabilities!
IDE plugins answered the next complaint, that feedback living in a separate tool was too far from developer’s work to act on. So the findings moved into the editor and the pull request, inline on the offending line. But proximity is not context, and doesn’t force work to get done. Every scanner brought its own plugin, its own severity model, its own bot on the same diff, and the developer’s workspace became a second inbox. Overload a developer with fifteen security tasks per line of code and you do not get vigilance, you get muted notifications.

Ironically, organizations that made meaningful dents in their backlog reverted to ticketing. Ticketing was the retreat when inline noise stopped working: route every finding to a backlog, assign an owner, track closure, report the numbers up the chain. This led back to the problems shift left tried to solve – creating developer/security friction, while increasing the backlog of work.

The Agentic SDLC: security’s compiler moment

Last-generation AppSec was built around one artifact: the code. Every attempt to solve developer security friction centered around that artifact, but code was the wrong vehicle for the fix. The Agentic SDLC changes the artifact, just as compilers once did. When high-level languages arrived, the work climbed off the machine and up to intent, and programmers got to think about what a program should do instead of how to spell it in machine instructions. The Agentic SDLC makes the same climb: the implementation falls to the agent, and the developer’s real work becomes ideation, architecture, intent. That moves the artifact from hand-written code to intent and design, so security stops being the thing that arrives last and becomes the thing that arrives first. It moves security training from a once a year activity into an ongoing process on every prompt.

Secure by design becomes operational

When intent and design are the artifact, the constraint comes first. You can state what a system is allowed to do, what data it can touch, what it must never expose, before any of it is built, and the agent generating the code is bound by that statement rather than trusted to remember it. The developer gets clear constraints instead of late rejections, and secure by design turns operational instead of aspirational: enforcement is a property of the design the code is generated from.

Fixing becomes economic

When an agent generates the fix and checks it before a human is involved, the cost of remediation collapses to almost nothing, and most importantly, story points don’t need to get assigned. GitHub measured its own Copilot Autofix cutting median remediation from about 90 minutes to under 30, and agentic fixing is only moving further in that direction. Once a fix costs less to apply than to debate, the debate becomes the expensive line item, and a team that used to weigh whether a finding was worth the work just applies the change instead. Remediation becomes the default rather than an argument about if it’s worth it.

Patching becomes background

Patching for minor versions already runs in the background at the dependency layer, where automated updates can pull in safe changes, limited only by the maturity of your test suite. The Agentic SDLC extends that pattern to application code: a coding agent runs alongside the work, proposes the fix, and validates it against the build before anyone is paged. Patching stops being a project a person owns and becomes a process the system runs, and the dependency churn that once landed on a developer’s afternoon gets absorbed by the system that proposed the change.

Developer security friction is gone. Security isn’t.

The Agentic SDLC removes the structural reason developer security friction ever existed. That is not the same as removing the need for security, or the need for developers and security to work together. Both are as real as they ever were. What changed is the world around them. Software is now built by agents, and the old answers no longer fit: security practiced the way it always was, beside a developer-security relationship run the way it always was, will only manufacture new friction against an Agentic SDLC. Each has to turn agentic too.

Security’s job shifts from reviewer and gatekeeper to architect, encoder and enforcer. The context that let a senior practitioner judge a real vulnerability, what an application does and where it can be reached, used to live in too few heads and arrive only after the code was written. Now that same context has to be readable for the agents writing the code, encoded into the build and enforced as the code is written.

The relationship has to change the same way. A security champion program used to exist to push security knowledge into developers, training and nudging them into caring enough to fight the friction. An agentic security champion program starts from the opposite fact: the agents already hold that knowledge. The work becomes orchestration, knowing how to direct those agents well, when to pull a human expert into the loop, and how to build on judgment the team no longer has to carry in its own head. That is the program worth building now.

The post How the Agentic SDLC fixes developer security friction appeared first on Clover Security.

NEW YORK, NEW YORK, May 12, 2026. Clover Security, the design-led product security company built for the Agentic SDLC, today announced its inclusion in Rising in Cyber 2026, an independent annual list launched by Notable Capital to recognize the 30 most promising private cybersecurity startups. Now in its third year, Rising in Cyber has become a trusted signal of what is actually moving the needle in enterprise security.

Unlike traditional rankings, Rising in Cyber honorees are selected through voting by 150 active CISOs and senior security executives. The result is a reliable signal of what security teams are actually adopting to address their most urgent challenges.

Clover joins a cohort that has collectively raised over $6.9 billion, according to PitchBook, and is defining the next generation of cybersecurity across critical areas including identity and access management, agentic AI security, security operations, and application defense.

The 2026 honorees were named alongside the release of the Rising in Cyber 2026 Report, produced in collaboration with Morgan Stanley. The report draws on CISO survey data and market analysis to map how the cybersecurity industry is evolving, from AI agents reshaping security operations to a historic surge in strategic M&A, and separates signal from noise for investors, operators, and security leaders.

“Security is now moving from a constraint to an enabler on how fast AI can actually scale inside the enterprise. The 150 CISOs who voted on this list understand that better than anyone,” said Oren Yunger, Managing Partner, Notable Capital. “Congratulations to this year’s Rising in Cyber honorees for earning their trust.”

Honorees will be recognized at a private event on May 12 at the New York Stock Exchange in San Francisco alongside top security leaders and investors.

“The 150 CISOs who voted on this list have validated what we live with every day: in the agentic era, engineering work moves upstream into intent, design, and the context AI agents operate in. Security has to follow,” said Alon Kollmann, CEO and co-founder of Clover Security.

Behind the recognition is a year of compounding traction for Clover. In March 2026, ServiceNow made a strategic investment in Clover and, as a customer, will be integrating Clover’s AI security agents into the ServiceNow enterprise solutions suite. Clover’s customer base has grown 4x year-over-year and now spans enterprise software, financial services, and commerce, with deployments at Expedia, Instacart, Plaid, Notion, Lemonade, Virgin Money, Neo4j, AlphaSense, and PROS. At Virgin Money, one of the UK’s largest banks, Clover runs design-led product security at 4x efficiency. Over the same twelve months, the team has more than doubled in size and continues to scale across Tel Aviv, New York, and San Francisco.

To learn more about Rising in Cyber 2026, visit www.notablecap.com/risingincyber.

About Clover Security

Clover Security delivers design-led product security for the Agentic SDLC. Its AI agents build a live context model from design through code, reason like senior security architects, and surface architectural risk before it ships. Clover is security’s force multiplier in the agentic era, catching design flaws before code is written and embedding continuous, context-aware security across the development lifecycle. The company is headquartered in New York with operations in Tel Aviv, and serves enterprise customers including ServiceNow, Expedia, Plaid, Notion, Lemonade, and Virgin Money. Clover is backed by Notable Capital, Team8, and SVCI. Learn more at www.clover.security.

About Rising in Cyber

Rising in Cyber is an annual list and research initiative that recognizes the most promising private cybersecurity companies, as selected by nearly 150 practicing CISOs and cybersecurity executives. For more information about the Rising in Cyber list, report, and methodology, visit www.risingincyber.com.

About Notable Capital

Notable Capital is named for the founders we invest with, the ideas they pursue, and the companies they build. An early-stage venture capital firm headquartered in the U.S., Notable brings a global perspective to cloud infrastructure, cybersecurity, fintech, commerce, and AI, investing across the U.S., Israel, Europe, and select go-global markets.

Notable Capital’s portfolio companies include Affirm, Airbnb, Anthropic, Browserbase, Drata, fal, Handshake, Quince, Slack, Square, Vercel, Wispr, and more. More information at www.notablecap.com.

Contact

Clover Security

Moran Halevi, VP Marketing

moran@clover.security

+972.52.843.1154

Notable Capital

Christine Hinton

chinton@notablecap.com

+1 415.939.0139

The post Clover Security named to Rising in Cyber 2026 by 150 CISOs and security leaders appeared first on Clover Security.

If you lead security at any organization that ships software, you already know this is not just AI-assisted development but a structural transformation of how software gets built, one that is fundamentally reshaping who writes the code, how it reaches production, and what a security review actually needs to cover. All at a pace where developers can now push hundreds of pull requests faster than your security team can review one.

Every transformation of this scale, from open source to cloud to DevOps, has been a defining moment for the security leaders who lived through it. The ones who called the shift early and redesigned their programs around it became the architects of how their companies built security for the next decade. The ones who waited spent that decade catching up. This transformation is no different, except that it is moving faster than any of its predecessors. Securing the Agentic SDLC is not just another item for the roadmap. It is a fundamental rethinking of security for the entire ecosystem, which will define our craft and success for the decade ahead.

What is the Agentic SDLC?

The traditional SDLC followed a familiar chain: requirements → design → implementation → testing → deployment → monitoring. Humans drove every stage. Code was the artifact of human thought, written line by line, reviewed by peers, and shipped through well-understood CI/CD pipelines.

The Agentic SDLC breaks that chain.

In this new model, engineering focus shifts to three core activities:

1. Specifying intent, design, and architecture.

The most critical work in software development is no longer writing code, it’s defining what to build and why. Engineers and product managers spend more time crafting specifications, defining system architecture, and articulating design intent than they spend on implementation. As Anthropic’s report notes, “human expertise focuses on defining the problems worth solving while AI handles the tactical work of implementation.”

2. Manage context and tools. 

Developers now curate the context that agents operate within, and that curation is a craft in its own right. It starts with choosing the right model or agent for each task, defining how it operates, and selecting the tools it gets access to. It extends to configuring MCP servers, building Claude Skills, writing custom system prompts, and maintaining the knowledge infrastructure that lets agents make good decisions. The quality of the output is directly proportional to the quality of the context provided.

3. Reviewing and validating massive volumes of agent output. 

When agents can work for hours or days autonomously, generating entire feature sets or even complete applications, the human role shifts from writing code to reviewing it, evaluating architectural choices, validating design decisions, and ensuring the system as a whole solves the right problems. Anthropic’s research reveals that while engineers use AI in roughly 60% of their work, they can only “fully delegate” 0-20% of tasks. The rest requires active collaboration, supervision, and judgment.

Code itself is becoming a commoditized implementation detail. The real craft, the work that determines whether software is good, secure, and correct, is moving upstream to intent, design, and context.

Three audiences of agentic builders

The Agentic SDLC isn’t producing a single, uniform type of builder. It’s producing three distinct audiences, each with a fundamentally different relationships to code, to tooling, and to the enterprise development pipeline. Understanding this breakdown is essential, because each audience creates a different category of security challenge.

Audience 1: Technical builders

These are the professional software engineers who have evolved from writing code to orchestrating agents that write it for them. They are the core of the Agentic SDLC.

In Anthropic’s framing, the engineer’s role has shifted from “implementer to orchestrator.” In 2026, the value of an engineer’s contribution increasingly lies in system architecture design, agent coordination, quality evaluation, and strategic problem decomposition. They shepherd multiple features through development simultaneously, applying their judgment across a broader scope than individual implementation ever allowed.

These builders work in tools like Claude Code, Cursor, and IDE-integrated agents. They express intent, provide context via MCP servers and Claude Skills, review agent-generated output, and ship through standard CI/CD pipelines. Some prompt agents conversationally; others collaborate with PMs and architects on detailed design docs that guide agent behavior.

A growing subset of this audience is going further, adopting spec-driven development, where structured specifications are committed to version control and serve as the primary input to autonomous code generation pipelines. GitHub’s Spec Kit has reached 89.2k stars. The Kiro IDE team cut feature builds from two weeks to two days. AWS engineering teams completed an 18-month re-architecture with six people in 76 days. Spec-driven development is powerful, but it remains an optional adventure at this point, a maturity level that some organizations pursue, not a path most companies will necessarily follow. Whether an engineer prompts an agent conversationally or feeds it a formal spec, the common thread is the same: they are technical builders who no longer write code manually, and whose primary craft has shifted to intent, design, and architecture.

The security challenge here is about scale and context. These builders are 10x more productive, shipping at volumes that overwhelm traditional review processes. And the agents they orchestrate make design decisions without institutional memory, without awareness of trust boundaries, past security incidents, or adjacent system dependencies. The output is technically excellent but contextually blind.

Audience 2: Semi-technical builders

A second, rapidly growing segment of builders are those who aren’t professional engineers but are now producing production code: product managers, designers, data analysts, junior developers. They use natural language, “vibe coding,” the term coined by Andrej Karpathy, to prompt AI agents and generate working software, which then enters the standard SDLC through pull requests.

The pattern looks like this: the builder describes what they want in plain English. Claude or Cursor generates the code. A developer reviews the PR. Tests run, CI/CD deploys, and the output reaches production. It’s an enterprise-guardrailed version of vibe coding, the output enters the standard pipeline, but the person who initiated it may have limited understanding of the architectural and security implications of what they’re shipping.

The code itself is often syntactically clean, AI models are sophisticated enough to avoid the tactical issues that scanners flag. But the design decisions embedded in that code are made by an AI agent operating without organizational context, without understanding of the broader system architecture. Palo Alto’s Unit 42 has documented real-world breaches caused by this exact pattern: a sales lead app compromised because the agent skipped authentication and rate limiting, an AI agent deleting an entire production database despite explicit instructions, authentication bypasses from exposed public IDs. Their root cause finding is that AI models “prioritize function over security” and suffer from “critical context blindness.” An independent scan by Escape.tech of 5,600 vibe-coded production applications confirmed the scale of the problem: over 2,000 vulnerabilities, 400+ exposed secrets, and 175 instances of exposed PII, including medical records and authentication credentials. And these are typically design-level flaws, not syntax errors.

Anthropic’s own research confirms this is becoming mainstream: the barrier separating “people who code” from “people who don’t” is becoming permeable. As their report notes, “coding capabilities democratize beyond engineering,” with non-traditional developers building in fields like cybersecurity, operations, design, and data science.

The security challenge here is about visibility and literacy. The people generating code may not understand what a trust boundary is. The developers reviewing their PRs may be overwhelmed by volume. And the design decisions being made are invisible to any tool that only looks at code.

Audience 3: Citizen developers

The third audience is often the least visible, and introduces a unique set of risks. Non-technical builders across sales, marketing, legal, and operations are using Claude, Lovable, and other no-code/low-code tools to build internal applications, automations, and workflows that never enter the formal SDLC at all.

Anthropic’s trends report confirms this is accelerating: “Non-technical teams across sales, marketing, legal, and operations gain the ability to automate workflows and build tools with little or no engineering intervention.” Zapier has achieved 89% AI adoption across its entire organization with 800+ AI agents deployed internally. Anthropic’s own legal team reduced marketing review turnaround from two to three days down to 24 hours by building Claude-powered workflows. Domain experts implement solutions directly, removing the bottleneck of filing a ticket and waiting for engineering.

Citizen-developed applications break the boundary between corporate security and product security. They operate entirely outside the purview of traditional product security teams. There is no PR to review. No CI/CD pipeline to gate. No design doc to analyze. These applications go directly from business need to production usage, with whatever security posture the AI agent happened to bake in by default. They often handle real customer data, connect to real internal systems, and operate as de facto production software, without ever being seen by a security engineer.

A security mandate that can’t be met

Product security teams were already struggling to keep up with human developers long before any of this started. Backlogs were growing, reviews were slipping, and threat models were going stale faster than teams could refresh them. Now add agentic developers shipping at 10x volume, vibe-coded pull requests from semi-technical builders who don’t know what a trust boundary is, and citizen-built shadow IT that never enters the pipeline at all. This rapidly increases the threat surface, at a pace no human process was designed to match.

Manual review processes, design reviews, architecture assessments, and threat models all remain high-fidelity activities that catch real flaws. But they are fundamentally human-speed processes facing machine-speed output from three different directions.

This is the core tension of the Agentic SDLC: security teams are under more pressure than ever to secure these applications, while also being expected to enable the greatest productivity boost of our generation. Block the agentic pipeline and you block the business. Let it run unchecked and you accept unquantifiable risk.

What security for the Agentic SDLC requires

We founded Clover because the industry requires a fundamentally new approach to software security, one that works across all builder audiences, at machine speed, with continuous understanding of design, architecture, and intent.

Context is the new foundation. In the traditional SDLC, humans carried context implicitly, why this service exists, what data it handles, what the trust model is. In the Agentic SDLC, that context evaporates. AI agents operate without institutional memory, without awareness of adjacent systems, without understanding of past security decisions. Security that doesn’t start with context, deep, architectural, continuously-updated context, is security that can’t function at an agentic scale.

Clover builds a live context engine that fuses product context (what we’re building and why), technical context (how it’s built, what talks to what, where sensitive data flows), and security context (what could go wrong, what’s been reviewed, what assumptions remain unvalidated). It does this by plugging into the tools builders already use: Confluence, Jira, GitHub, Claude, Slack, and continuously analyzing the evolving state of every product and application.

Building an effective context engine is the difference between security agents that spit out AI slop and an effective agentic infrastructure that actually works at scale. With the right context in place, this engine can secure all three builder audiences:

1. Technical builders get fast, high-signal feedback they can iterate on, without the noise of traditional scanners.
2. Semi-technical builders produce higher-quality code with simpler inputs, as architectural context is enforced downstream.
3. Citizen developers can move quickly while staying within company guardrails, even outside the formal SDLC.

The security shift isn’t from scanners to better scanners. It’s from scanning code to understanding context. When code is commoditized, risk moves upstream, into design decisions, architecture, and implicit assumptions agents make without awareness. AI-generated code will often pass scanners while still introducing systemic flaws. The question is no longer simply “is this code vulnerable?” but “did we make the right decisions before the code existed?” Clover operates at that layer, analyzing intent, architecture, and trust boundaries before they become implementation.

Facing the security challenge (and opportunity) of the decade

When your builders adopt something faster than you can govern it, that’s a signal that your security model’s status quo is shifting beneath you. GitHub arrived in enterprises through backchannels years before security teams were ready to bless it. ChatGPT showed up on employee laptops months before most CISOs had an AI policy. Every seismic shift in how software gets built has followed the same pattern: the builders move first, the organization catches up later, and the security teams who treated the shift as a threat to contain ended up running behind the ones who treated it as a shift to secure. The Agentic SDLC is the same pattern, at a larger scale, moving faster.

And the pattern is already playing out. Inside the organizations moving fastest, the Agentic SDLC is not next year’s planning exercise, it’s today’s production reality. Engineers are orchestrating agents. Product managers and designers are shipping vibe-coded features. Sales, legal, and operations are building applications that never touch a pull request. The builders are already speaking loudly, in three different voices, and the security model sitting on your desk wasn’t designed to hear any of them.

Every security leader reading this already has more on their plate than the hours in a day allow. Scanners to triage, vulnerabilities to patch, pen tests to run, compliance clocks ticking. All of it matters. All of it is real. But none of it will define the next decade of product security. This will. The leaders who recognize that first, the ones who stop treating agentic development as a threat to contain and start treating it as the terrain they now operate on, are the ones who will still be leading when the dust settles. The rest will be explaining to their boards why the pipeline got away from them.

The craft of software has moved from code to intent. The craft of security has to follow. Not eventually. Now.

We’ve been building Clover for exactly this future, and we’ll have a lot more to share soon. If you’d like an early look at what we believe security for the agentic era has to be, get in touch.

The post Securing the Agentic SDLC appeared first on Clover Security.

After acquiring three companies in Israel, American software giant ServiceNow is also investing directly in Israeli startups. Calcalist has learned that ServiceNow has invested in Israeli cybersecurity company Clover Security, in a deal estimated to be worth several million dollars.

As part of the investment, ServiceNow is expected to integrate Clover’s technology into its own suite of enterprise solutions and will also become a customer of the company.

Clover was founded in 2023 by Alon Kollmann (CEO) and Or Chen (CPO). The two met in 2022, when Kollmann was pursuing an MBA in France and Chen was completing his tenure at Checkmarx, which had acquired Chen’s previous startup.

Clover integrates AI agents into everyday developer tools such as Confluence, Jira, GitHub, Cursor, and Slack, enabling teams to identify design flaws early and build securely from the outset. Its AI agents replicate the mindset of experienced security professionals, understanding system behavior, predicting where vulnerabilities may emerge, and applying security principles before development begins. As a result, security teams are relieved of repetitive work, and developers receive real-time security guidance inside their existing workflows.

In November, Clover raised $36 million in a funding round led by Notable Capital and Team8. Since then, the company has expanded its operations, signed additional customer agreements, and reached a revenue run rate of more than $1 million per quarter. Clover currently employs around 50 people, most of them based in Israel, with the remainder in the United States.

ServiceNow has been steadily expanding its presence in cybersecurity in recent years, positioning the sector as a key growth engine. The company has previously invested in Snyk and recently acquired Armis for approximately $7.75 billion. It also announced acquisitions of Israeli AI and data companies Pyramid Analytics and Traceloop.

The partnership with ServiceNow is expected to significantly expand Clover’s market reach, giving it access to thousands of enterprise customers worldwide through ServiceNow’s platform.

“ServiceNow is one of the most influential enterprise software platforms in the world,” said Kollmann. “The decision to invest in us and partner with us reflects how the market is evolving. As AI-driven development accelerates, security must be embedded directly into the software creation process, not added later. For us, this is another step toward making this approach the standard in global organizations.”

The post ServiceNow invests in cyber startup Clover Security appeared first on Clover Security.

Today we are proud to share that Silicon Valley CISO Investments (SVCI) has joined Clover Security as a strategic investor. What makes SVCI distinct is not only their track record of successful investments, but their perspective as practicing security leaders. SVCI is a community that brings together dozens of CISOs who protect some of the most complex and consequential technology environments in the world. SVCI members lead security programs for some of the most technology-enabled and forward leaning companies that are rapidly embracing AI-native software development. As early adopters of this shift, they have concluded that … design-led security must be accelerated, iterated and rapidly integrated into the development lifecycle to maintain pace with the way software is being built today. The winners through this era will be those companies that adopt this trend and evolve alongside as the bar continues to be raised on what it takes to earn customer trust.

Why Clover

Across the ecosystem, a clear shift is underway. Security teams are increasingly shifting their focus to collaborating with engineers early in the development lifecycle. The most critical design decisions often take place even before a single line of code is written; security needs visibility and influence into those decisions, to ensure product changes are built securely by nature.

Clover stood out to SVCI not only because of its unique, fresh perspective on the evolution of product security, but also because of its rapid customer adoption and growth, signaling a clear market shift. Customers with advanced engineering stacks or resource constraints are rapidly adopting design-led product security not as an experiment but as a strategic part of how they build software. Together with Clover’s consistent execution, rapid expansion within organizations, and customer feedback, this solidified SVCI’s conviction that Clover is positioned to lead a new category and define how modern software will be secured.

What’s next

With SVCI, Clover gains both strategic insight and direct access to the leaders shaping how security teams adapt to AI-native development. Their experience helps us refine the technology where it matters most, and their network accelerates the adoption of design-led product security across the industry. This partnership strengthens our ability to define new expectations and build the standards that will guide how software is securely designed in the years ahead.

The post SVCI backs Clover Security to empower companies to secure their products by-design, fueled by AI appeared first on Clover Security.

Let’s be honest: it’s become completely impossible to keep up with the progress of AI and how it transforms software development. Every time we think we have a handle on what’s going on, OpenAI or Anthropic releases another model, capability, or way of building apps.

What started with basic code-completion capabilities has now evolved into autonomous agents that act on behalf of developers, generating code and features at an unimaginable speed. But architecture itself is also getting more complex. New AI patterns like RAG, agents, and MCPs are being pushed into existing products before security guardrails and policies are even set. And if that’s not enough, HR and Marketing teams are now spinning up entire products in hours. Everyone has become a builder, and that reality is here to stay.

What this means for security

This new era brings extraordinary innovation but also unprecedented risk. Engineering capacity is multiplying through AI while security capacity has remained largely fixed, and the gap is only widening. When AI agents can generate entire features in seconds, the old reactive security model simply can’t keep pace.

For the past decade, we tried to solve software security by looking for better ways to do reactive scanning. Scanning more, scanning earlier, scanning smarter… “Focus on what matters most”, they said. In theory, it sounded like progress. In practice, we’ve been incrementally optimizing a flawed approach. SAST, SCA, DAST, secret scanners, ASPMs, CSPMs, runtime scanners, reachability, prioritization, and remediation, AI-powered AppSec, agentic AppSec. Different names, different roles – all different flavors of the same reactive pattern. All focused on detecting issues after implementation had been completed and developers had moved on to the next task. We’ve been adding smarter fire alarms to a straw house that keeps catching fire instead of rebuilding with fire-resistant materials.

With AI, it’s even clearer that reactive security is flawed at its core. AI models are continuously improving to the point where they will eventually stop introducing known vulnerabilities altogether. At the same time, AI gradually distances builders from code syntax, intricate implementation details, and focuses their attention on high-level design, specification, and outcome.

In this new world, reactive scanners are simply not enough. Security has to be design-led. It must understand intent, architecture, and system behavior before code exists. Teams don’t need another scanner or a faster workflow. They need a way to eliminate entire classes of issues by addressing them where they start, inside the design process. That’s how security moves at the speed of development, embedded where products begin instead of where they break.

A new design-led mindset

Design-led product security is about making security a natural part of the building process, guiding and collaborating with builders long before implementation begins. Every architectural decision is a potential security decision. Every integration, every data flow, every dependency carries consequences that no tool can “patch out” later. These decisions are being made by developers, product managers, architects, and AI agents – while security teams are not in the room, more often than they are.

Clover was built to live in that creative moment: the earliest conversations, the messy drafts, the evolving diagrams. It was built to bring the security guidance that helps teams reason about security, privacy, and compliance – and influence decision making before those ideas translate into code.

Similar to onboarding a new security team member, Clover’s AI agents start with learning the organization’s context, digging into existing documents and code bases, observing how teams build, and continuously learning from feedback. Finally, they can naturally extend the security team and help them scale manual activities like design reviews, architecture reviews, threat modeling, and more – in ways that were simply not possible before.

Scaling product security with context

We believe security should scale at the speed of innovation. That means:

Starting with context. Understanding architecture, intent, and system behavior before anything is built, so security becomes part of the design conversation, not the post-mortem.

Meeting builders where they are. Inside the tools where ideas are captured, designs evolve, and code takes shape, including Confluence, Jira, GitHub, Cursor, and Slack.

Designed for scale. Scaling secure design means operating in complex enterprise environments, with varying technologies, processes, and cultures.

These are the design principles that guide every feature and use case we build at Clover. They didn’t come out of creative brainstorming sessions, but from hard lessons our team learned over the past decade building application and cloud security solutions at places like Microsoft, Checkmarx, and Dazz (acquired by Wiz).

We learned through hard lessons that product security cannot be reactive. It must be proactive.

It’s become clear to us: good product security is when builders don’t feel you slow them down. Great product security is when builders want to pull you into the room, not because they have to, but because you make their product better.

Looking ahead

We’re proud to see Clover powering teams that are building some of the most advanced products in the world – across financial services, enterprise software, and consumer applications. Our mission is simple but transformative: make software products secure by nature.

As AI reshapes how software is built, we’re redefining how it is secured. Because in the AI era, the most powerful way to make products secure isn’t to react faster, it’s to design smarter.

The post Introducing Clover Security: Design-led product security for the AI era appeared first on Clover Security.