featured articles

The Decision You're Actually Making

Most security teams can build an AI-assisted security review workflow. The question is whether you want to own what it takes to make that system production-grade, accurate, and maintainable, indefinitely. That's a different question, and the answer changes the math significantly.

What Is Prime Security?

Prime Security is a purpose-built AI security review platform designed for software development lifecycles (SDLCs). Unlike generic AI tools or in-house workflows, Prime uses a persistent context graph, a structured knowledge layer that connects your architecture, trust boundaries, business logic, internal controls, and historical security decisions. This means security reviews grow more accurate over time rather than starting from scratch with each request.

Prime covers the full development lifecycle: architecture reviews, threat modeling, documentation analysis, and security analysis tied to tickets and code changes. Agents run continuously across planning and development workflows without requiring custom engineering from your team.

What Does Building In-House Actually Cost?

Early-stage AI security tooling is fast to prototype and hard to scale. Security teams that have gone down this road consistently hit the same wall:

1. Context degrades at scale

Useful security analysis requires understanding your architecture, trust boundaries, historical decisions, and internal controls, not just the ticket in front of the model. Systems that reconstruct this context per request become inconsistent as the codebase and team grow. There is no compounding institutional knowledge; every review starts from near zero.

2. Agentic operation becomes a platform engineering problem

Triggering a review on demand is a demo. Running continuous, autonomous reviews across planning, documentation, and development workflows, with retries, orchestration, and write-back into engineer tooling, is a significant ongoing engineering commitment that compounds as your stack evolves.

3. You end up owning a second product

Maintaining a home-grown AI security system means owning the prompts, the evaluation framework, the integrations, and the improvement cycle. Security expertise encoded in prompts drifts as your architecture changes. Without a dedicated team to run that loop, accuracy degrades quietly, often without anyone noticing until a review misses something it shouldn't.

The build path isn't wrong. For experimentation or limited scope, it can be the right call. But for SDLC-wide Product Security coverage, teams that build often find they've created a second product to maintain.

When Does Building Make Sense?

Building in-house is a reasonable choice when:

• You are running a limited-scope proof of concept or internal experiment
• Your security review surface is narrow and stable (e.g., one team, one repo)
• You have dedicated ML/security engineering bandwidth to own and iterate on the system long-term
• You are not yet ready to evaluate external vendors

For any of the following, the buy path will typically cost less over 12–18 months: SDLC-wide coverage, multiple engineering teams, frequent architectural change, or a security team without dedicated tooling engineers.

What Prime Does Differently

Prime is purpose-built for the part that's hard to build: persistent, context-aware security reasoning across the entire development lifecycle.

Prime's core advantage isn't automation. It's that Prime's persistent context graph connects architecture, business logic, and historical security decisions, so reviews stay accurate as your systems and team evolve, without ongoing engineering investment to keep them that way.

How Prime Compares to Home-Grown Solutions

‍

‍

How Prime Is Different from SAST or Traditional AppSec Tools

Prime Security focuses on security design review and threat modeling across the SDLC, not static code scanning. It applies contextual reasoning grounded in your architecture, business logic, and past security decisions, producing reviews that account for how your system actually works rather than flagging generic code patterns.

Traditional SAST tools catch known vulnerability patterns in code. Prime catches architectural and design-level risks before they reach code, and integrates that context with the decisions your team has already made.

Result: What Teams See After Deploying Prime

‍

“A s our development velocity increased, especially with A I, we

needed a force multiplier we could actually trust. Prime gives us

consistent, high-quality security reviews and threat models across

our entire surface area, and the confidence to operate at speed ."

A l Faiella, Sr . Director of Product Security

Thoughtspot

‍

ThoughtSpot outcomes after deploying Prime:

• 5x increase in security reviews capacity
• 30-minute reduction in per-review execution time
• 100% coverage accross all development surface area

The Bottom Line

You can build a prototype. Prime gives you a system.

If your goal is scalable Product Security review coverage. not a prototype, but a system your team can rely on, the build path will cost more in engineering time and security accuracy than it first appears.

Prime gets you to production-grade coverage faster, with a reasoning layer that improves over time rather than one you have to rebuild every time your stack changes.

‍

Frequently Asked Questions

Should I build an AI security review tool in-house or buy a solution like Prime?

Short answer: Buy, unless you are experimenting at limited scope. For SDLC-wide Product Security coverage, a purpose-built solution is faster to deploy and lower-cost to operate than building in-house. Teams that build often end up owning a second product, with ongoing investment in prompts, orchestration, and integrations, and no built-in mechanism for improving accuracy over time.

What is Prime Security's core advantage over home-grown solutions?

Prime uses a persistent context graph that connects architecture, business logic, controls, and historical security decisions, so reviews stay accurate as your systems and team grow, without requiring internal engineering effort to maintain them. The key distinction is that Prime's accuracy improves over time; home-grown systems tend to degrade.

How much does Prime Security reduce review time?

Prime delivers 5x review capacity, reduces review execution time by 30 minutes per review, and provides 100% coverage across all development surface area, based on results reported by ThoughtSpot.

What is a persistent context graph in AI security reviews?

A persistent context graph is a structured knowledge layer that connects your architecture, trust boundaries, business logic, controls, and historical security decisions. In security reviews, it means the system builds on prior decisions instead of reconstructing context from scratch with each request, so review accuracy improves as your codebase and team grow.

What development workflows does Prime Security cover?

Prime Security covers the full software development lifecycle: architecture reviews, threat modeling, documentation analysis, and security analysis tied to tickets and code changes. Agents run continuously across planning systems and development workflows without requiring custom orchestration from your engineering team.

How is Prime Security different from a SAST or traditional AppSec tool?

Prime Security focuses on security design review and threat modeling across the SDLC, not static code scanning. It applies contextual reasoning grounded in your architecture, business logic, and past security decisions, producing reviews that account for how your system actually works rather than flagging generic code patterns.

What are the signs that a home-grown AI security tool is failing?

Common failure signals include: review quality becoming inconsistent as the codebase grows, reviewers having to re-explain the same architectural context in every session, increasing engineering time spent on prompt maintenance and integration upkeep, and security reviews missing issues that depend on historical architectural decisions. If your team is spending more time maintaining the tool than using it, that's a strong indicator.

How long does it take to deploy Prime Security?

Because Prime is vendor-managed and purpose-built for SDLC security workflows, deployment does not require building orchestration, writing evaluation frameworks, or standing up custom integrations from scratch. Teams can reach production-grade coverage significantly faster than the build path, which typically requires months of engineering investment before reviews are consistently reliable.

Is Prime Security suitable for fast-growing engineering teams?

Yes. Prime is specifically designed for environments where development velocity is increasing and the security team cannot linearly scale headcount to match. The persistent context graph ensures review quality stays consistent even as the number of engineers, repos, and architectural decisions grows.

Does Prime Security replace human security engineers?

No. Prime functions as a force multiplier for your existing security team, handling continuous coverage, routine reviews, and surface area that would otherwise require manual triage. Security engineers are freed to focus on higher-judgment work: novel threat patterns, architectural decisions, and cross-functional security strategy.

‍

Ready to see it in your environment?

We'll scope a POC around your stack and team size - or set up a peer reference call with a security leader who's been through this decision.

Reach out to get started.

When you run a security design review manually, you spend half your time hunting down context that should have been included upfront. Half-written Jira tickets, outdated architecture diagrams, Slack threads explaining what the PRD didn't: this is what passes for documentation. Understanding security design reviews means knowing what questions to ask and which frameworks to apply, but it also means accepting that each review will consume hours reconstructing information before you can analyze actual risk. Your coverage stays stuck at 10 to 15 percent because the overhead never scales down.

What a Security Design Review Is and Why It Matters

A security design review happens before code gets written. Security teams analyze planned features, architectures, and system changes to identify risks while they're still theoretical. The goal is to shape what gets built, instead of inspecting it after the fact.

This matters because of basic economics. Fixing security flaws costs 100x more when found late in development. Refactoring a live system beats rewriting a paragraph in a document every time.

Design reviews differ from tools like SAST and DAST, which scan existing code. Those tools are valuable but reactive. Design reviews operate upstream, deciding where the fire exits go instead of checking if the paint meets spec.

When to Trigger a Security Design Review

Knowing when to trigger a review is half the problem. Most organizations rely on developers self-reporting or informal Slack requests. The result: only high-visibility projects get reviewed, while risky changes slip through because no one knew to ask.

Clear trigger criteria solve this. Reviews should automatically start when development work involves:

• New authentication or authorization mechanisms
• Third-party integrations that handle customer data
• Changes to API endpoints that expose sensitive resources
• Infrastructure changes affecting network segmentation
• Processing of compliance-controlled data types (PII, PHI, payment card data)
• New data stores or major schema changes
• AI model integrations or code generation workflows

Requesting and Scoping the Review: What Security Teams Need

Once a review gets triggered, security needs complete context to work effectively. In theory, teams submit complete PRDs, architecture diagrams, and data flow maps. In practice, you're handed a half-written Jira ticket and a Slack thread.

The gap between what you need and what you get defines the friction. Security teams spend hours hunting down information that should have been included upfront. You're looking for:

• Product requirements document explaining the feature's purpose, user flows, and business logic
• Technical design spec covering system components, data models, and integration points
• Architecture diagrams showing how services communicate and where data lives
• Data classification details identifying what sensitive information gets processed
• Existing security controls relevant to the affected systems
• Compliance requirements that apply to the planned changes
• Dependencies on third-party services or libraries

You won't get all of this upfront. The question is whether you spend your time reconstructing missing context or analyzing actual risk. That difference determines whether reviews take 30 minutes or three days.

Data Flow Analysis and Trust Boundaries

Data flow analysis maps where information travels and how it changes across system boundaries. Track every input, processing step, and output to understand what happens as data moves through your architecture.

Start by identifying entry points where data enters the system: user forms, API calls, file uploads, and third-party webhooks. Then trace the path through each service, transformation, and storage point.

Trust boundaries mark where security assumptions change. Data moving from a user's browser to your API crosses one. So does information flowing from your application to a third-party payment processor. Each boundary changes validation, authentication, and encryption requirements.

Document what data types cross each boundary, which security controls protect them, and where assumptions about integrity or confidentiality change. A diagram showing "User → API → Database" reveals nothing about PII encryption or access control differences between layers.

Threat Modeling Frameworks: STRIDE, MITRE ATT&CK, and LINDDUN

Threat modeling frameworks give security teams a structured way to ask "what could go wrong?" They're thinking tools, not checklists, helping you systematically surface risks that informal analysis misses.

STRIDE categorizes threats by type: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Use it when reviewing application features and data flows.

MITRE ATT&CK maps real-world attacker techniques based on observed breaches. It's best for infrastructure changes, third-party integrations, and scenarios requiring reasoning about how adversaries actually operate.

LINDDUN focuses on privacy threats: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of Information, Unawareness, and Non-compliance. Apply it when processing personal data or building features subject to GDPR, CCPA, or HIPAA.

Most security teams struggle to apply these frameworks consistently.

‍

Risk Analysis and Prioritization

Risk analysis ranks threats by balancing exploitation likelihood against business impact. CVSS scores miss critical context. A severe vulnerability in a three-person admin tool differs from a moderate flaw in customer payments, which affects revenue and compliance.

Use a simple matrix pairing likelihood (low, medium, high) with impact (low, medium, high), then layer in business judgment. What breaks if this threat succeeds? Customer data exposure, service interruption, and regulatory violations all carry different weight. A low-likelihood, high-impact risk in your revenue system typically beats a medium-likelihood, low-impact issue in a logging service.

Context beats formulas. Teams that rank risks against real operations get fixes shipped.

Developing Specific and Actionable Recommendations

Generic recommendations waste everyone's time. "Implement proper input validation" tells developers nothing. Which inputs? What validation? Using which library?

Actionable recommendations specify what to do and how. Instead of "encrypt sensitive data," write "encrypt customer PII fields using AES-256-GCM via the existing CryptoService wrapper before writing to the customer_data table." Reference actual classes, endpoints, or services the team already uses.

Distinguish between blocking issues and improvements. Blocking findings prevent launch: unauthenticated admin endpoints, SQL injection in payment flows, exposed credentials. Recommended improvements strengthen security posture without being critical path: rate limiting on public APIs or shorter-lived token rotation.

Clarity on severity helps engineering sequence work without endless negotiation.

Communicating Findings into Developer Workflows

Findings in Jira get fixed. Developers work in specific tools, and context-switching kills follow-through.

Create tickets linked to the relevant epic or story, with findings as subtasks. For code-level issues, open GitHub issues or PR comments tied to files. Document decisions somewhere permanent. Slack threads disappear.

Match format to severity. Critical issues need synchronous discussion: a 15-minute call beats three days of async threading. Medium-severity findings fit ticket descriptions with acceptance criteria. Low-priority items batch into a single issue reviewed during sprint planning.

Meet engineering in their existing tools to see faster remediation.

Validating That Mitigations Were Implemented

Recommendations get documented, tickets get closed, and teams assume the work is done. Validation proves whether mitigations actually shipped or just got marked complete.

Manual follow-up works at small scale: schedule a 30-minute review where security spot-checks implemented changes against original recommendations. Code review catches tactical fixes, confirming that encryption calls use the right algorithms or authentication checks happen before data access.

Automated validation closes the loop permanently. Write tests that fail if mitigations regress: integration tests verifying auth requirements, security scanning rules that flag missing encryption, or CI/CD gates that block deploys when recommended controls are absent.

Why Manual Security Design Reviews Cannot Scale

Manual design reviews consume 2-4 hours of senior security engineer time per feature. Engineering ships dozens each sprint. The math doesn't work.

Most organizations review 10 to 15 percent of planned work. The rest ships without analysis because teams can't scale. Even at a healthy security-to-developer ratio of 1:100, covering every design means each security engineer spends 20-30 hours weekly just on reviews.

Common workarounds fail. Generic checklists miss context-specific risks. Delegating to junior staff produces inconsistent outputs. Developer self-assessments create false confidence without catching real threats.

AI-assisted development widens the gap. Code generation tools let engineering ship faster while manual review speed stays constant.

Human expertise won't scale to match. Coverage drops and risks accumulate across the backlog.

How Prime Security Automates Security Design Reviews

Prime acts as an AI Security Architect that runs continuously alongside engineering. The system scans Jira, Confluence, and planning tools to identify design-stage risks across all planned work, expanding coverage from 10 to 15 percent to nearly 100 percent.

Prime aggregates context automatically, interprets requirements, applies STRIDE and MITRE ATT&CK, and generates mitigation recommendations in under 20 minutes. Findings flow directly into developer workflows as Jira tickets or GitHub issues.

The system builds institutional memory as you conduct reviews. Past decisions, design patterns, and risk tolerance preferences inform future analysis, creating consistency without requiring the same senior engineer on every review.

Final Thoughts on the Security Design Review Processes

Your security team probably reviews a fraction of planned work not because you're bad at prioritization but because the process itself can't scale. Security design reviews done manually consume more time than most organizations have available, leaving risky changes to ship without analysis. The core problem isn't methodology or frameworks, it's that human-driven review speed stays constant while development velocity keeps increasing. Automation handles the repetitive parts like context gathering and threat enumeration so your architects focus on judgment calls that actually need human expertise. See what automated reviews look like in your environment.

FAQ

How long does a security design review typically take?

Manual reviews consume 2-4 hours of senior security engineer time per feature, while Prime's automated approach completes the same analysis in under 20 minutes by automatically aggregating context and applying threat modeling frameworks.

What's the difference between a security design review and tools like SAST or DAST?

Design reviews happen before code gets written and shape what gets built, analyzing planned features and architectures to identify risks while they're theoretical. SAST and DAST scan existing code after it's written, making them reactive instead of preventive.

When should I trigger a security review for a new feature?

Trigger reviews when development involves new authentication mechanisms, third-party integrations handling customer data, API endpoint changes exposing sensitive resources, infrastructure modifications affecting network segmentation, processing of compliance-controlled data types, new data stores, or AI model integrations.

Why can't manual security design reviews scale with modern development?

At a healthy 1:100 security-to-developer ratio, covering every design means each security engineer spends 20-30 hours weekly just on reviews. Most organizations review only 10-15% of planned work because the math breaks down when engineering ships dozens of features each sprint.

Can I validate that security mitigations were actually implemented?

Yes, through manual spot-checks where security reviews compare implemented changes against original recommendations, or through automated validation like integration tests verifying auth requirements, security scanning rules flagging missing encryption, or CI/CD gates blocking deploys when recommended controls are absent. You can also link a GitHub repository or pull request directly to a mitigation, allowing you to formally identify and confirm whether a specific control has been implemented. This provides a clear, traceable audit trail from recommendation to resolution.

On Feb 19th, 2026, the cyber earth shook! The cyber security market lost billions in a single afternoon. JFrog dropped 25%. CrowdStrike fell 8%. And all because Anthropic launched Claude Code Security.

Here’s what I find fascinating: the market panicked about the wrong thing.

Claude Code Security is genuinely impressive, an AI model that reasons about code like a security researcher, finds zero-days that survived decades of expert review, and suggests patches for human approval. That’s a HUGE milestone. But the breathless headlines about AI “replacing” cybersecurity miss a fundamental truth:

Finding vulnerabilities has never been the hard part. Knowing what to do about them is.

Better scanners don’t solve the real problem

What Anthropic built matters. Reasoning-based vulnerability discovery is a genuine leap, and static analysis becoming embedded in AI coding platforms is the right direction for the industry.

But enterprise security teams aren’t starved for findings, they’re drowning in them. SAST, DAST, SCA, container scanners, each one generating alerts, none capable of answering the only question that matters:

“Should I care about this one?”

That’s a context question. And it eats 80% of a security team’s time.

Claude Code Security is a dramatically better way to find code-level vulnerabilities. But it doesn’t know your architecture, your compliance obligations, or the security exceptions your architect approved last quarter. Without that context, even the most brilliant finding is just another alert in the queue.

Same vulnerability, two completely different realities

Let me make this concrete. Imagine Claude Code Security finds an insecure direct object reference (IDOR) in your codebase. A user can manipulate an API parameter to access another user’s data. The scanner flags it as high severity and even suggests a patch. Impressive work.

Now what?

Without business context, your security team sees one more high-severity finding in a backlog of 200. An engineer spends 45 minutes triaging; pulling up architecture diagrams, pinging the team lead on Slack, digging through Confluence. They eventually discover it’s an internal admin tool used by six people, accessible only through a VPN behind SSO. The IDOR is real, but the blast radius is tiny. Forty-five minutes gone. Multiply that by 30 findings a day.

That’s not security engineering. That’s archaeology.

With organizational context, the same IDOR gets instantly enriched by Prime’s Security Context Engine: Checkout Service, Tier 1, internet-facing, PCI-DSS. The design review eight weeks ago recommended object-level authorization checks and was linked to a Jira ticket which was deprioritized after a production incident. The feature team ships in six days.

Same vulnerability. First scenario: 45 minutes to figure out whether to care. Second: the team acts within seconds due to a critical finding, compliance obligation, known fix, tight deadline.

That’s the difference context makes. A fundamentally different operating model.

This is exactly why we built Prime

Prime’s Security Context Engine is an organizational context graph. A living map of your security architecture decisions, risk exceptions, and compliance requirements. The institutional memory that turns raw findings into actionable intelligence.

Any scanner can tell you what’s wrong. Prime tells you why it matters to your organization, and what to do about it.

Detection is maturing. Context is just getting started.

The Claude Code Security launch validates the thesis we’ve been building around since day one.

Scanning and operationalization tools play a vital role in any mature security program. But detection is converging fast. When a frontier AI model can discover 500 zero-days with no custom scaffolding, the race to find more bugs has a ceiling.

What doesn’t have a ceiling is organizational knowledge. That knowledge compounds with every design decision processed, every review completed, every exception documented. It deepens with time, and new entrants can’t shortcut it.

The three-layer future of product security

Here’s how I see the product security stack evolving:

Layer 1: Design-stage intelligence. Before code is written, understand the security implications of what you’re about to build. This is Prime’s core, automated security and privacy design reviews with architect-level guidance in real time.

Layer 2: Code-level scanning. Once code is written, scan it for vulnerabilities. Claude Code Security, traditional SAST/DAST tools, SCA analyzers live here. This layer is getting dramatically better and cheaper.

Layer 3: Runtime protection and response. Endpoint detection, identity management, network security. CrowdStrike, Cloudflare, Okta and the likes were never threatened by a code scanner, and the market selloff was, as Barclays put it, “illogical.”

The insight is that Layer 1 makes Layer 2 dramatically more useful. When you understand your architecture and design decisions before code is written, every finding from a scanner arrives pre-contextualized. You’re not triaging from scratch, you’re confirming or updating what you already know.

And the benefits to layer 3 I’ll leave to a separate post…

The question security leaders should actually be asking

Anthropic’s Claude Code Security is a genuinely exciting development for defenders. But better scanners mean more findings. More findings without context means more noise. And the real question this launch should prompt isn’t “will AI replace my security tools?” it’s “am I positioned to absorb the coming flood of AI-generated findings?”

The organizations that thrive won’t be the ones with the best scanners, they’ll be the ones that can instantly contextualize any finding against their specific risk posture and act on what actually matters.

Scanners find. Context decides.

And context is king.

‍

In the age of AI-driven development, architecture matters more than ever. Prompts don't change individual lines of code, they change how systems are composed, connected, and allowed to interact. But to change an architecture, you first need to understand what already exists.

In most organizations, that understanding lives in architecture diagrams across tools like Lucid, Draw.io, Miro, and other diagramming platforms.

We benchmarked leading AI models on their ability to understand these diagrams at scale and found that while general-purpose models work on small systems, they break down quickly as complexity grows. Prime maintained accurate system-level understanding even on large, complex architectures, highlighting the difference between describing diagrams and reasoning about real systems.

Why does architecture understanding matter for AI-driven development?

As software systems grow more distributed, interconnected, and automated, architecture has become the primary unit of change. Products are no longer shaped line by line, but by decisions about composition, interaction, and boundaries.

The core decisions that manifest in architecture include:

• How services are composed
• Where trust and responsibility boundaries exist
• Which components are allowed to communicate by default
• How data flows across the system

Once AI enters the development loop, many of these decisions stop being explicit. Choices about service boundaries, dependencies, and integration patterns are increasingly embedded inside prompts and generated artifacts, rather than surfaced through formal design discussions. In practice, the most durable record of those decisions lives in architecture diagrams across tools like Lucid, Draw.io, Miro, PowerPoint, and similar systems-diagrams that reflect how teams actually reason about structure, dependencies, and boundaries.

That leads to a very practical question: If AI systems are going to contribute to building modern software, can they reliably understand the architectures organizations already use to reason about change?

Where architecture diagram understanding breaks down

In practice, this is where teams start to run into problems.

Through our work at Prime with Security Architecture and Product Security teams, we repeatedly saw the same pattern. Uploading an architecture diagram into an LLM often appears to work at first. The model describes the system, names key components, and even infers a few flows.

But as diagrams grow in size or complexity, exactly where real production systems live, the output becomes unreliable:

• Components are missed or merged
• Relationships are dropped or misrepresented
• Trust boundaries disappear
• Critical structure is confidently simplified away

This wasn't a prompt issue, and it wasn't tied to any single model. We saw the same failure modes across teams, tools, and use cases. What broke wasn't the explanation, it was the model's ability to preserve system structure as complexity increased.

At that point, the question stopped being "can LLMs describe diagrams?" and became something more fundamental.

So we decided to measure it.

The experiment: How well can AI models understand architecture diagrams?

We designed a benchmark to test how well different AI systems can understand and extract structure from architecture diagrams.

Systems tested

We ran the experiment across multiple leading, state-of-the-art models, alongside improved methodologies we developed at Prime, using the same inputs and prompts.

What we measured

Two core capabilities:

Node accuracy – How accurately the model identifies and classifies components in the diagram

Edge accuracy – How accurately the model identifies relationships, flows, and connections between components

Edges are particularly important from a security perspective, since they represent data flows, trust boundaries, and potential attack paths.

Methodology

• We used architecture diagrams at increasing levels of complexity, ranging from small diagrams (~15 nodes) to large diagrams (~150 nodes and ~160 edges)
• Each test was run three times per model, averaging the results
• Inputs were high-resolution PNG images generated using draw.io
• Prompts were kept consistent across runs to eliminate prompt bias
• The same diagrams and prompts were used for all models

Can AI models accurately extract components from architecture diagrams?

Node accuracy results

All models performed well on small diagrams. The problems appeared quickly as scale increased:

• Once diagrams exceeded roughly 30-40 nodes, general-purpose models began to degrade rapidly
• Accuracy collapsed entirely for some models by ~50 nodes
• Prime maintained ~95–100% accuracy even at 150+ nodes

The degradation wasn't gradual decline, it was structural collapse. Models that correctly identified 95% of components in a 20-node diagram would miss or merge half the components in a 60-node system.

Can AI models accurately identify relationships in complex architectures?

Edge accuracy results

Edge extraction proved significantly harder for every system, and this is where the real problem lives.

• General-purpose models showed steep degradation as edge count increased
• Some dropped to near-zero accuracy well before 100 edges
• Prime stabilized at consistent accuracy even at the highest complexity tested

This distinction matters: identifying components is useful, but understanding how those components interact is where security insight actually comes from. A model that can list every service in your architecture but cannot reliably map which services communicate, where data flows, or which boundaries matter is fundamentally unable to support threat modeling or design review at scale.

The gap between "can describe a diagram" and "can model a system" becomes obvious once relationships enter the picture.

What causes AI models to fail at architecture diagram understanding?

This experiment highlights a fundamental difference in how AI systems reason about architecture.

General-purpose LLMs treat diagrams primarily as visual artifacts. They interpret, summarize, and compress what they see in a single pass. As complexity increases, they lose global consistency: entities blur together, long-range relationships drop out, and structural fidelity gives way to approximation.

This isn't a limitation of model intelligence, it's a structural constraint of the approach. Vision-language models are optimized to describe images, not to extract formal representations of systems. When you ask them to process a 150-node architecture diagram, they're doing visual interpretation at every step. There's no mechanism to maintain global consistency as local complexity increases.

Rather than processing a diagram in a single pass, Prime uses a multi-stage extraction pipeline that first builds a structured representation of components and containers, then separately resolves relationships and flows. This allows the system to maintain global consistency even as local complexity increases.

In short: most models are diagram readers. Prime is a system modeler.

Why accurate architecture understanding matters for threat modeling

This distinction matters because architecture understanding is not an academic exercise.

Teams increasingly need AI systems that can reason about architectures before code exists, across hundreds of concurrent initiatives, and without losing consistency as development velocity increases. If a system cannot preserve architectural structure beyond small diagrams, it cannot reliably support design-stage reasoning at scale.

Consider what breaks when architecture understanding fails:

• Threat models miss critical data flows because the model dropped edges
• Security reviews produce inconsistent guidance on similar architectures
• Risk assessments fail to account for trust boundaries that weren't extracted
• Teams lose confidence in AI-assisted analysis and revert to manual review

At 30% - 50% accuracy, automated threat modeling isn't just less useful, it's actively harmful. Engineers stop trusting security guidance, and security teams spend more time debugging bad outputs than they save from automation.

Conclusion: What it takes to understand architecture at scale

The takeaway is not that LLMs are "bad at diagrams." It's that understanding architecture requires persistent, structured system reasoning, not just visual interpretation.

Most AI systems were built to interpret and describe. Prime was built to model and reason. This experiment makes that difference measurable.

The challenge wasn't incremental, it required rethinking how architectural understanding works. General-purpose models will continue to improve at visual interpretation, but the structural problem remains: treating diagrams as images to describe rather than systems to model means accuracy collapses as complexity grows.

Prime solved this by building extraction pipelines that preserve structure first, then resolve relationships within that structure. The result is consistent accuracy on large, complex diagrams at scales where other approaches break down entirely.

For organizations adopting AI-driven development or trying to scale threat modeling and security design reviews, this matters immediately. The architecture diagrams you already use to reason about systems need to be something AI can reliably understand, not approximately, but structurally. Otherwise, design-stage security remains bottlenecked by manual review, and the gap between development velocity and security coverage continues to widen.

We didn't benchmark architecture diagram understanding to show that Prime is better at reading images. We did it to demonstrate that understanding architecture at scale requires fundamentally different approaches, and that those approaches now exist.

Most security teams are already using AI in threat modeling and security design reviews. They just don't always say it out loud.

It starts informally. A PRD gets pasted into ChatGPT to get oriented before a review. An LLM is asked to summarize a messy Jira epic or extract data flows from a half-written document. A threat model gets sanity-checked after the fact. Not because it's "AI-driven security," but because unstructured design data practically demands it.

Threat modeling has always lived in unstructured inputs: incomplete docs, diagrams that lag reality, tickets that describe intent indirectly. LLMs are simply very good at working with this kind of material. Once teams experience that leverage, they don't go back to doing everything manually.

At that point, the question is no longer whether to use AI in threat modeling. It becomes a much more familiar one: do we build this ourselves, or do we adopt a product?

Why are security teams turning to AI for threat modeling?

The forcing function is velocity.

In many organizations, developers can go from idea to production in a day. New services, integrations, and data flows appear continuously. Meanwhile, security design reviews still assume lead time: intake, scheduling, workshops, follow-ups.

A two-week wait for a threat model is no longer a delay. It's a miss.

Security teams feel this pressure immediately. They can either accept shrinking coverage or find a way to compress design-stage feedback without sacrificing quality. That's where AI enters the picture, intentionally or not.

After speaking with hundreds of teams, a consistent pattern emerges in what works and where things break.

How do security teams start using AI for threat modeling?

The first stage is straightforward and surprisingly effective.

Teams use LLMs for one-off design reviews. Paste in a PRD. Ask for threats. Generate a diagram. Sometimes export it to Mermaid to make iteration easier. For individual reviews, this works well. It's faster than starting from a blank page and often surfaces obvious gaps.

For already-overloaded teams, this alone feels like a breakthrough.

But it doesn't scale in a durable way. Every review is isolated. Context is short-lived. Accuracy depends heavily on who is prompting and what they remember to include. Nothing accumulates.

How do you scale AI-assisted security design reviews?

The next step is almost inevitable.

Someone adds retrieval. Policies get indexed. Maybe internal standards too. A dedicated Claude or ChatGPT project appears. Sometimes a lightweight app gets built using tools like Lovable or n8n. There's an integration with Google Docs to generate threat models in place, or a Slack bot to initiate reviews.

For a while, this feels like the answer. Coverage improves. Intake friction drops. The “scale problem” looks solved. Then reality sets in.

Then reality sets in.

The system doesn't remember past decisions well. Context goes stale. Similar designs get different answers. Engineers lose trust as accuracy hovers around "pretty good," which is not good enough for security guidance. At scale, 50% accuracy is worse than none.

This is where most internal efforts stall.

Why is building AI for threat modeling so difficult?

At this stage, teams rediscover an old lesson: automated threat modeling quality is not about generating text. It's about consistent reasoning grounded in shared memory.

To move past this point, you need:

• An accurate, evolving understanding of the product and its architecture
• Durable memory of past decisions, accepted risks, and exceptions
• The ability to reason over large, messy context without hallucinating

That is hard to build. Harder to maintain. And even harder to explain to engineers when it breaks.

But there is a deeper problem that shows up even when the tooling is solid: visibility still depends on developer behavior.

Most internal systems only see work when someone remembers to ask for a review, uses the right template, or triggers the right workflow. Even with AI assistance, coverage is gated by human compliance. In high-velocity environments, that assumption does not hold. Engineers move quickly, patterns repeat, and small design changes accumulate into material risk without ever crossing a formal review boundary.

This is where many threat modeling programs quietly lose control. Not because reviews are low quality, but because security cannot see what never entered the system.

Should you build or buy AI threat modeling tools?

At that point, the buy-versus-build decision becomes unavoidable.

Building is absolutely an option. With enough time, AI expertise, and dedicated security validation, teams can assemble something that works. But it is expensive, fragile, and non-core. You need engineers who understand LLM behavior, infrastructure to manage context and memory, and security practitioners validating outputs continuously.

Everything is possible, the real question is why invest that effort just to regain visibility that should be table stakes.

The decision is not about whether AI-assisted reviews work. It's about whether rebuilding a bespoke AI security system is the best way to restore visibility across all planned work.

This is also why platforms like Prime exist. Not to "do threat modeling," but to observe design-stage change directly from systems of record like Jira and Confluence, maintain context over time, and surface risk whether or not someone explicitly asked for a review.

Why AI alone doesn't solve the threat modeling scale problem

AI didn’t change what good threat modeling requires. It made it obvious where threat modeling breaks at scale. LLMs can analyze design documents and identify threats, and they’re getting better every month. But the limiting factors aren’t analytical. They’re structural.

First, threat modeling depends on institutional memory. Without durable context about your architecture, past decisions, and accepted risk, guidance stays inconsistent and trust never compounds. Every review starts from scratch.

Second, even perfect threat models don’t help if security can’t see the work. Most risk is introduced through tickets, docs, and design changes that never cross a formal review boundary. If AI only activates when developers remember to ask, coverage collapses.

These aren’t problems you solve with better prompts or more RAG. They require persistent context and proactive visibility into planned work.

That’s the real build-versus-buy question. Not whether AI can help with threat modeling, it can, but whether rebuilding institutional memory and visibility from scratch is the best use of a security team’s finite attention when the real challenge is seeing all the design work happening in the first place.

‍

The Cyber Resilience Act (CRA) is the European Union's most significant product security regulation since GDPR. Formally adopted as Regulation (EU) 2024/2847, the CRA establishes mandatory cybersecurity requirements for all products with digital elements sold in the EU market. Non-compliance carries penalties up to €15 million or 2.5% of global annual turnover, and products that fail conformity assessment lose EU market access entirely.

Unlike previous frameworks focused on organizational security practices, the EU CRA is product-centric. Every software product must prove security throughout its lifecycle to receive CE marking, which signifies that products sold in the EEA (European Economic Area) have been assessed to meet high safety, health, and environmental protection requirements. For security leaders, this regulation formalizes a long-standing principle: security must be considered at the design phase, not retrofitted after implementation. This guide explains what the CRA requires, who it affects, and how to build compliant practices.

Executive Summary

What the EU CRA Regulates

• All products with digital elements: standalone software, IoT devices, firmware, SDKs, and connected hardware
• Applies to any organization selling to EU customers, regardless of headquarters location
• SaaS products with downloadable components (browser extensions, SDKs, agents) are in scope

Key Compliance Dates

• September 2026: Mandatory vulnerability reporting to ENISA begins
• December 2027: Full compliance with all essential requirements

Security by Design is the Essential New Mandate

• The regulation requires documented evidence that security was addressed during “design and development”
• Traditional AppSec tools (SAST, SCA, DAST) operate after code exists and cannot satisfy this requirement
• This design-stage gap is unique to CRA; other regulations (NIS2, DORA, ISO 27001) do not require it

What Organizations Must Do

• Inventory and classify all products by CRA risk tier
• Implement design-stage security review with documented evidence
• Establish vulnerability handling and ENISA reporting processes
• Generate SBOMs and technical documentation for conformity assessment

What Is the Cyber Resilience Act (CRA)?

The Cyber Resilience Act is an EU regulation setting mandatory cybersecurity requirements for all products with digital elements sold in the European market. Formally adopted as Regulation (EU) 2024/2847 and entering into force on December 10, 2024, the CRA represents the most far-reaching product security regulation the EU has enacted. It is product-centric, requiring every software product, from standalone applications to embedded firmware to SDK components, to prove security throughout its entire lifecycle, from initial design through end-of-life support.

Why Was the EU Cyber Resilience Act Introduced?

Product security failures have grown too consequential and too widespread for voluntary standards to fix. When connected devices reach hundreds of millions of households and businesses, a single architectural shortcut can cascade into infrastructure-level disruption. As shown by the October 2016 Dyn attack, attackers compromised over 600,000 IoT devices by exploiting factory-made usernames and passwords, leaving services like Twitter, Netflix, GitHub, and others unreachable for hours.

The vulnerability was not a coding error that testing would have caught but a product design decision. Although GDPR covers the handling of personal data and NIS2 covers critical infrastructure network security, neither imposes obligations on the manufacturers whose design choices created the attack surface in the first place. The CRA fills this gap by making secure-by-design a legal requirement at the point of manufacture, documented and auditable before products reach the market.

What Makes the EU CRA Different From Other Regulations?

The CRA differs from NIS2, DORA, and ISO 27001 in one key way: it regulates products, not organizations. While NIS2 requires essential service operators to implement security measures, and ISO 27001 certifies organizational security management systems, the CRA requires each individual product to meet specific security requirements and undergo conformity assessment before receiving CE marking for EU market access.

This product-level focus means compliance cannot be achieved through organizational policies alone. Each product requires documented evidence that security was considered and implemented throughout its development, starting at the design phase.

What are the Key Dates You Should Know?

The CRA follows a phased implementation timeline:

‍

‍

Why the September 2026 Deadline Matters:

While December 2027 is the full compliance deadline, September 2026 introduces mandatory vulnerability reporting. This means organizations need:

• Documented vulnerability handling processes
• Established reporting channels to ENISA
• Systems for detecting actively exploited vulnerabilities
• Evidence of ongoing security monitoring

For companies selling to EU customers, this provides an implementation window to build the practices that form the foundation of CRA compliance, including design-stage security reviews.

Penalties for Non-Compliance

The CRA establishes a tiered penalty structure based on violation severity:
‍

Beyond financial penalties, non-compliance affects:

• CE marking eligibility and EU market access
• Product availability (potential withdrawal or recall requirements)
• Customer confidence in your security practices

Which Organizations Must Comply with the CRA?

The CRA specifically calls out four classifications of software providers:

1. Manufacturers

Organizations that design, build, or brand products bear primary responsibility for CRA compliance.

This includes:

• Software publishers selling to EU customers
• Hardware manufacturers with embedded software
• Companies that white-label or rebrand products
• Organizations that substantially modify existing products

2. Importers

Entities that bring products from outside the EU into the EU market must verify compliance before distribution.

3. Distributors

Entities in the supply chain that make products available.

4. Open Source Considerations

Open source software developed outside commercial activity is generally exempt.

However:

• Commercial products using open source components must ensure those components meet CRA requirements
• Any open source integrated into commercial products becomes the manufacturer's responsibility

Does the CRA apply to companies outside the EU?

Yes. The CRA applies to any entity that places products with digital elements on the EU market, regardless of where that organization is headquartered. Non-EU manufacturers must comply with all essential requirements to receive CE marking and maintain EU market access.

Which Products Are Impacted by the CRA?

The CRA applies to products with digital elements (PDEs), defined as any software or hardware product that connects directly or indirectly to a device or network. The scope is deliberately broad to cover the interconnected nature of modern digital products.

Products in Scope:

• Standalone software applications (desktop, mobile, and web applications with downloadable components)
• Operating systems and firmware
• IoT devices and connected hardware
• Software libraries, SDKs, and APIs distributed as components
• Industrial control systems and OT equipment
• Network equipment (routers, switches, firewalls)
• Consumer electronics with data connectivity

What about SaaS Products?

Pure SaaS offerings, where no software component is downloaded or installed, are generally excluded from the CRA's scope. However, most modern SaaS products include downloadable elements that bring them into scope:

• Browser extensions or plugins
• Desktop or mobile companion apps
• Agent software for integrations
• SDKs provided to customers
• CLI tools or development utilities

If your SaaS product includes any downloadable component, that component falls under CRA requirements, and the security of that component must be proven through design-stage practices.

How does CRA Classify Products and Risk Tiers?

The CRA establishes risk categories with corresponding compliance requirements:

‍

What is required for CRA conformity assessment?

CRA conformity assessment requirements depend on product risk classification. Default (non-critical) products allow self-assessment. Important Class I products can self-assess with harmonized standards or use third-party assessment. Important Class II products require mandatory third-party assessment by notified bodies. Critical products require European cybersecurity certification.

What Are the Essential CRA Security Requirements?

The CRA's essential requirements are defined in Annex I of the regulation and are divided into two categories: security requirements for the product itself, and vulnerability handling requirements for ongoing support.

Part I: Security Requirements for Products

1. Security by Design

Products must be "designed, developed and produced" with appropriate cybersecurity levels based on risk assessment. This requires documented evidence that security was considered during architectural decisions, not added after implementation. The regulation states:

"Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks." (CRA Annex I, Section 1.1)

2. Secure Default Configuration

Products must ship with secure settings by default: least-privilege access, no default credentials, and hardened configurations aligned to intended use. Configurations that require user action to become secure do not meet this requirement.

3. Data Protection

Products must ensure confidentiality, integrity, and availability of data through appropriate mechanisms including encryption, access controls, and data minimization.

4. Resilience and Availability

Products must resist denial-of-service attacks and minimize negative impacts on other network resources.

5. Attack Surface Minimization

Products must minimize external interfaces, disable unnecessary services, and limit the impact of potential compromises through segmentation and containment.

6. Software Bill of Materials (SBOM)

Manufacturers must identify and document all software components, including dependencies, in a machine-readable format — either SPDX or CycloneDX.

Part II: Vulnerability Handling Requirements

• Establish coordinated vulnerability disclosure policies
• Document and remediate vulnerabilities without delay
• Apply effective and regular tests and reviews of product security
• Provide security updates for minimum 5 years or expected product lifetime
• Report actively exploited vulnerabilities to ENISA within 24 hours

Why Security-by-Design Is Core to the CRA Mandate?

The CRA's most consequential requirement is not SBOM generation or vulnerability scanning. It is the mandate for security by design. Article 13 requires manufacturers to "exercise due diligence when integrating components" and ensure products are "designed, developed and produced in accordance with essential requirements." The regulation specifies:

"Manufacturers should therefore ensure that all products with digital elements are designed and developed in accordance with the essential cybersecurity requirements laid down in this Regulation." (CRA (9))

What does Security-by-Design Mean Under the CRA?

Security by design under the CRA means integrating security considerations from the earliest product development phases, during architectural decisions and feature design, not retrofitting security after implementation. The regulation requires documented evidence that security was considered during design, rather than tested only after development.

"Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks." (CRA Annex I)

We continue to see an acceleration in the amount of focus that the design stage is getting from a cybersecurity risk management perspective, driven not solely by this act, but by global cybersecurity organizations and regulators alike.

The Design-Stage Gap

Most organizations have to this point invested substantially in code-level security tools:

• Static Application Security Testing (SAST) finds vulnerabilities in written code
• Software Composition Analysis (SCA) identifies risks in dependencies
• Runtime Application Security Testing (DAST) uncovers vulnerabilities in running applications

These tools serve important purposes, but they operate after code exists.

The CRA asks a different question: What security decisions were made when this feature was designed? 

When a feature moves from specification to implementation, the security-relevant decisions happen early. What data will this access? How will authentication work? What happens if this component is compromised? By the time code exists to scan, these architectural decisions are already made.

Answering the CRA's design-stage question requires security review during the design phase, with documented evidence that can satisfy conformity assessment. This creates a gap for most organizations: they have tooling for code-level security, but not for design-stage security review.

CRA Requirements vs. Traditional Tools and Other Regulations

The CRA creates new compliance obligations that existing tools and regulations do not cover:

‍

These security-by-design requirements create the primary compliance gap organizations must close.

How Does Prime Security Handle CRA Compliance?

Prime Security's Agentic Security Architect closes the design-stage gap by bringing security review to where the CRA requires it: before code is written. Prime identifies security risks in planned work and creates the documented evidence that conformity assessment requires.

Design-Stage Security Review: Prime's Approach

Prime analyzes feature specifications, architectural decisions, and integration plans as they are created, not after they are implemented. 

When a developer writes a Jira ticket describing a new feature, Prime automatically:

1. Identifies security-relevant changes that warrant review
2. Analyzes architectural implications including data flows, authentication requirements, and attack surface changes
3. Generates security recommendations specific to the proposed design
4. Creates documented evidence of security review for CRA compliance

This shifts security review to where the CRA requires it, the design phase, while ensuring consistent coverage across all development activity.

Manual security design reviews can satisfy CRA requirements in theory. In practice, they create an impossible tradeoff. The CRA demands documented security consideration for every feature across every product. Achieving full coverage manually means either hiring a security architect for every development team or slowing releases to a crawl while a small team reviews everything. Most organizations end up with partial coverage and gaps in their conformity documentation.

Prime resolves this tradeoff. By automating design-stage review, organizations achieve the continuous coverage CRA requires without blocking development. Security teams maintain oversight and make final decisions, but the baseline analysis and documentation happens automatically, at the pace of development.

‍

How Prime Helps Companies Meet Specific CRA Requirements?

Security by Design (Annex I, Part I)

The CRA requires that products "be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks." 

Prime ensures that security teams are able appropriately manage the risks of every project by making sure that features are designed securely from the beginning.

Risk Assessment (Statement 37)

The CRA also mandates that “ Manufacturers should ensure that software made available under those conditions is released only following a risk assessment and that it complies to the extent possible with the security requirements relating to the properties of products with digital elements laid down in this Regulation.”

Prime's agent assesses the risk of both new components and existing software based on the rules and regulations set out by each individual company, regardless of size or industry..

Due Diligence on Components (Article 13.5)

The regulation requires manufacturers to "exercise due diligence when integrating components sourced from third parties." 

When development plans include third-party integrations, Prime analyzes the security implications of those integrated design decisions.

Effective and Regular Testing (Annex I, Part II)

The CRA mandates that manufacturers "apply effective and regular tests and reviews of the security of the product." 

Prime fits into your existing workflows between security and engineering,  continuously reviewing development activity.

Technical Documentation (Article 31)

“The technical documentation shall contain all relevant data or details of the means used by the manufacturer to ensure that the product with digital elements and the processes put in place by the manufacturer comply with the essential cybersecurity requirements set out in Annex I.”

Prime creates persistent, auditable records of security decisions, recommendations, and reviews, producing the documentation required for conformity assessment and market surveillance.

How does EU CRA Compare to Other Cybersecurity Regulations?

CRA vs. NIS2

NIS2 (Directive 2022/2555) applies to essential and important entities operating critical infrastructure and requires organizational security measures, incident reporting, and supply chain security. The CRA applies to products regardless of who uses them.

The key differences: 

• NIS2 is entity-focused while CRA is product-focused
• NIS2 requires organizational policies while CRA requires product-level conformity
• NIS2 allows member state variation while CRA is directly applicable EU-wide

Most organizations that need to comply with NIS2 will also need to comply with CRA. A software company providing products to healthcare organizations might need NIS2 compliance as an important entity and CRA compliance for each product sold.

CRA vs. DORA

The Digital Operational Resilience Act (DORA) focuses on financial entities with requirements for ICT risk management, incident reporting, and third-party risk management. 

While DORA regulates organizational resilience, CRA focuses on product security. Financial services companies subject to DORA that also manufacture software products need CRA compliance for those products in addition to DORA compliance for their operations.

CRA vs. ISO 27001

ISO 27001 is a voluntary certification for information security management systems. The CRA is mandatory regulation with legal enforcement. ISO 27001 certification can support CRA compliance by showing mature security practices, but does not substitute for product-level conformity assessment and technical documentation.

FAQ

Does the CRA apply to my company if we're headquartered outside the EU?

Yes. The CRA applies to any organization that places products with digital elements on the EU market, regardless of where the company is based. If you sell software, hardware, or connected products to EU customers, you need to meet CRA requirements and obtain CE marking for those products.

Does the CRA apply to SaaS products?

Pure SaaS offerings with no downloadable components are generally out of scope. However, most SaaS products include elements that bring them in — browser extensions, desktop or mobile apps, agent software, SDKs provided to customers, and CLI tools all fall under CRA requirements. If any component gets installed or downloaded by the user, that component is in scope.

When does my company need to be fully CRA compliant?

Full compliance with all security requirements is due by December 11, 2027. However, mandatory vulnerability reporting to ENISA starts earlier, on September 11, 2026. That earlier deadline means you need documented vulnerability handling processes and reporting channels in place well before the full compliance date.

What is the difference between security by design and traditional AppSec testing?

Traditional AppSec tools — SAST, SCA, and DAST — find vulnerabilities in code that already exists. Security by design means making security decisions during the architectural and feature design phase, before any code is written. The CRA requires documented evidence of the latter; code-level scan reports alone do not satisfy this requirement.

What evidence do I need to pass a CRA conformity assessment?

You need documented proof that security was considered during the design phase of each product, a software bill of materials (SBOM) in a machine-readable format, records of vulnerability handling processes, and technical documentation covering how your product meets the Annex I requirements. For higher-risk product categories, third-party assessment by a notified body is also required.

Getting Started With EU CRA Compliance

The Cyber Resilience Act formalizes what security teams have long advocated: security consideration at the design phase, with documented evidence. The regulation provides clear requirements and a defined timeline to build out security by design best practices. Prime Security closes the design-stage gap by bringing automated security review to the design phase, creating the documented evidence that conformity assessment requires while helping your security architects focus on the strategic decisions that need human judgment.

Ready to Explore Design-Stage Security Review?

Request a Demo to see how Prime Security automates CRA-compliant security design reviews across your development organization.

‍

Get Your Copy:

The Cyber Resilience Act (CRA) Cheatsheet

Download

Today, I’m proud to share that Prime Security has raised a $20 million Series A, led by Scale Venture Partners, with continued support from Foundation Capital and Flybridge Ventures.When Dima, Matan, Danny, and I started Prime almost two years ago, our hypothesis was simple: Security isn’t keeping up with development. Despite endless tools, day-to-day security engineering and architecture work still feels manual, fragmented, and slow. 

We experienced this problem first-hand. Dima’s previous security teams at PayPal were always playing catch-up, while Matan, Danny, and I were delaying releases at Own because of last-minute security requirements. Even two years ago, this was a huge problem.

What we didn’t expect was just how fast development itself would evolve. Everyone became an engineer. AI-powered coding tools exploded. Velocity went through the roof, and the bottleneck for security? It got 5× worse.

We are building Prime to change that.

The AI Security Architect - the Super-Tool Product Security Always Needed

LLMs changed everything. But we didn’t see them as a replacement for security engineers; we saw them as a way to scale their judgment.

From day one, our vision has been to democratize security knowledge across every development team, to make security as embedded and accessible as code review.

That’s what Prime is building: an AI Security Architect - the super-tool security teams have always needed. An agentic system that autonomously reviews design work, identifies risks, and recommends mitigations, before a single line of code is written.

With Prime, security teams can finally cover all development work, not just the 5–10 percent they can manually review today. The result? Teams eliminate review backlogs, accelerate development and save millions in process costs, sometimes tens of millions annually, all while actually improving security outcomes.

It’s not reactive security. It’s preemptive security, where risks are understood and resolved at the design stage, long before they ever become incidents.

We’ve been lucky to work with some incredible early partners - PayPal, Qualtrics, ThoughtSpot, Bumble, Yext, Redis Labs, and many others who believed in our vision early on.

Together, we proved our hypothesis: Product Security teams require tooling that lets them move at the speed of modern development, without compromising on risk visibility.

It’s not about scanning code faster. It’s about thinking about security earlier, when architecture, design, and product decisions are being made.

We started by focusing on the design stage of the product development lifecycle, but that is just the beginning. The challenges of securing modern development don’t end there. They start there.

This Series A funding gives us the resources to go deeper, expand our agentic AI capabilities, and grow our teams across the U.S. and Israel, all with the goal of leading the next era of product security.

We believe security shouldn’t slow you down. It should help you move faster confidently.

That’s what Prime is here to do.

— Michael Nov, Co-Founder & CEO, Prime Security

‍

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 

‍

EVERY SINGLE COMPANY I speak to has adopted or is adopting AI code generation tools. Cursor’s ARR numbers don’t lie. Some companies are pretending they haven’t, calling it “just a pilot” or “a few devs experimenting.” Others are leaning all the way in because they have to. Dev teams are demanding speed. Leadership wants productivity gains. And honestly? These tools are good. Too good to ignore.

But here’s the thing: AI-powered development is already here. It’s loud. It’s fast. And it’s not waiting around for security sign-off. The train has left the station. Security’s still checking the schedule. Google says 25% of their code is now written by AI. If they got there that fast, your org’s not far behind. This isn’t hype. It’s happening.

Let’s not kid ourselves, most developers aren’t generating full-blown apps (yet), especially at mid-sized and larger companies. For now, it’s autocomplete. Maybe a helper function here and there. Seems safe. Harmless.

But we’ve seen this progression before. Autocomplete becomes “generate block.” “Generate block” becomes “why not ship it?” And suddenly, you’ve got AI-assisted infrastructure changes cruising toward production. There’s a Jira ticket. There’s some plan. But no one’s waiting for a security review. The specs are thin, the pace is insane, and the review process? Skipped, sidelined, or rubber-stamped. Just enough structure to ship, nowhere near enough to secure.

And here’s what makes it even scarier: a lot of these changes aren’t greenfield. They’re not new apps. They’re small adjustments to complex, fragile, existing systems. A new flow here. A helper function there. A tiny tweak that seems low-risk, until it breaks something critical or quietly bypasses security controls that were never meant to be touched. And the tools? They simply lack the context to catch it.

We’ve already seen horror stories play out with vibe coders pushing insecure features into production. And we’ve heard of plenty more quietly handled inside enterprises, breaches averted by luck, late-night heroics, or pure chance. This isn’t theoretical. It’s already happening.

So where does that leave Product Security?

Let me be crystal clear: these tools don’t know your threat models. They don’t care about your asset inventory. They sure as hell don’t know your compliance requirements. They don’t know that your legacy billing service is basically a haunted house held together by duct tape, broken dreams, and a regex pattern no one understands.

And now the window between “I had an idea” and “it’s in production” is… what, a couple hours? What used to be design reviews, architecture sessions, a few spicy Slack threads, that’s all gone. It’s now: prompt, pull request, CR, merge. Done.

Manual product security processes? Dead on arrival. If your team still relies on humans to dig through design docs and flag every potential risk before a line of code is written, you’re already underwater. Best case, you slow things down and become that team. Worst case, you get quietly pushed out of the process entirely.

Some companies are trying to solve this by plugging static security rules into their AI dev tools, like that’s going to stop the bleeding. But rules without context don’t make things more secure. They just make the code more bloated. You end up with unnecessary security controls shoved into places they don’t belong, confusing developers and cluttering the codebase. The devs don’t argue. They just ship it and move on. Congrats, you’ve added security theater to the build pipeline. A silent overkill.

But let’s not confuse fixing bugs after the fact with building secure systems in the first place.

None of these tools are going to raise a flag when your architecture is fundamentally broken. They won’t catch it when a new feature opens up a nasty compliance gap. They won’t stop a dev from shipping an unauthenticated admin panel to production because the AI said, “looks good to me.”

They weren’t built for that. And that’s the real problem.

Security teams are staring at a widening gap, and most are still trying to patch it with manual reviews, tribal knowledge, and wishful thinking. But as the pace of development accelerates, absurdly accelerates, those old methods just don’t scale. They’re already cracking under pressure.

The opportunity? Massive. AI-powered development has created an entirely new class of problems, ones the existing security stack was never built to solve. Securing applications  generated at the speed of a prompt requires a new approach, a new mindset, and yes, new tools. Entire categories of security tooling will need to be rebuilt for this world. This isn’t a “feature gap.” It’s a market gap.

So where do we go from here?

Security thinking has to shift upstream. It needs to be seamlessly embedded into planning, not patched onto delivery. It has to evolve from reactive reviews to proactive visibility. It needs to move with the development process, not try to slow it down from the sidelines.

This isn’t about waving red flags after the build pipeline’s already green. This is about being in the room when the feature is defined, before a single prompt is typed into the AI tool.

Because the future isn’t coming. It’s already writing itself.

And if security doesn’t learn to speak that language, to exist inside that flow, it won’t just be left behind. It’ll be ignored completely.