featured articles
Prime introduces a new operating model for Product Security
Prime Security today introduced a new operating model for Product Security, expanding its platform to help security teams participate in every product decision - from architecture and design through implementation and continuous validation.
The announcement comes as the company returns to Black Hat USA, one year after winning the conference's prestigious Startup Spotlight competition, where it will showcase the expanded platform this week in Las Vegas.
Prime's expanded platform addresses a fundamental change in how software is built. As AI accelerates engineering and compresses the distance between architecture, implementation, and deployment, security can no longer rely on reviewing finished code alone. It must participate continuously as products are designed, built, and shipped.
From day one, Prime has taken a different approach to Product Security. Rather than analyzing isolated pieces of software, the platform was built to understand products as complete systems - starting with architecture and design decisions, where critical security context is created long before code is written.
That architectural foundation now extends across the entire product lifecycle, enabling security teams to participate before the code, in the code, and after the code through a shared understanding of the product.
The expanded platform includes autonomous design reviews, AI security code reviews, AI coding guardrails, risk-focused software supply chain security, and continuous white-box pentesting - all powered by the same understanding of the product and its architecture.
Prime CEO Michael Nov said:
"Software development has fundamentally changed. Architecture, implementation, and deployment no longer happen as separate phases - they increasingly happen together, often inside the same AI-assisted workflow. Security can't keep up by reviewing software after it's built because the important decisions have already been made. Product Security has to participate as those decisions are being made. That's what Prime was built for."
Backed by Foundation Capital, Flybridge and Scale Venture Partners, Prime is trusted by organizations including PayPal, Bumble, Qualtrics, MX, and ThoughtSpot among its customers.
Customers report completing security design reviews in as little as 15 minutes, increasing security team capacity by 4-5x, and reducing false positives by up to 90% compared to traditional application security approaches.
Learn more at https://www.primesec.ai or visit https://www.primesec.ai/blackhat-2026 for Black Hat activities and event information.
Before the Code. In the Code. After the Code. Security in the age of AI Factories
Software development didn't just get faster. It broke shape. The old shape of plan, design, build, test, deploy is not how software gets built anymore. Now it is specs in one place, prompts in another, code written by humans and agents, architecture decisions made in a chat window, and tests generated after the fact.
The boundary around who builds is dissolving too. Engineers orchestrate agents. Product managers turn ideas into real products with the help of vibe coding. Business Analysts build workflows that touch real data and real systems. Some of it enters the formal SDLC. Some never do. All of it changes the attack surface.
The end state is becoming obvious: software factories run mostly by agents, the way lights-out factories run manufacturing lines with no humans on the floor. Some companies are already there. Most are in the awkward middle - partial adoption, uneven quality, and pressure to move faster anyway.
Strip away the noise and the goal is simple: whatever reaches production has to be secure and follow the rules you set for it. That job did not change. Everything around it did.
Shift left and DevSecOps were the right answers for their moment - but both were designed around developers making decisions. Now agents make architectural choices, wire data flows, and push work forward faster than any human checkpoint can follow. Every prompt, every PR, every agent-generated feature is an architectural decision your security team never reviewed.
The next model is not a faster human. It is an autonomous security agent operating in the same environment as the development agents - and it cannot work component by component. Attackers already don't: AI-powered attack tooling chains the design flaws, code vulnerabilities, and cloud misconfigs your agents just introduced into single exploitable paths. Scanners see files. Pipelines see changes. Attackers see weaknesses - and need only one that connects. Security has to see the product - that is where weaknesses connect: what is being planned, what is in work, and what has shipped.
That is what Product Security means now. Not security embedded in a pipeline - security as an autonomous participant in it, holding the product view through every stage: before the code, in it, and after it.
Before the code - where intent gets set and attack vectors get introduced
For business critical features and complex systems, design still deserves real scrutiny before a single line gets written. An agent factory executing a flawed design quickly is worse than a slow team building the wrong thing manually. The blast radius is bigger. A missing auth requirement, a broken tenant isolation model, an exposed data flow - these are not code problems. They are design decisions, and agents execute them at speed.
As spec-driven development matures, getting the spec right becomes the highest-leverage security investment you can make. The old way of getting it right was threat modeling - a workshop, a whiteboard, an architect asking the right questions. It worked, for the handful of features that got one. That trade dies when a product manager's spec becomes running code in a day. Autonomous review changes the economics: it reads every spec, ticket, and PRD as it is written - wherever intent lives - and asks what the architect would have asked.
What the design stage gives you is the missing context: what the feature is meant to do, who should reach it, what data it touches, and what it must never allow. Without that, the check after the code can only answer one question: is this vulnerable? With it, it can answer the ones that actually drive a decision: does this vulnerability matter, what does it cost the business, and is this what was supposed to get built?
Design is still where security starts. It is no longer where it stops. The review does not produce just a report. It produces the context the next stage runs on.
In the code - security cannot just guide agents. It has to act.
Prompts change. Models change. Agents change. The system is what accumulates - every architecture decision, every trust boundary, every data flow, every intent, layered over years. Without that context, a security agent can reason about code. With it, it can reason about the system.
Security has two jobs here: steer the work while it is written, and gate it before it merges.
Steering happens in the moment. A development agent starts wiring a new data flow - the security agent loads the live architecture, reads the trust boundaries, and if something is wrong, intervenes. Not a flag. Not a ticket. An agent with the authority to block a bad decision before it is ever committed.
The gate is the pull request - the last moment a change is still just a proposed change. Everything gets checked, every time, no matter who or what wrote the code. The gate answers one question: does this change violate a rule you already set? Hardcoded secrets, broken cryptography, and prohibited patterns do not require system-wide reasoning. They are known violations and should be stopped immediately. That is what makes the gate fast, deterministic, and difficult to argue with. Exploitability is a different question.
The PR merges. The change becomes part of the system. And exploitability lives in the system, not the diff.
After the code - where exploitable paths get validated
The change has landed. It is part of a system now. Whether it is exploitable is no longer a fact about the change - it is a fact about the system around it. The gate answered one question: did you break a rule. This stage answers the other: is there a path to exploit. The analysis starts the moment the change lands, before anything ships, and it never stops after.
First, at the repo level. A flagged line of code matters only if it plays a part in an attack path - as the way in, or as a step along the way - past the controls that exist. A vulnerable dependency only matters if the vulnerable function is reachable and exploitable with input an attacker controls. Part of no path is noise. That is how the 200-issue queue dies - validation eliminates the 195 that never mattered and confirms the five that did.
Then at the system level, continuously. Clean when it landed does not mean clean today: a new CVE drops against a dependency you merged six months ago, a cloud config drifts, another team's change opens a path through your service. The attacker does not care which PR introduced which piece - only whether a path exists through the system as it runs right now.
You hold the source, the architecture, the cloud controls, and the intent behind every feature - everything an attacker wishes they had, and you have it first. Run the real thing from the inside: continuous, white-box attack path analysis across the live system. An internal service skips authentication because nothing external can reach it. An agent builds on its API, a routing change exposes it - zero findings, one path to customer data. Only the intent recorded on day one makes the last change light up.
Not is this vulnerable - a scanner guesses at that. Is there an exploitable path, through this architecture, past these controls, into this data. You do not infer it. You validate it. The output is not a list of findings. It is a path an attacker can take, end to end.
–
The challenge has shifted. It is no longer "How do we find bugs earlier?" It is "How do we release secure software when the decisions that matter are made autonomously, continuously, and faster than any human review can follow?" That question does not have a checkpoint answer. Security cannot review decisions after they are made. It has to participate in them as they happen.
And participation is not three products at three checkpoints. It is one view of the product - planned, in work, shipped. The intent understood before the code is what makes steering possible during it, and what makes validation credible after it. Break that chain into point tools and each sees a slice; the exploitable path that matters often spans all three. That is not another scanner or another policy engine. It is a new operating model for Product Security.
We built Prime to run that model.
Before the code, it reviews design intent autonomously and records what every feature is supposed to do. In the code, it steers agents and developers with the live architecture loaded, and gates every PR on the rules you set. After the code, it validates exploitable paths continuously across the live system.
This only works as one platform. Prime can validate an exploitable path because it understood what the feature was supposed to do before the code existed, followed how it was implemented, and sees how the system and its controls connect today. That context cannot be reconstructed reliably after the fact. It has to persist from intent through implementation.
The factory is already running. Security can review its decisions after they happen, or participate in them as they are made. We built Prime for the second answer. Before the code. In the code. After the code.
.avif)
The Most Ignored Artifact in Security is Now the Most Important One
Security policies were the documents nobody read. Written, published, forgotten. Developers worked around them. Security teams rewrote them every two years and called it progress. Everyone understood the game and nobody said anything because it was mostly harmless. A bad policy sat in a wiki somewhere and collected dust.
That is no longer the situation.
In an agentic world the agent does not work around the policy. It follows it. Every time. No judgment, no improvisation, no common sense filling the gaps. That changes what a bad policy costs, in a way most security teams have not fully sat with yet.
A bad policy written for humans is a document nobody reads. Mostly harmless because humans ignored it anyway. A bad policy followed by agents is consistent wrong behavior, at scale, across everything your agents touch. It does not sit in a document anymore. It ships.
Here is what that looks like in practice. A policy that says "use appropriate encryption" is standard language in half the security documents written in the last decade. It tells a human to think and make a reasonable call. It tells an agent to decide. It will decide. It might pick MD5. It will be consistent about it.
The language that felt precise enough for a human audience, "appropriate," "reasonable," "where possible," is not precise at all. It is an instruction to exercise judgment. Rewriting policies for agents forces decisions that security teams have been deferring for years. What does appropriate encryption actually mean in this system? What counts as sensitive data in this context? What should the agent never do, regardless of what it is asked? These questions used to live in someone's head. Now they have to be written down in a form a machine can execute without a human in the loop to catch the edge cases.
The difference in practice looks something like this. The old version says "use appropriate encryption for sensitive data." The new version says "all data classified as sensitive must be encrypted using AES-256-GCM at rest and TLS 1.3 in transit. The agent must not proceed if either condition cannot be verified." One requires a judgment call. The other does not. If you cannot write a test that verifies the agent followed the policy, the policy is not done.
There is one more thing the static policy model never had to confront. The threat landscape does not wait. When a new attack technique gets published, the window between disclosure and active exploitation is sometimes days. A policy that was correct last month can be the thing that gets you next month. Human security teams absorbed that kind of change through awareness, the engineer who read the advisory and updated the standard before it mattered. Agents do not read advisories. They follow what they were given. A policy that cannot be updated dynamically and propagated to every agent consuming it in real time is already becoming a liability the moment it is written. Specificity and machine readability make agent-ready policy powerful. They also make it brittle if the update mechanism is not part of the design from the start.
That is a pipeline problem as much as a content problem. The policy layer has to be live. Version controlled, continuously updated against the current threat landscape, and connected to the agents consuming it in a way that does not require a manual deployment every time something changes. That is new infrastructure most security teams do not have yet and are not building.
That is usually how it goes right before something forces it.
Do it before the agent does something your policy technically allowed.
Prime introduces a new operating model for Product Security
Prime Security today introduced a new operating model for Product Security, expanding its platform to help security teams participate in every product decision - from architecture and design through implementation and continuous validation.
The announcement comes as the company returns to Black Hat USA, one year after winning the conference's prestigious Startup Spotlight competition, where it will showcase the expanded platform this week in Las Vegas.
Prime's expanded platform addresses a fundamental change in how software is built. As AI accelerates engineering and compresses the distance between architecture, implementation, and deployment, security can no longer rely on reviewing finished code alone. It must participate continuously as products are designed, built, and shipped.
From day one, Prime has taken a different approach to Product Security. Rather than analyzing isolated pieces of software, the platform was built to understand products as complete systems - starting with architecture and design decisions, where critical security context is created long before code is written.
That architectural foundation now extends across the entire product lifecycle, enabling security teams to participate before the code, in the code, and after the code through a shared understanding of the product.
The expanded platform includes autonomous design reviews, AI security code reviews, AI coding guardrails, risk-focused software supply chain security, and continuous white-box pentesting - all powered by the same understanding of the product and its architecture.
Prime CEO Michael Nov said:
"Software development has fundamentally changed. Architecture, implementation, and deployment no longer happen as separate phases - they increasingly happen together, often inside the same AI-assisted workflow. Security can't keep up by reviewing software after it's built because the important decisions have already been made. Product Security has to participate as those decisions are being made. That's what Prime was built for."
Backed by Foundation Capital, Flybridge and Scale Venture Partners, Prime is trusted by organizations including PayPal, Bumble, Qualtrics, MX, and ThoughtSpot among its customers.
Customers report completing security design reviews in as little as 15 minutes, increasing security team capacity by 4-5x, and reducing false positives by up to 90% compared to traditional application security approaches.
Learn more at https://www.primesec.ai or visit https://www.primesec.ai/blackhat-2026 for Black Hat activities and event information.
.avif)
Prime Security Raises $20M Series A December 2025
Prime’s new platform accelerates development with automated security reviews and full visibility into design-level risks
NEW YORK CITY and TEL AVIV – December 9, 2025 – Prime Security, creator of the first Agentic Security Architect, today announced its $20M Series A funding. The round was led by Scale Venture Partners, with participation from Foundation Capital, Flybridge Ventures, and Ofir Ehrlich, CEO & Founder of Eon. The new funding will fuel Prime’s go-to-market expansion and accelerate development of its Agentic Product Security Platform, a growing suite of autonomous AI agents that continuously monitor, assess, and guide product security throughout the entire development lifecycle.
Modern development runs at machine speed, but security still operates like an assembly line, slow, manual, and dependent on scarce expertise. Today, security teams have the capacity to manually review only a small fraction of planned work before release, leaving the rest to chance. As AI-assisted coding accelerates development velocity, this gap keeps widening. Prime’s agentic platform automates this manual craftsmanship, transforming design-stage protection into a continuous, intelligent process that scales with engineering.
"Integrating security into the design phase has always been a technically challenging manual process. Prime's unique approach transforms this critical, time-consuming stage." said Ariel Tseitlin, Partner at Scale Venture Partners. "This team are both visionaries and operators. Having led technical, GTM, and security teams at companies like PayPal and Own, and scaled enterprise Product Security programs, they've experienced firsthand the problem they're solving. This combination of category-creation vision and deep operational expertise is what defines market leaders."
Prime Security is developing a new era of Product Security, where AI agents bring security into the design stage of every software project and feature. Its flagship product, the Agentic Security Architect, autonomously conducts security design reviews and proactively identifies design flaws across development work. By embedding directly into engineering workflows, Prime enables organizations to accelerate reviews, cut manual effort and cost by more than 60%, and achieve nearly full coverage across planned development tasks.
“Modern product development is changing in front of our eyes,” said Michael Nov, Co-Founder and CEO of Prime Security. “We founded Prime to redefine how security fits into this new world, with agentic systems that operate starting at the design phase, not after development. Our mission is to build security that scales with engineering instead of slowing it down.”
After starting to commercialize the product earlier this year, Prime won the Black Hat 2025 Startup Spotlight this summer and is already working with dozens of customers including PayPal, Qualtrics, Bumble, ThoughtSpot, Redis Labs, and others with development teams of over 200 engineers who are seeing significant impact including:
- Up to 30x faster resolution of design-stage risks
- 100% of planned work receives security assessment versus 10-15% with manual reviews
- 50% reduction in time and cost spent on security reviews
“At PayPal, we know that security must evolve as fast as the threat landscape,” said Shaun Khalfan, CISO at PayPal. “Prime Security’s autonomous, design-stage reviews give us continuous and adaptive visibility across our engineering ecosystem, enabling us to identify and address risks earlier in the software development lifecycle. This capability helps us move with speed and confidence to deliver for our customers and strengthen trust in our business globally.”
By providing continuous, automated security assessment of all planned work, Prime empowers security teams to focus on strategic architecture while ensuring comprehensive coverage of every feature, enhancement, and change flowing through the development pipeline.
ABOUT PRIME SECURITY
Prime Security provides an agentic-powered platform that enables security teams to detect, prioritize, and mitigate risks at the software design phase. Founded in 2023 and headquartered in New York with offices in Tel Aviv, Prime integrates with leading engineering tools to deliver 100% coverage of development efforts without slowing engineering down. The company is SOC2 Type II certified and backed by Scale Venture Partners, Foundation Capital, Flybridge Capital Partners and PayPal Ventures. For more information, visit the website.
Media Contact:
Morgan Grandi
morgan@primesec.ai
.avif)
Prime Security Is Now GA
Today, we’re announcing that Prime Security is officially Generally Available, the first AI Security Architect built to bring security into the design stage of every software project, without slowing development. Development velocity has gone through the roof (thanks, AI), but design-stage security reviews stayed manual, slow, and dependent on a handful of experts. Prime closes that gap.
Prime automates the entire design-review process: discovering design-stage risks across all planned development work, interpreting tasks and documents with full business context, and generating complete security reviews, risks, mitigations, data flows, and compliance ties, in minutes. It operates directly inside engineering workflows, giving teams near-total coverage without forms, questionnaires, or chasing down developers.
With GA, Prime is enterprise-ready: automated reviews for Jira, Confluence, PRDs, and AI-generated plans; risk identification and prioritization; mitigation recommendations aligned to frameworks like NIST, CIS, PCI, and HITRUST; and a self-serve Security Architect chat experience for engineers. Teams at Qualtrics, Yext, ThoughtSpot, and others are already using Prime to accelerate secure development at scale.
Security can’t rely on manual architecture work in an AI-accelerated world. GA is the next step toward Agentic Product Security, where autonomous AI agents continuously monitor, assess, and guide design-stage security. Prime is now ready for every team that needs to secure modern development without slowing it down.
.avif)
.avif)
Security Design Reviews vs. Threat Modeling (April 2026)
The Nuances of Design Stage Security
If you work in cybersecurity (or security adjacent) you are very familiar with the 2 main practices that help to identify and remediate security concerns before development starts; Threat modeling and Security Design Reviews. Both are practical capabilities, and while threat modeling has a variety of frameworks, design reviews are more of a delicate and tactical process that heavily relies on an intimate knowledge of the business. But have you ever felt like your security reviews are missing the mark? Maybe they’re too generic or don’t account for the unique risks your business faces. The challenge often lies in capturing that elusive business context. While threat modeling is a powerful tool, it often happens to be a hammer, and so reluctantly security has to see every design problem as a nail. This makes threat modeling a default approach even when a more nuanced method, like targeted security reviews, would be more effective. By harnessing Large Language Models (LLMs) to sift through unstructured data, we can finally bring the vital context needed to scale security reviews across the board and provide a supercharged version of this method to security practitioners.
Context: The Critical Factor
Traditional security checks often fall short because they can’t adapt to the specific nuances of your business, and threat modeling alone can’t address all the intricacies of secure development. This is where LLMs come into play. By leveraging new LLM empowered capabilities early in the design stage of the SDLC, we can enhance security reviews with deeper context and precision, making them more effective and efficient. This approach allows you to weave security into your systems right from the start, rather than relying on exhaustive modeling for every scenario.
Providing developers with business-driven, concrete security requirements upfront reduces friction and ensures the right tools are used at the right time. By leveraging security reviews at scale for ongoing, contextual feedback, development teams know exactly what’s expected before writing a single line of code, minimizing rework and keeping projects on track. It substantially reduces the dependency on sometimes very cumbersome threat modeling processes that can be an overkill for the task at hand.
Prime Security: Embedding Security before Development starts
At Prime, we focus on security design reviews because we know they’re the most practical and proactive way to secure products from the ground up. By providing the infrastructure to capture and integrate business context, Prime ensures that your security reviews are tailored to the specific needs of your organization. The result? A product that’s secure by design, allowing your teams to move fast without sacrificing security.
.avif)
Building Prime Security
As security professionals and technical leaders we’ve experienced the main pain in developing products. The constant struggle of balancing development velocity with security needs. Through it all, one thing became clear, many security challenges could be prevented given the right context at the design phase of the SDLC. Too often, security comes in at the last minute, scrambling to apply fixes after development is complete, leaving both teams frustrated and out of sync.
Sure, security exists in the SDLC today, but it starts to scale when code is written. You can scan for dependencies, catch bugs, and identify vulnerabilities. But Product Security shouldn’t start with code scanning; it needs to start with design. It’s not just about applying processes or enforcing policies; it’s about influencing decisions before a single line of code is written. Security teams need actionable insight into what’s being built and why, from the earliest stages. But extracting that insight is challenging, scaling it across fast-paced teams is even harder, and making it stick while everyone’s sprinting to meet deadlines can feel nearly impossible.
That’s why we built Prime Security. To truly integrate security into modern development, it has to start at the design phase, not after. We’re not here to slow development down; we’re here to give security engineering teams superpowers so they can support developers to make smarter decisions, faster - embedding security directly into their workflows.
With our unique business and security context extraction engine, Prime Security automates risk assessments and generates tailored mitigation recommendations, ensuring that security isn’t just an afterthought, but a partner in the development process. Prime brings hard-won insights from security professionals right to the point where they’re needed most. This isn’t about adding friction; it’s about unlocking development velocity without compromising on security.
This is the future of Product Security: practical, scalable, and context-driven decisions, integrated from day one. With Prime, security and development teams can truly build securely from the start, setting a new standard for scalable, design-first security. We’ve lived through these challenges, and we’re here to solve them, for good.
Michael, Dimitry, Danny, Matan
