AI News

Fleuret AI Raises €4 Million to Bring Continuous Security Testing to European Businesses

A French Startup Wants Security Checks to Keep Up

Software changes quickly. Security assessments do not always move at the same speed.

A company can complete a penetration test, fix the problems, and introduce another weakness with its next update. Yesterday’s reassuring report may still be accurate about yesterday. Today is a different question.

French startup Fleuret AI wants to narrow that gap.

On October 5, the Paris-based company announced a €4 million pre-seed funding round led by RAISE Ventures, with participation from Auriga Cyber Ventures, Wind Capital, Better Angle, and cybersecurity business angels. The funding will support recruitment and product development.

Its pitch centres on AI agents that help organisations test their systems more frequently and verify whether discovered weaknesses are exploitable.

The ambition is practical: make security testing part of ongoing operations.

Because software rarely waits politely for the next scheduled audit before changing.

The Problem With a Security Snapshot

A penetration test examines an agreed set of systems for weaknesses that an attacker might exploit.

The work can provide valuable evidence. But its findings relate to the environment tested at that time.

As Tech.eu’s funding report explains, Fleuret targets the mismatch between continually evolving information systems and assessments performed as occasional audits. A deployment after testing can change the exposed environment.

Consider a hypothetical business launching a new customer portal.

Its previous assessment might have covered the existing website thoroughly. The new portal introduces different functions, permissions, and connections.

That does not make the earlier assessment useless. It means the business now has additional questions to investigate.

Fleuret’s opportunity sits in that interval.

If teams can repeat meaningful tests more easily after changes, they could gain a fresher understanding of their exposure—and act while the relevant engineering work is still recent.

The Founders Have Worked in Pentesting Before

Fleuret’s co-founders are Yanis Grigy, CEO, and Augustin Ponsin, CTO.

The company says they have known each other since childhood and previously founded a business specialising in penetration testing. Their experience helped them identify the gap between changing systems and infrequent assessments.

Télécom Paris’ coverage adds an entrepreneurial angle. Grigy describes how the school’s technical community and incubator helped the earlier project develop and connect with initial customers.

That background gives the startup a relevant starting point.

Building security software requires understanding how findings become useful work for customers. A technically interesting discovery still needs evidence, context, and a clear route towards resolution.

The commercial challenge is equally concrete.

Customers must trust the product enough to let it examine important systems. Previous experience can help open that conversation, but the platform’s actual performance will determine whether the relationship lasts.

Meet Emile and Champollion

Fleuret’s funding announcement names two AI agents: Emile and Champollion.

The company describes them as mapping customer environments, exploring applications and infrastructure, and attempting to validate discovered vulnerabilities.

Its platform page provides a more detailed architectural picture. Émile supervises an engagement and coordinates specialist agents, while a separate validation component checks findings before reporting them. These are the company’s descriptions of its system.

For a general reader, an AI agent here means software assigned to perform steps towards a testing objective.

The interesting part is how those steps connect.

Mapping an application, examining a suspected weakness, and producing evidence are different tasks. Coordinating them could make the result more useful than an isolated warning.

However, giving an agent a memorable name does not establish its capabilities.

Emile still needs to earn his place on the team. Preferably without asking for an office with a window.

Evidence Is the Centre of the Pitch

Fleuret emphasises reproducible proof of concept: evidence intended to show that a reported weakness can actually be exploited.

Its platform documentation says findings pass through controlled validation before entering the report.

The practical distinction is between a suspicion and a demonstrated problem.

Imagine a hypothetical team receiving an alert about inappropriate access to customer information. Developers need to understand whether the behaviour occurs, under which conditions, and what boundary has failed.

Clear evidence can help answer those questions.

It can also make discussion more productive. Instead of debating an abstract warning, the team can examine a documented result.

Still, proof has limits.

Showing one weakness exists does not demonstrate that every other part of an application is secure. Nor does a clean report establish that the testing covered every possible issue.

Evidence strengthens a finding. It does not turn a finite assessment into a universal guarantee.

Discovery Is Only the First Step

Finding a vulnerability matters. Getting it resolved matters more.

Tech.eu reports that Fleuret is developing support for prioritisation, integration with engineering tools, automated retesting, and reporting that shows whether identified problems have been fixed.

That connects the testing product to everyday engineering work.

A useful finding needs an owner. It needs enough context for someone to investigate. It needs a status that does not disappear inside an email thread.

Without those connections, even a good assessment can become a document everyone intends to revisit.

Later.

After the release.

After the next release.

The business implication is straightforward: Fleuret’s value could depend as much on helping teams complete the repair process as on discovering weaknesses.

For customers, a shorter path from evidence to action would be meaningful.

A beautifully formatted report is welcome. A confirmed fix is considerably better news for the people responsible for the system.

Retesting Closes an Important Loop

Fleuret AI penetration testing

A developer can change the code and believe a problem is fixed.

Retesting asks whether the relevant weakness remains.

Fleuret’s FAQ says its one-off penetration test includes a retest after customers release their fixes, with findings updated to reflect the new status.

Consider a hypothetical access-control issue.

A team adjusts a permission check and closes its internal ticket. Repeating the relevant assessment could reveal whether the change addressed the original behaviour.

It might confirm success. It might show that more work is needed.

Either outcome provides useful information.

As an analytical point, making retesting easier could reduce the distance between an engineering team’s intention and verified results. That matters particularly when several people handle different stages of a repair.

The strongest workflow would preserve the original evidence, document the change, and record the follow-up result.

A ticket marked “done” is a statement. A successful retest gives that statement supporting evidence.

Continuous Testing Needs a Clear Definition

“Continuous security” sounds reassuring. Its meaning needs careful explanation.

Fleuret’s ambition is to monitor changes and enable further testing as systems evolve. Its commercial website also describes penetration tests that customers can launch on demand.

Those ideas can complement each other, but they are not identical.

Monitoring an environment, scheduling assessments, and checking a repair each answer different questions.

A hypothetical business might continuously observe exposed systems while running deeper tests after significant releases. Another might commission individual assessments when needed.

Both could benefit from automation. Their testing frequency and coverage would differ.

For buyers, the useful question is what happens in their particular deployment.

Which changes trigger attention? When does deeper testing occur? What requires a customer’s decision?

Clear answers would make the promise easier to evaluate.

Security improves through specific, repeatable activities. The word “continuous” becomes meaningful when customers can see which activities actually continue.

The Pricing Pitch Is About Accessibility

On its website, Fleuret advertises a €4,000 penetration test per web application and compares that with higher consulting fees. It also promotes delivery in hours. These are the company’s commercial claims, rather than independently established market benchmarks.

The proposed advantage is easier access to testing.

If an assessment requires less money and coordination, a business may find it more practical to repeat.

But price comparisons depend on what each engagement includes.

Scope, specialist involvement, reporting, follow-up, and the complexity of the environment can change the value of an offer. A headline price cannot settle those differences.

The sensible comparison is therefore between defined services.

As an analytical possibility, automation could make more frequent testing achievable for some organisations. Demonstrating comparable depth on relevant customer tasks would strengthen that case.

Cheaper testing is attractive. Useful, repeatable testing is the actual product customers need.

Early Customers Give the Announcement Substance

Fleuret’s funding announcement names Brevo, Stoïk, and Yogosha among its customers and describes a team of around ten people.

That gives the story more substance than an idea accompanied by a fundraising headline.

However, customer names alone leave important questions unanswered.

The announcement does not provide detailed revenue figures, retention data, or independent comparisons of testing performance. It also does not establish the size of each relationship.

Early adoption supports a picture of commercial activity. It does not demonstrate comprehensive maturity.

For a young security company, the next evidence could include customers returning for further engagements, broader use within organisations, and clear accounts of how findings helped engineering teams.

Those are analytical measures, not results disclosed in the announcement.

The funding provides resources to pursue that progress.

The product still needs to show that it can deliver reliably across different environments, rather than succeeding only in a carefully chosen demonstration.

Why European Hosting Is Part of the Story

Fleuret positions itself as a European security provider.

Its security policy says production data is hosted within the European Union. It describes encryption, restricted access, client data isolation, and retention arrangements for testing evidence and reports. These are the company’s stated practices. (Fleuret)

For this kind of service, information handling belongs in the product discussion.

A testing provider may receive details about systems, weaknesses, and evidence collected during an engagement. Customers need to understand how that material is protected and who can access it.

Geography supplies one part of the answer.

Operational controls, contractual terms, retention, and access management supply other parts.

European hosting does not establish testing accuracy. Likewise, accurate findings do not answer every question about data protection.

A buyer must evaluate both.

Fleuret’s positioning could appeal to organisations seeking a European supplier, but trust will depend on the supporting details rather than the location label alone.

The Roadmap Has Boundaries

The company’s own FAQ distinguishes current coverage from planned expansion.

It lists web applications, REST and GraphQL APIs, and external infrastructure as available testing areas. Active Directory, mobile applications, and cloud penetration tests appear on the roadmap.

That distinction matters because the broader ambition could otherwise sound more comprehensive than the present offering.

Télécom Paris’ interview also describes funding for additional coverage and the surrounding remediation workflow.

Expanding coverage involves more than adding categories to a sales page.

Different environments present different access arrangements, operational constraints, and expectations. A product needs appropriate methods and evidence for the areas it claims to assess.

For customers, clear limits are useful information.

They help establish whether the platform matches an immediate need and where other testing remains necessary.

A credible roadmap shows direction. A credible current offering explains what users can depend on today.

Keeping those two descriptions distinct makes the expansion story easier to judge.

Human Expertise Remains Part of the Work

Fleuret’s FAQ describes an approach combining AI agents with human offensive-security expertise.

That leaves room for automation to handle repeated tasks while specialists contribute judgment.

Independent of Fleuret, the OWASP Web Security Testing Guide provides an established resource for web application testing. Its existence underlines that security assessment involves organised methods and technical knowledge, beyond producing a list of alerts.

For an AI testing product, the analytical challenge is deciding where automated results are sufficient and where expert attention adds value.

A discovered behaviour may require business context. An unusual application may need closer interpretation. Customers may also need help understanding the practical consequences of a finding.

Automation could free specialists to concentrate on those questions.

That would make the combination valuable through better allocation of effort.

The goal should be a clearer assessment and a more effective repair process, with expertise applied where it helps most.

What Would Make This €4 Million Matter?

Fleuret AI penetration testing

Fleuret’s funding gives a young company resources to develop its platform and pursue wider adoption.

The larger outcome remains to be demonstrated.

Useful measures would include reproducible findings, clear coverage, dependable operation, successful retesting, and customers choosing to use the product again. Independent evaluations would also help readers distinguish product claims from demonstrated performance.

Those are analytical yardsticks for the next stage.

The promising idea is that security testing could move closer to the rhythm of software development. Teams would gain more opportunities to examine changes and confirm repairs before uncertainty accumulates.

Achieving that requires more than fast agents.

It requires useful evidence, clear boundaries, and workflows people can trust under everyday conditions.

Fleuret now has fresh capital to work on those requirements.

If it delivers, the important result will reach beyond another AI funding headline: more businesses could make meaningful security testing a routine habit, rather than an appointment they keep postponing.

Sources