Mave Series A Raises $28 Million for AI Investigations Across Existing Security Tools

Mave raised a $28 million Series A to automate security investigations without requiring enterprises to centralize their security data first. Announced October 22, the Mave Series A backs a specific architectural bet: software can connect evidence across existing tools while people retain control over consequential responses. The funding brings its total raised to $34 million.

The tension sits between gathering information and reaching a defensible decision. An organization can own capable security products and still depend on analysts to reconcile conflicting findings. Mave proposes automating that connecting work, which puts its product between the systems that report suspicious activity and the people accountable for acting.

Competitors such as Dropzone AI already pursue automated investigations, so Mave enters an established contest for security teams’ trust. Its opportunity rests on making fragmented tools work together. The important questions concern investigation quality, operational permissions, and whether automation reduces work after human review enters the calculation.

What the Mave Series A actually funds

The investment supports an investigation layer across existing systems, with enterprise expansion alongside technical development.

Red Dot Capital Partners led the round, with Lumir Growth Partners participating. An earlier $6 million seed round was led by Dell Technologies Capital and Emerge Ventures. CTech’s reporting on the security investigation funding identifies AI research, enterprise products, and international expansion as planned uses of the capital.

The distinction between the new round and total funding matters. Mave announced $34 million in cumulative financing, rather than a Series A of that size. The announcement establishes investor backing and spending priorities. It does not establish how the product performs against competing approaches under comparable conditions.

Mave was founded in 2025 by CEO Raziel Oren and CTO Guy Eshel. That places the company early in its operating history, even as it targets demanding enterprise environments. Funding provides resources for development and distribution, while customers still need evidence that the system fits their particular security operations.

The Mave Series A also supports work that sits outside model development. Enterprise deployment requires reliable connections, permission management, documentation, support, and predictable behavior when an underlying tool changes. Those responsibilities matter because an investigation product inherits dependencies from every system it touches.

A compelling demonstration can show software assembling a coherent account of suspicious activity. A durable deployment must keep producing useful results after access policies change, tools undergo upgrades, and organizations restructure. Investors fund the capacity to address those problems, but the financing announcement cannot show that they are solved.

There is a commercial implication as well. A product that works across existing systems potentially lets buyers test automation without committing to a broader infrastructure replacement. That makes the initial proposition easier to evaluate, although the actual deployment burden depends on the integrations and controls each organization needs.

The strongest interpretation of the round is therefore specific. Investors are backing an attempt to automate the investigative work between security products. That creates pressure on vendors to explain where their automation begins, what dependencies it introduces, and how customers can verify the resulting decisions.

It also gives Mave room to pursue technical and commercial development together. Expanding sales before deployment becomes repeatable can stretch support resources. Concentrating exclusively on research can leave an effective product difficult to adopt. The announced spending priorities reflect both sides of building an enterprise security business.

Security leaders face a coordination problem

Mave’s pitch puts pressure on the manual work connecting security tools, rather than on any single source of alerts.

A security operations center, or SOC, is the team and operating function responsible for monitoring threats and coordinating investigations. Its work involves more than reading warnings. Analysts must determine which evidence belongs together, whether an event is suspicious, and what response the business can tolerate.

Consider an illustrative investigation involving a suspicious employee login. An identity system can show authentication activity, while an endpoint product records behavior on the employee’s device. An asset inventory might identify the device’s owner. The analyst needs those observations to form a judgment about the same event.

This example is hypothetical, rather than a disclosed Mave customer incident. It illustrates why collecting an alert does not automatically resolve an investigation. Each observation answers a different question, and the relationship between those answers determines whether the event deserves escalation.

A security information and event management system, or SIEM, collects and analyzes security events in a central platform. Central collection helps establish history and search across records. However, a buyer still needs to assess whether the investigation includes relevant context outside that platform.

The pressure falls first on security leaders who must explain both missed threats and operational disruption. Faster processing is attractive, but a decision to disable access can interrupt legitimate work. An automated investigation needs to support the judgment behind that action, rather than simply deliver its recommendation sooner.

Analysts face a related change in responsibility. If software gathers evidence, their attention shifts toward checking unresolved assumptions and handling exceptions. That shift creates value only when reviewing the output requires less effort than reconstructing the investigation manually.

Managed security service providers, or MSSPs, operate security services for other organizations. For them, investigation automation raises questions about consistency across customer environments. An approach that works well for a standardized environment needs further evaluation when customers use different products and access policies.

This creates an immediate buying question: which part of the work does the product actually remove? Retrieving records, identifying relationships, recommending actions, and executing responses are separate capabilities. Combining them in a sales presentation should not obscure their different consequences in production.

The longer-term pressure reaches security platform vendors. If an independent investigation layer becomes useful, customers have another way to coordinate their existing products. Established vendors then need to demonstrate why their own connected workflows offer better evidence, simpler administration, or clearer accountability.

That outcome remains conditional on adoption. Mave’s financing does not show that customers will shift budgets or replace existing processes. It gives the company resources to argue that coordination deserves its own product layer, with measurable benefits beyond an additional interface.

Investigating in place changes the dependencies

Avoiding a new central repository shifts the integration challenge toward live access, consistent interpretation, and reproducible evidence.

Mave describes a system that queries connected tools, gathers current context, and adapts its investigation as evidence emerges. Its stated approach avoids requiring a new centralized telemetry database. Telemetry means the activity records that systems produce about their operation.

The company’s announcement on agentic security operations describes agents that investigate and perform authorized tasks across existing systems. Here, agents are software components that pursue tasks through connected tools. These capabilities remain company claims, rather than independently established comparative results.

Working where information already resides creates an appealing proposition. Buyers can assess whether the investigation layer accesses useful context without rebuilding the entire collection process. The architectural question shifts from where all records should live toward which evidence the system can retrieve when needed.

That shift creates dependencies worth examining. If a connected tool becomes unavailable, an investigation needs to distinguish an incomplete search from an absence of suspicious activity. Otherwise, a missing answer risks becoming an unjustified conclusion.

The same issue applies to permissions. Limited access can be appropriate for security reasons, but it narrows what the system can establish. An investigation should make that boundary visible so reviewers understand which questions remain unanswered.

Time adds another complication. Current information can help explain an active incident, while historical records help reconstruct what happened earlier. Buyers should assess how the product relates observations collected at different times, especially when account status or device configuration changes during an investigation.

An audit trail, meaning a retained record of investigative steps and evidence, helps reviewers examine that relationship. Mave says it records queries, evidence, reasoning, and actions. The practical question is whether those records let a reviewer test the conclusion without repeating the entire workflow.

For example, a recommendation should be distinguishable from the observation supporting it. A record that access was revoked is different from evidence that the account was compromised. Keeping those elements separate helps reviewers identify whether a disagreement concerns the facts, their interpretation, or the response policy.

This is an evaluation criterion, rather than a claim about a demonstrated Mave limitation. The architecture makes such questions especially relevant because the investigation depends on several connected systems. Reliability must cover the connections and their interpretation, alongside the language model.

Avoiding centralization also does not eliminate data governance questions. A buyer still needs clarity about which information is retrieved, where processing occurs, and what investigation records are retained. Those details determine whether the design fits the organization’s obligations.

The architectural tradeoff is consequently more precise than a choice between old databases and new AI. Central collection and live investigation address overlapping needs. Mave’s opportunity lies in showing that its approach improves decisions across an existing environment while making the remaining gaps inspectable.

Rivals make investigation quality the comparison

Automated investigation is already a competitive category, so Mave needs differentiation that buyers can observe in their own environments.

Dropzone AI provides a useful reference point. GeekWire’s coverage of its AI SOC analysts describes software intended to investigate alerts and escalate incidents requiring human attention. That establishes overlapping product ambitions, rather than evidence that either company performs better.

The comparison matters because an enterprise buyer can evaluate several approaches to similar work. A broad promise to reduce repetitive investigations does not identify the conditions under which one system deserves preference. Integration coverage, evidence quality, and operational fit become central to that decision.

Mave’s emphasis on investigating across existing systems gives it a concrete position. However, a position becomes differentiation only when the implementation produces an advantage. Buyers need to see whether the product handles their particular combinations of tools, incomplete records, and unusual workflows.

Competitor claims also deserve the same attribution discipline applied to Mave. Dropzone CEO Edward Wu told CRN that its product delivers investigations without human labor performing the underlying service. He separately described an internal human quality-control function reviewing completed work.

CRN’s discussion of software-only investigations highlights a useful distinction between delivering a service and checking its quality. It is Wu’s account of his company’s approach. It does not establish how Mave staffs its own operations.

For buyers, that distinction opens a broader question about what automation means operationally. A product can automate evidence retrieval while people complete difficult reasoning. Another can automate the investigation while requiring extensive customer review. Both arrangements need clear disclosure before customers compare their results.

The same caution applies to speed claims. A quick verdict has limited meaning without understanding the investigation’s scope. If a system checks fewer relevant sources, a shorter completion time does not necessarily indicate better work.

Comparisons should also account for unresolved cases. A product that clearly identifies uncertainty can be more useful than one producing a confident answer without adequate evidence. Evaluating only completed investigations would miss that difference.

These considerations keep the competitive frame grounded. Mave and Dropzone need not follow identical architectures to compete for the same operational responsibility. The relevant contest concerns which approach helps a security team reach defensible decisions with less total effort.

This also explains why existing workflows remain an important reference. A new product must improve on what customers already do, including the human review it introduces. Funding and demonstrations help companies enter that conversation; deployment results determine whether they stay in it.

The Mave Series A gives the company resources to compete on those terms. It does not justify calling the company a category leader or assuming its architecture produces superior outcomes. Those judgments require comparable evidence that the financing itself does not provide.

Traceability helps, but does not establish correctness

A readable investigation record supports accountability, while the underlying conclusion still needs independent scrutiny.

Mave says it is operating in more than 200 SOCs and allows teams to govern automatic execution and human approvals. Those statements describe reported deployment and intended control. They do not provide a common measure of investigation accuracy or show how extensively each deployment uses the product.

A deployment count can refer to organizations with very different operating arrangements. A limited rollout and a broadly adopted workflow represent different levels of reliance. Without that context, the number establishes reported reach more clearly than it establishes operational depth.

The technical uncertainty extends beyond deployment labels. The National Institute of Standards and Technology identifies confabulation, meaning confidently generated false content, as a generative AI risk. Its generative AI risks profile also warns that generated explanations can mislead people into trusting incorrect outputs.

That guidance is a general risk framework, rather than an assessment of Mave. Its relevance concerns how buyers interpret an AI-generated investigation. An explanation that sounds coherent needs supporting observations, especially when the proposed response affects access or system availability.

Traceability addresses part of this problem. Reviewers can inspect what the software checked and compare the finding against the evidence. However, a record of steps cannot establish that every necessary question was asked or that each observation received the right interpretation.

Approval controls address a different problem. They determine who can authorize an action, but their value depends on what the reviewer receives. If the supporting evidence is unclear, a human approval step can become an administrative gesture instead of a meaningful check.

A useful assessment therefore examines how the product communicates uncertainty. Missing information, contradictory observations, and ambiguous identities should remain visible. The buyer needs to know whether the system pauses, requests more context, or presents a bounded finding.

Permissions require similar scrutiny. The authority to read records differs from the authority to isolate a device or disable an account. Customers should understand how those responsibilities are separated and how exceptions affect an ongoing investigation.

None of these questions establishes a defect in Mave’s product. They identify the evidence needed to evaluate its intended role. The more consequential the permitted action, the stronger the case for examining the entire path from observation through authorization.

There is also a practical knowledge problem after the investigation ends. Teams need to preserve decisions, exceptions, and explanations that inform future reviews. A searchable knowledge base supports that documentation work, while security controls govern operational access and response.

The central uncertainty is whether automation saves effort after those responsibilities are included. A system that produces more findings can still leave analysts with substantial verification work. Demonstrating useful automation requires showing how much dependable investigative work reaches completion.

Watch customer evidence, operating boundaries, and repeat adoption

The next useful signals concern demonstrated outcomes, disclosed controls, and whether customers expand their reliance on the product.

Over the next several months, the first signal to watch is detailed customer evidence. A useful account would explain the operating environment, investigation scope, previous workflow, and remaining human involvement. Named examples would make the claims easier to assess than an aggregate deployment count alone.

The strongest evidence would include difficult cases alongside routine successes. Reviewers need to understand what the software handled, where it needed assistance, and how the team recognized those boundaries. A carefully scoped result can be more informative than a broad claim about investigating every alert.

Such disclosures would strengthen the argument that Mave’s architecture creates practical value across existing systems. Evidence of substantial reconstruction or repeated manual correction would narrow that argument. The distinction concerns how much dependable work the system completes, rather than whether it can produce an investigation narrative.

The second signal is greater detail about operating boundaries. Buyers should watch for documentation explaining permissions, unavailable connections, retained evidence, and approval behavior. Those details would make it easier to evaluate how the platform behaves outside a successful demonstration.

Clear boundaries would support Mave’s position because enterprise teams need predictable behavior under imperfect conditions. Vague descriptions would leave the integration burden difficult to assess. This signal concerns disclosed behavior, rather than a particular feature release that the company has promised.

The third signal is repeat adoption. Evidence that customers renew, expand investigation coverage, or entrust additional approved workflows would show increasing operational reliance. The relevant question is what changed in actual use, alongside any growth in the number of deployments.

Expansion should still receive careful interpretation. Additional access can reflect confidence, but buyers need to know which responsibilities remain with people. A fuller picture would connect increased use with review effort, escalation quality, and the handling of exceptions.

These signals follow a logical order. Customer evidence establishes usefulness, operating detail establishes how that usefulness holds up, and repeat adoption indicates whether the arrangement remains valuable. None requires predicting that Mave will displace established platforms or outperform every rival.

For security leaders following the Mave Series A, start with the workflow your team finds hardest to complete reliably. Identify where evidence lives, which judgments require human accountability, and how much review an automated finding would demand. Then compare vendor claims against that operational picture. Ask for completed investigations that expose uncertainty, including cases where the system stopped or escalated. Examine whether the record supports the proposed response and whether another analyst can follow it. The useful next step is to seek evidence that answers those questions. Which part of your investigation process would you trust software to complete, and what would you need to see before extending that trust?