Clover Security is a design-led product security platform that puts AI agents into the tools where software is designed and built. Rather than scanning finished code, its agents work at design time — a different shape from the scanner-aggregation ASPM tools it sits alongside.
The company launched in November 2025 with $36M co-led by Notable Capital and Team8, with SVCI, the Wiz founders, and Shlomo Kramer participating, and later a strategic investment from ServiceNow. It was founded by CEO Alon Kollmann and CPO Or Chen.
What is Clover Security?
Clover’s argument is that reactive scanning cannot keep pace with AI-assisted development. When AI agents generate whole features in seconds, finding issues after implementation lands too late.
So Clover moves upstream. Its agents understand architecture, intent, and system behavior before code exists, bringing security into the design conversation instead of the post-mortem.
The agents start like a new team member: learning the organization’s context from existing documents and codebases, then extending manual work like design reviews, architecture reviews, and threat modeling.
Key capabilities
Clover packages its platform as a set of context-aware agents. Each one takes over a slice of product security work that used to be manual.
| Agent | What it does |
|---|---|
| Discovery | Surfaces critical changes and blind spots, and prioritizes risky features |
| Design review | Automates security review of designs and architecture |
| Security policy | Applies organizational policies inside developer workflows |
| Threat modeling | Generates continuous application- and code-level threat models |
| Developer guidance | Guides builders on secure decisions in their workflow |
| Governance | Tracks secure-design posture, standards adherence, and maturity |
| MCP | Gives visibility into AI-generated code and secures MCPs |
| Vibe coding | Checks vibe-coding and shadow AI for misconfigurations and missing controls |
Design-time threat modeling
The threat modeling agent auto-generates application- and code-level threat models from your existing codebase, diagrams, and documents. That reframes threat modeling from a one-off workshop into something continuous.
Design-to-implementation drift
Clover also watches for drift between the intended design and what actually ships. A secure design only holds if the code matches it, and the drift check is where design-time review meets the codebase.
Securing AI-assisted development
Two agents target the AI-native SDLC directly. The MCP agent enforces policies on coding agents and secures MCPs, while the vibe coding agent flags excessive permissions and missing controls in AI-assisted work.
Where it fits and how it compares
Clover sits in the ASPM neighborhood as an application security program platform, but it works differently by design. It does not deduplicate scanner findings; it works before those findings would exist.
That makes the comparison less about feature parity and more about philosophy. Phoenix Security and Jit route and remediate findings after scanners run, while Clover tries to eliminate whole classes of issues in the design phase.
The team’s background sits behind that bet. Clover’s founders and staff previously built security products at Microsoft, Checkmarx, and Dazz (acquired by Wiz), and cite that decade of reactive-tooling experience as the reason for the design-first approach.
Clover does not publish pricing and routes prospects through a demo request. For scanner-aggregation and remediation platforms in the same category, browse the full ASPM tools catalog on AppSec Santa.
How does Clover fit into a delivery workflow?
Clover’s design-review workflow builds context from documents, tickets, and pull requests. It then generates threats and requirements before checking whether the implementation matches them.
The natural insertion point is a meaningful product change, not every commit. Discovery identifies changes that need review, while design and threat-modeling agents prepare the security work around them.
A focused rollout can follow four steps:
- Connect one product’s design documents, tickets, and repositories.
- Define the policies that should become review requirements.
- Compare generated reviews with recent reviews completed by the security team.
- Enable code verification after the team trusts the design-stage output.
This keeps human approval in place while testing whether Clover understands business logic and organizational policy. It also exposes missing context before agents turn it into a confident recommendation.
How is Clover deployed and evaluated?
The platform page describes context-aware agents and eight product-security roles. It does not publish a self-hosted package, public API reference, versioned release notes, or supported-connector matrix.
Clover is evaluated through a demo request . The public site lists no pricing or self-service trial, so procurement includes a vendor-led technical evaluation.
For coding agents, Clover’s Kura announcement says security context is selected per task. Buyers should verify which coding assistants and repository controls are supported in their environment.
What are Clover Security’s limitations?
Clover’s platform description covers design reviews, threat models, guidance, and drift checks rather than source-code vulnerability scanning or scanner aggregation.
That design-first scope leaves other jobs to existing controls. Dependency vulnerabilities, internet-facing behavior, runtime exposure, and exploit validation still need SCA, DAST, runtime telemetry, or manual testing.
The quality of a review depends on the context Clover can read. Sparse tickets, outdated diagrams, and undocumented business rules can produce incomplete requirements even when the agent follows its workflow correctly.
Public technical detail remains limited. I would require a connector walkthrough, data-flow review, permission model, retention policy, and a measured comparison with recent human reviews before a broad rollout.
Policy maintenance is another cost. Requirements derived from outdated standards or architecture assumptions can be applied consistently and still be wrong.
Someone must own the source policies, exceptions, and review feedback that shape future agent decisions.