● B2B offer — Cybersecurity & monitoring
Cybersecurity: alerts qualified, events correlated
A security team receives more alerts than it can look into in detail. Your agent, connected to your SIEM, correlates the events, qualifies each alert against your detection rules and documents the signal with the chain of events it rests on. Hosted in France: your technical logs and your infrastructure map stay with you. Any remediation belongs to your security team.
Hosted in France
Technical logs protected
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Cybersecurity · hosted in France
Which alerts deserve our attention this morning?
Alerts qualified against your detection rules, each with its chain of correlated events.
Three signals bring together several linked events on the same account and the same time window.
The source events and their timestamps are provided.
🔗 Sourced · SIEM logs, correlated events
Three signals bring together several linked events on the same account and the same time window.
The source events and their timestamps are provided.
🔗 Sourced · SIEM logs, correlated events
Can we isolate the account concerned?
The material needed for the decision is gathered: chain of events, apparent extent, systems concerned.
Isolating an account or cutting off access has consequences for the business: that decision belongs to your security team.
✎ Support · material gathered, human remediation
Isolating an account or cutting off access has consequences for the business: that decision belongs to your security team.
✎ Support · material gathered, human remediation
Local inference · no data outside the EU
Logs hosted in France
Sovereign by designLocal inference or hosting in France
GDPR & AI Act: governed deploymentTraceability & human oversight
TurnkeyDesigned, installed and operated for you
Your security team decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent cybersecurity agent, connected to your SIEM, correlates the events, qualifies the alerts against your detection rules and documents every signal with the chain of events and the timestamps it rests on. No remediation is applied automatically. It runs on local inference or is hosted in France: your logs stay with you, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
100%
hosted in France in the target architecture
0
transfer outside the EU in the target architecture
6
security monitoring uses ready to deploy
0
decision taken without human approval
These figures describe our offer, not results measured at a client. How large the gain is on your volume of logs and number of sources is confirmed by a pilot.
The context
What does an AI agent bring to your security monitoring?
A correlated, documented signal can be looked into in minutes; an isolated alert means reconstructing everything.
! The issue
Looking into an alert means gathering the linked events and placing their extent. That correlation work is systematic and lends itself to automation; the remediation decision, on the other hand, commits the business. The agent correlates, qualifies against your rules and provides the full chain with its timestamps.
✓ Our answer
Your security team looks into signals that are already correlated and documented, across all the logs rather than the most closely watched sources. Isolating an account, cutting off access or triggering an incident procedure has consequences for the business: those decisions stay theirs. Local inference or an isolated resource hosted in France: your technical logs, which describe your information system, do not leave the company.
The decisive point
Your technical logs and your security map: sovereignty & compliance
Your technical logs draw the map of your information system: keeping them confidential is a security matter in itself. Here is how that is assured.
Local inference
The agent can run on a machine belonging to your organisation: no technical log and no element of the map leaves the network.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your event logs and your alerts: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For your technical logs and your security map, the architecture aims to reduce exposure to the Cloud Act and FISA 702; being located in France or in the European Union does not, on its own, guarantee immunity.
Isolated resource
No pooling: an environment strictly dedicated to your organisation and its detection rules.
Chain of events kept
Every signal keeps the correlated events and their timestamps; encryption, role-based access and logging that can be used in an investigation.
AI Act: governed deployment
The agent is strictly in support; no account is isolated, no access is cut off and no procedure is triggered automatically; traceability and human oversight from end to end.
What depends on the architecture chosen These points are not general guarantees: they are settled deployment by deployment, in the quotation.
- The applicable location is that of the architecture set out in the quotation and verified before commissioning.
- Local execution is announced only for the configuration explicitly described and accepted in the quotation.
- The applicable isolation depends on the deployment mode set out in the quotation; no dedicated isolation is presumed.
- Roles and permissions are configured and accepted for the identities and systems actually connected.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For investigations in progress and confirmed security incidents, SecNumCloud and reinforced hosting are options depending on your requirements. A single architecture is designed to answer both the GDPR and extraterritorial exposure. Designed for deployment in line with the GDPR and the AI Act, after the processing, roles and context-specific risks have been assessed.
Demonstration
See the agent at work
5 real situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data.
The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds.
The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
The company in this demonstration
Fictional companyMaldeau Groupe — specialist retail, 84 stores and an online shop
- Sector
- Specialist retail — 84 stores, an online shop, two warehouses
- Headcount
- 1,900 staff, including 4 in security: 1 CISO and 3 analysts, office hours
- Public served
- 2.1 million loyalty-card holders, payment in store and online
- Volume monitored
- 2.4 billion events a month, 11 log sources, 1,400 alerts a week
- Tools in place
- SIEM live for 4 years, directory, firewalls, monitored endpoints, ticketing tool — the agent plugs in read-only, nothing is replaced
- Who decides
- The CISO settles remediation gestures; operations approve any access cut-off; the three analysts investigate
- Room for improvement
- 41 alerts investigated in depth each week out of 1,400 received; correlation takes 65 % of the time spent on an alert
Maldeau Groupe receives twenty times more alerts each week than its three analysts can investigate, and nobody has ever been able to say what the other 1,359 contained. The agent runs on local inference on a machine at the group and reads the SIEM, the directory, the ticketing tool and the change calendar: it correlates, qualifies, quantifies the noise set aside and prepares every gesture with its effect on production. The CISO decides, and what he decides executes within minutes. The exchanges below cover one quarter, from the first triage to the review.
This company, its figures and the exchanges that follow were invented for the demonstration. They illustrate a common situation; they describe no real client.
Cybersecurity · hosted in France
This week's 1,400 alerts are sorted. Three deserve your morning, and I tell you exactly why the other 1,397 do not.
Correlation means bringing together the linked events of one account, one machine or one time window, so an alert stops being an isolated dot.
The three signals, by reach:
· Signal 1 — 214 failed authentication attempts on 38 accounts, from 3 addresses, in 11 minutes, then one success on a test account. 34 events correlated across 4 sources.
· Signal 2 — a service account authenticating from an office workstation. A service account is a technical account used by a program, never by a person. Zero occurrences of that behaviour across the previous 90 days.
· Signal 3 — an export volume multiplied by 22 on an account at the north warehouse, between 22:40 and 23:05, outside any declared maintenance window.
What happens to the other 1,397, and nothing disappears:
· 1,240 are set aside with a written reason, viewable and reversible in one click. 620 of them — half — come from three detection rules whose threshold has never been reviewed since it was written.
· 157 are grouped into 9 families and await a tuning decision, not an investigation.
The time this moves: correlation took 65 % of the time spent on an alert; it now takes 7 %. Your analysts used to investigate 41 alerts a week out of 1,400; all 1,400 are now sifted, and they investigate the ones that deserve it.
What I propose: I show you how I checked that this triage lets nothing through — by replaying it across twelve months of your own logs. weekly-triage_1400-alerts.pdf3 signals, 1,240 written reasons, 620 from 3 rules
⛓ Sourced · SIEM (2.4 billion events/month, 11 sources), directory, change calendar
Correlation means bringing together the linked events of one account, one machine or one time window, so an alert stops being an isolated dot.
The three signals, by reach:
· Signal 1 — 214 failed authentication attempts on 38 accounts, from 3 addresses, in 11 minutes, then one success on a test account. 34 events correlated across 4 sources.
· Signal 2 — a service account authenticating from an office workstation. A service account is a technical account used by a program, never by a person. Zero occurrences of that behaviour across the previous 90 days.
· Signal 3 — an export volume multiplied by 22 on an account at the north warehouse, between 22:40 and 23:05, outside any declared maintenance window.
What happens to the other 1,397, and nothing disappears:
· 1,240 are set aside with a written reason, viewable and reversible in one click. 620 of them — half — come from three detection rules whose threshold has never been reviewed since it was written.
· 157 are grouped into 9 families and await a tuning decision, not an investigation.
The time this moves: correlation took 65 % of the time spent on an alert; it now takes 7 %. Your analysts used to investigate 41 alerts a week out of 1,400; all 1,400 are now sifted, and they investigate the ones that deserve it.
What I propose: I show you how I checked that this triage lets nothing through — by replaying it across twelve months of your own logs. weekly-triage_1400-alerts.pdf3 signals, 1,240 written reasons, 620 from 3 rules
⛓ Sourced · SIEM (2.4 billion events/month, 11 sources), directory, change calendar
Setting 1,240 alerts aside is exactly what worries us.
I checked that before proposing it: I replayed the triage across twelve months of your logs, and all three of the year's real incidents come out, at the top of their list.
What the replay measured, rule by rule: for each of your 47 detection rules — the written condition that makes an alert appear — I counted across twelve months how many alerts it produced, how many were confirmed after investigation, and what it would have let through.
· 3 rules produce 44 % of your alerts and 0 confirmations in twelve months.
· 9 rules produce fewer than 5 alerts a month and 61 % of the confirmations. Those are your best ones, and they are drowned.
· The year's 3 real incidents were raised by 2 rules, and the triage places them among the top three signals of their week.
What I propose, written and already tested: four tightened rules, drafted in the form of your existing ones. For each, here is what twelve months of logs give:
· Failed-authentication rule: 84 alerts become 19, the 3 confirmed ones are kept, and 65 pointless investigations disappear.
· Out-of-hours connection rule: 310 become 41, the 2 confirmed ones kept.
· Share-access rule: 240 become 58, the single confirmation kept.
· Application-error rule: 186 become 12, no confirmation lost.
You sign them and they are live tonight — and each one is withdrawn in one word, on its own, without touching the other forty-six. The count of alerts set aside stays viewable at all times: an alert set aside is not an alert deleted. rules-replayed_over-12-months.pdf4 tightened rules, 84 → 19, 3 confirmations kept
⛓ Sourced · 12 months of archived logs, 47 detection rules, history of investigations and confirmations
What the replay measured, rule by rule: for each of your 47 detection rules — the written condition that makes an alert appear — I counted across twelve months how many alerts it produced, how many were confirmed after investigation, and what it would have let through.
· 3 rules produce 44 % of your alerts and 0 confirmations in twelve months.
· 9 rules produce fewer than 5 alerts a month and 61 % of the confirmations. Those are your best ones, and they are drowned.
· The year's 3 real incidents were raised by 2 rules, and the triage places them among the top three signals of their week.
What I propose, written and already tested: four tightened rules, drafted in the form of your existing ones. For each, here is what twelve months of logs give:
· Failed-authentication rule: 84 alerts become 19, the 3 confirmed ones are kept, and 65 pointless investigations disappear.
· Out-of-hours connection rule: 310 become 41, the 2 confirmed ones kept.
· Share-access rule: 240 become 58, the single confirmation kept.
· Application-error rule: 186 become 12, no confirmation lost.
You sign them and they are live tonight — and each one is withdrawn in one word, on its own, without touching the other forty-six. The count of alerts set aside stays viewable at all times: an alert set aside is not an alert deleted. rules-replayed_over-12-months.pdf4 tightened rules, 84 → 19, 3 confirmations kept
⛓ Sourced · 12 months of archived logs, 47 detection rules, history of investigations and confirmations
And what no rule describes? An attack we have never seen slips through.
That is why I do not work from your rules alone: I also measure the gap to habitual behaviour, and that is how I found two of this morning's three signals.
The baseline is the habitual behaviour of an account, a machine or a time slot, measured over a period long enough for the exception to show. Mine covers 90 rolling days, and it is computed per account, per machine and per time slot — a company-wide average would have shown nothing.
The two behaviours none of your 47 rules described:
· The service account authenticating from an office workstation. Over 90 days that account authenticated 4,100 times, always from the same two servers. This morning, once, from a workstation. No rule saw it, because no rule states where a service account is allowed to come from.
· The export volume multiplied by 22. That account's baseline is 4 to 11 MB an evening; yesterday, 214 MB in 25 minutes.
What I draw from it, and propose writing into your rules: three new detection rules, drafted, each with what twelve months of history makes it produce:
· « A service account authenticates from a machine absent from its list » — 6 firings over 12 months, 4 of them confirmed after investigation.
· « An account exceeds ten times its usual export volume » — 11 firings, 3 of them confirmed.
· « An authentication succeeds after more than 50 failures in the same window » — 4 firings, 2 of them confirmed.
Those three rules would have produced 21 alerts in a year — fewer than one a fortnight for your analysts — and nine of them would have been confirmed. You review them, you sign them, and this morning's behaviour becomes a rule of the house. behavioural-detection_3-rules-proposed.pdf21 alerts a year, 9 confirmed against history
⛓ Sourced · 90 days of per-account and per-machine baselines, 12 months of archived logs
The baseline is the habitual behaviour of an account, a machine or a time slot, measured over a period long enough for the exception to show. Mine covers 90 rolling days, and it is computed per account, per machine and per time slot — a company-wide average would have shown nothing.
The two behaviours none of your 47 rules described:
· The service account authenticating from an office workstation. Over 90 days that account authenticated 4,100 times, always from the same two servers. This morning, once, from a workstation. No rule saw it, because no rule states where a service account is allowed to come from.
· The export volume multiplied by 22. That account's baseline is 4 to 11 MB an evening; yesterday, 214 MB in 25 minutes.
What I draw from it, and propose writing into your rules: three new detection rules, drafted, each with what twelve months of history makes it produce:
· « A service account authenticates from a machine absent from its list » — 6 firings over 12 months, 4 of them confirmed after investigation.
· « An account exceeds ten times its usual export volume » — 11 firings, 3 of them confirmed.
· « An authentication succeeds after more than 50 failures in the same window » — 4 firings, 2 of them confirmed.
Those three rules would have produced 21 alerts in a year — fewer than one a fortnight for your analysts — and nine of them would have been confirmed. You review them, you sign them, and this morning's behaviour becomes a rule of the house. behavioural-detection_3-rules-proposed.pdf21 alerts a year, 9 confirmed against history
⛓ Sourced · 90 days of per-account and per-machine baselines, 12 months of archived logs
Signal 2, the service account. Show me everything.
Thirty-four events, six sources, timestamped to the millisecond and clock-corrected. Here is the sequence, and exactly what it establishes.
First, a correction nobody makes by hand: one of your six sources runs 3.2 seconds behind the others. Without that realignment, two events appeared in the wrong order — and order is everything in a chain.
The sequence, as it happened:
· 04:12:06 — the service account authenticates from workstation P-1147, a machine absent from its list of 2 servers. Source: directory.
· 04:12:09 — the same account opens a session on the accounting file server. Source: server log.
· 04:12:44 to 04:19:31 — 1,842 file reads across three directories, 1,615 of them in a directory this account had never touched in 90 days.
· 04:21:02 — an outbound connection attempt to an external address, blocked by your firewall. The block worked, and that is an established fact, not a supposition.
· 04:21:05 to 04:26:18 — 7 further attempts, all blocked.
The perimeter, settled on the logs: 1 account, 2 machines, 3 directories, and no data exfiltration recorded — the eight attempts appear in the firewall log with their timestamp and verdict.
What remains to establish, and how I establish it: the origin of the access to workstation P-1147. I get it from the workstation's local log, which I do not yet collect — and I have drafted the collection request, read-only, scoped to that workstation alone.
The time: building the investigation file took 30 % of the effort; it takes 4 %. This file was built in four minutes, and it is dated, sealed and preserved. event-chain_signal-2.pdf34 events, 6 sources, 8 blocked outbound attempts
⛓ Sourced · directory, server logs, firewall, monitored endpoints, SIEM — clocks realigned
First, a correction nobody makes by hand: one of your six sources runs 3.2 seconds behind the others. Without that realignment, two events appeared in the wrong order — and order is everything in a chain.
The sequence, as it happened:
· 04:12:06 — the service account authenticates from workstation P-1147, a machine absent from its list of 2 servers. Source: directory.
· 04:12:09 — the same account opens a session on the accounting file server. Source: server log.
· 04:12:44 to 04:19:31 — 1,842 file reads across three directories, 1,615 of them in a directory this account had never touched in 90 days.
· 04:21:02 — an outbound connection attempt to an external address, blocked by your firewall. The block worked, and that is an established fact, not a supposition.
· 04:21:05 to 04:26:18 — 7 further attempts, all blocked.
The perimeter, settled on the logs: 1 account, 2 machines, 3 directories, and no data exfiltration recorded — the eight attempts appear in the firewall log with their timestamp and verdict.
What remains to establish, and how I establish it: the origin of the access to workstation P-1147. I get it from the workstation's local log, which I do not yet collect — and I have drafted the collection request, read-only, scoped to that workstation alone.
The time: building the investigation file took 30 % of the effort; it takes 4 %. This file was built in four minutes, and it is dated, sealed and preserved. event-chain_signal-2.pdf34 events, 6 sources, 8 blocked outbound attempts
⛓ Sourced · directory, server logs, firewall, monitored endpoints, SIEM — clocks realigned
Could it not be an administrator working at night?
I put that question to your own systems before calling you, on five points. Four rule the explanation out, and the fifth is settled by a two-minute call.
The five checks, all done:
· Change calendar: no operation planned that night on that server or that account. All 14 operations of the month are on it; this one is not.
· Ticketing tool: no ticket open on that perimeter between the 3rd and the 9th.
· Workstation P-1147: it is assigned to a member of the accounting team, not to an administrator, and it has never been used for a service-account authentication in 90 days.
· Account behaviour: 4,100 authentications in 90 days, all from the same two servers. Zero from a workstation.
· The point that remains: two administrators hold legitimate access to that account. The message is written, addressed by name, and runs to three lines: « did you use the SVC-COMPTA account on the 7th at 04:12 from workstation P-1147? » One answer is enough to close it or to confirm it.
While you call, here is what is already prepared: three possible containment gestures, each with its costed effect on production — containment means isolating an account or a machine to interrupt an action in progress — and their rollback plan. You will have nothing to build at the moment of deciding; you will only have to decide.
The five checks, all done:
· Change calendar: no operation planned that night on that server or that account. All 14 operations of the month are on it; this one is not.
· Ticketing tool: no ticket open on that perimeter between the 3rd and the 9th.
· Workstation P-1147: it is assigned to a member of the accounting team, not to an administrator, and it has never been used for a service-account authentication in 90 days.
· Account behaviour: 4,100 authentications in 90 days, all from the same two servers. Zero from a workstation.
· The point that remains: two administrators hold legitimate access to that account. The message is written, addressed by name, and runs to three lines: « did you use the SVC-COMPTA account on the 7th at 04:12 from workstation P-1147? » One answer is enough to close it or to confirm it.
While you call, here is what is already prepared: three possible containment gestures, each with its costed effect on production — containment means isolating an account or a machine to interrupt an action in progress — and their rollback plan. You will have nothing to build at the moment of deciding; you will only have to decide.
The administrator says it was not him. We need that access cut, right now.
It is all set up, the effect on production is costed, the rollback takes 90 seconds. Sign the mandate and the access is cut in four minutes.
What the cut-off touches, because you should know before rather than after: that account carries three production flows.
· Stock synchronisation for the 84 stores, at 4 a.m. Workaround ready: switch to the standby account already provisioned, 2 minutes.
· The payment connector of the online shop. Checked: it uses another account. No effect.
· The month-end accounting export, next run in 6 days. No effect today.
The mandate I propose, written, capped, dated:
· Scope: the SVC-COMPTA account and workstation P-1147, by name — no other machine, no other account.
· Gestures covered: disabling the account, network isolation of the workstation, and nothing else.
· Term: until 6 a.m. this morning, extended in one word or withdrawn in one word.
· Notification: the CISO and the operations on-call are informed to the second of execution, with the reason and the event chain.
· Rollback: prepared, tested, 90 seconds, and executable by you without me.
· Trail: who signed, at which second, on which signal, with which chain of evidence.
And during those four minutes I freeze the evidence: a copy of the six sources' logs over the 03:00 – 05:00 window, sealed with a hash — the digital signature proving a file has not been altered since it was copied. Containment often erases the very traces you needed to keep; these are frozen beforehand.
You sign, I execute, and you have the timestamped report at 04:34. containment-mandate_scope-and-rollback.pdf2 named objects, 4 minutes to execute, 90 s rollback
✎ Framework · production dependencies mapped, rollback plan tested, mandate settings
What the cut-off touches, because you should know before rather than after: that account carries three production flows.
· Stock synchronisation for the 84 stores, at 4 a.m. Workaround ready: switch to the standby account already provisioned, 2 minutes.
· The payment connector of the online shop. Checked: it uses another account. No effect.
· The month-end accounting export, next run in 6 days. No effect today.
The mandate I propose, written, capped, dated:
· Scope: the SVC-COMPTA account and workstation P-1147, by name — no other machine, no other account.
· Gestures covered: disabling the account, network isolation of the workstation, and nothing else.
· Term: until 6 a.m. this morning, extended in one word or withdrawn in one word.
· Notification: the CISO and the operations on-call are informed to the second of execution, with the reason and the event chain.
· Rollback: prepared, tested, 90 seconds, and executable by you without me.
· Trail: who signed, at which second, on which signal, with which chain of evidence.
And during those four minutes I freeze the evidence: a copy of the six sources' logs over the 03:00 – 05:00 window, sealed with a hash — the digital signature proving a file has not been altered since it was copied. Containment often erases the very traces you needed to keep; these are frozen beforehand.
You sign, I execute, and you have the timestamped report at 04:34. containment-mandate_scope-and-rollback.pdf2 named objects, 4 minutes to execute, 90 s rollback
✎ Framework · production dependencies mapped, rollback plan tested, mandate settings
It is cut, and the administrator confirmed it was not him. What now?
Six actions, in the order they hold together, each with its duration, its effect and what it touches in production. Four are covered by the mandate in force; two need operations' agreement, and I have prepared them for it.
· 1. Rotate the service account's secret and reset it on its two servers. 12 minutes, no daytime effect, stock synchronisation returns to it at 4 a.m. tomorrow.
· 2. Remove from workstation P-1147 the rights that have no business being there. 4 minutes, and I checked: 3 other accounting workstations carry exactly the same rights.
· 3. Search for the same sequence across the previous 90 days and the other 10 sources. Done: 0 occurrences. That is an established fact, and it is worth more than a reassuring hunch.
· 4. Check the 6 other service accounts of the same kind. Done: 2 of them authenticate from machines outside their list, regularly and documented by tickets — those are undeclared legitimate uses. The lists have been up to date since this morning.
· 5. Restrict service accounts to their machine list, across the 7 accounts. Needs operations' agreement: a 30-minute window, one service restart. The request file is written.
· 6. Extend collection to the local logs of the accounting workstations — 14 machines, read-only. Needs operations' agreement; the estimated volume is costed in the file.
The evidence, meanwhile: the sealed copy of the six sources is preserved with its hash and its timestamp, and each of the actions above is written into the same file with the second at which it was executed and by whom.
What I propose: you approve the first four in one word, I take the last two to operations this morning, and I hand you the complete file before noon. remediation-plan_6-actions.pdf4 under mandate, 2 to operations, 0 prior occurrence
⛓ Sourced · signal 2 event chain, directory, tickets, service-account inventory
· 1. Rotate the service account's secret and reset it on its two servers. 12 minutes, no daytime effect, stock synchronisation returns to it at 4 a.m. tomorrow.
· 2. Remove from workstation P-1147 the rights that have no business being there. 4 minutes, and I checked: 3 other accounting workstations carry exactly the same rights.
· 3. Search for the same sequence across the previous 90 days and the other 10 sources. Done: 0 occurrences. That is an established fact, and it is worth more than a reassuring hunch.
· 4. Check the 6 other service accounts of the same kind. Done: 2 of them authenticate from machines outside their list, regularly and documented by tickets — those are undeclared legitimate uses. The lists have been up to date since this morning.
· 5. Restrict service accounts to their machine list, across the 7 accounts. Needs operations' agreement: a 30-minute window, one service restart. The request file is written.
· 6. Extend collection to the local logs of the accounting workstations — 14 machines, read-only. Needs operations' agreement; the estimated volume is costed in the file.
The evidence, meanwhile: the sealed copy of the six sources is preserved with its hash and its timestamp, and each of the actions above is written into the same file with the second at which it was executed and by whom.
What I propose: you approve the first four in one word, I take the last two to operations this morning, and I hand you the complete file before noon. remediation-plan_6-actions.pdf4 under mandate, 2 to operations, 0 prior occurrence
⛓ Sourced · signal 2 event chain, directory, tickets, service-account inventory
If we have to account for this to a third party — our insurer, a customer, an authority — what do we have?
A complete file, produced continuously from the first second, and issued in three versions depending on who you are talking to.
What the file holds, already written:
· The timestamped chronology of the 34 events, source by source, with the clock realignment documented.
· The established perimeter: 1 account, 2 machines, 3 directories, and the 8 blocked outbound attempts, with the firewall verdict for each.
· What is established and by which source, kept distinct from what is being established, with the means of establishing it — here, the workstation's local log, whose collection is requested.
· The data potentially concerned: the 1,615 files read are identified by name, and I have qualified their content: 1,402 accounting documents, 213 payroll files. That list is the first thing a third party will ask for.
· The actions and their timestamps, with the name of the signatory of each mandate.
· The hashes of the log copies, which let you show that nothing was retouched.
The three versions, ready together: a one-page note for the board, a full technical file for your analysts and for an expert, and a version intended for a third party with the architecture details that have no business leaving removed — and I tell you which ones I removed and why.
The time this changes: a regulatory notification is prepared in hours, not days. This file is complete and dated before the question arises; your counsel decides what has to be notified, and decides on a finished file. Building the file moves from 30 % to 4 % of investigation time, and it no longer depends on the memory of whoever was on duty. investigation-file_three-versions.pdf1,615 files identified, hashes preserved
⛓ Sourced · sealed log copies, mandate log, inventory of files read, hashes
What the file holds, already written:
· The timestamped chronology of the 34 events, source by source, with the clock realignment documented.
· The established perimeter: 1 account, 2 machines, 3 directories, and the 8 blocked outbound attempts, with the firewall verdict for each.
· What is established and by which source, kept distinct from what is being established, with the means of establishing it — here, the workstation's local log, whose collection is requested.
· The data potentially concerned: the 1,615 files read are identified by name, and I have qualified their content: 1,402 accounting documents, 213 payroll files. That list is the first thing a third party will ask for.
· The actions and their timestamps, with the name of the signatory of each mandate.
· The hashes of the log copies, which let you show that nothing was retouched.
The three versions, ready together: a one-page note for the board, a full technical file for your analysts and for an expert, and a version intended for a third party with the architecture details that have no business leaving removed — and I tell you which ones I removed and why.
The time this changes: a regulatory notification is prepared in hours, not days. This file is complete and dated before the question arises; your counsel decides what has to be notified, and decides on a finished file. Building the file moves from 30 % to 4 % of investigation time, and it no longer depends on the memory of whoever was on duty. investigation-file_three-versions.pdf1,615 files identified, hashes preserved
⛓ Sourced · sealed log copies, mandate log, inventory of files read, hashes
And so that it does not happen again?
Five root causes, each with its costed fix and the effect it would have had across twelve months of your logs. Three of them remove 61 % of the alerts in this family.
· Service accounts are not restricted to their machines. Fix: the per-account list, 7 accounts, a 30-minute window. Measured effect over 12 months: this morning's sequence becomes impossible, and 6 historical firings out of 6 would have been blocked at authentication.
· Three accounting workstations carry rights left over from a project closed in 2023. Fix: removal, 12 minutes, no effect on usage recorded over 90 days.
· Workstation local logs are not collected. Fix: read-only collection on 14 machines. Effect: the year's 4 investigations that stayed incomplete would all have been closed.
· Three detection rules produce 44 % of the noise and no confirmation. Fix: the four tightened rules you signed. Effect already recorded: 620 fewer alerts a week.
· The change calendar is not matched against alerts. Fix: I now read it before qualifying. Effect: 2 high-level signals avoided in three months.
The hardening plan I propose, in three waves:
· Wave 1, this week — the two fixes with no effect on production. 16 minutes in total.
· Wave 2, at the next window — the service-account lists. 30 minutes, request file written.
· Wave 3, across the month — workstation collection, in batches of 5.
And I measure the effect of each wave on real alerts, week by week, so that hardening is judged on figures rather than on an impression. hardening-plan_5-root-causes.pdf3 fixes = 61 % fewer alerts in the family
⛓ Sourced · 12 months of archived logs, rights inventory, investigation history
· Service accounts are not restricted to their machines. Fix: the per-account list, 7 accounts, a 30-minute window. Measured effect over 12 months: this morning's sequence becomes impossible, and 6 historical firings out of 6 would have been blocked at authentication.
· Three accounting workstations carry rights left over from a project closed in 2023. Fix: removal, 12 minutes, no effect on usage recorded over 90 days.
· Workstation local logs are not collected. Fix: read-only collection on 14 machines. Effect: the year's 4 investigations that stayed incomplete would all have been closed.
· Three detection rules produce 44 % of the noise and no confirmation. Fix: the four tightened rules you signed. Effect already recorded: 620 fewer alerts a week.
· The change calendar is not matched against alerts. Fix: I now read it before qualifying. Effect: 2 high-level signals avoided in three months.
The hardening plan I propose, in three waves:
· Wave 1, this week — the two fixes with no effect on production. 16 minutes in total.
· Wave 2, at the next window — the service-account lists. 30 minutes, request file written.
· Wave 3, across the month — workstation collection, in batches of 5.
And I measure the effect of each wave on real alerts, week by week, so that hardening is judged on figures rather than on an impression. hardening-plan_5-root-causes.pdf3 fixes = 61 % fewer alerts in the family
⛓ Sourced · 12 months of archived logs, rights inventory, investigation history
We have eleven sources. Is that enough?
They cover most of your estate, and I started by repairing what was already broken: two of your eleven sources had stopped sending anything.
What had failed silently, with nothing to flag it:
· The online shop's firewall log had stopped sending for 23 days, after an update. Twenty-three days with no visibility on the group's most exposed flow. Flagged, repaired, and I now watch the freshness of every source: a source that goes quiet for more than 30 minutes raises an alert like any other event.
· One of the two warehouses' logs had stopped sending for 9 days. Same treatment.
The three blind spots that remain — parts of the estate from which no log arrives — and what each costs and returns:
· The 84 store tills have sent nothing for 14 months, that is 22 % of your estate. They carry in-store payment. Opening collection: +180 million events a month, +€310 of monthly storage. What it returns: of the year's 3 incidents, 1 took 6 days to scope for want of those logs.
· The supplier portal does not log its authentications. Opening: +2 million events a month, negligible storage, half a day of connection work. It gives access to your purchasing terms: the best ratio of reach to effort.
· The office file store does not log read access. That is precisely what was missing this morning on the 1,615 files — I identified them through the server log, and that route does not work everywhere. Opening: +40 million events a month, €90 of storage.
What I propose: I cost the effect of each opening on alert volume before you decide — so that nobody discovers the noise after plugging it in. source-coverage_3-blind-spots.pdf2 sources repaired, 22 % of the estate to open
⛓ Sourced · inventory of the 11 sources, feed freshness, history of the year's 3 incidents
What had failed silently, with nothing to flag it:
· The online shop's firewall log had stopped sending for 23 days, after an update. Twenty-three days with no visibility on the group's most exposed flow. Flagged, repaired, and I now watch the freshness of every source: a source that goes quiet for more than 30 minutes raises an alert like any other event.
· One of the two warehouses' logs had stopped sending for 9 days. Same treatment.
The three blind spots that remain — parts of the estate from which no log arrives — and what each costs and returns:
· The 84 store tills have sent nothing for 14 months, that is 22 % of your estate. They carry in-store payment. Opening collection: +180 million events a month, +€310 of monthly storage. What it returns: of the year's 3 incidents, 1 took 6 days to scope for want of those logs.
· The supplier portal does not log its authentications. Opening: +2 million events a month, negligible storage, half a day of connection work. It gives access to your purchasing terms: the best ratio of reach to effort.
· The office file store does not log read access. That is precisely what was missing this morning on the 1,615 files — I identified them through the server log, and that route does not work everywhere. Opening: +40 million events a month, €90 of storage.
What I propose: I cost the effect of each opening on alert volume before you decide — so that nobody discovers the noise after plugging it in. source-coverage_3-blind-spots.pdf2 sources repaired, 22 % of the estate to open
⛓ Sourced · inventory of the 11 sources, feed freshness, history of the year's 3 incidents
That is the point: more sources, more noise. It is what made us give up last time.
I simulated it across thirty days of your archives before proposing it, and the result is the opposite of what you fear: six alerts a week, four of which would have been confirmed.
The simulation, as I ran it: I took 30 days of till logs kept locally in two pilot stores, ran them through the triage, and extrapolated to all 84.
· With no adapted rule: +40 raw alerts a week. That is the figure that made you give up, and it is accurate.
· With the 3 rules I wrote for that source: 6 alerts a week, 4 of which match situations your analysts would have wanted to know about — two administrator sessions opened on a till outside any planned intervention, and two card readers replaced outside procedure.
· The other 34 are absorbed by the triage, each with its viewable reason.
The ratio, plainly: +180 million events a month for 6 weekly alerts. The volume never reaches your analysts; it reaches correlation, and correlation is what I do.
And the benefit shows somewhere other than in alerts: those logs are what settles a perimeter in hours rather than days. The incident that took 6 days to scope this year would have taken less than one.
What I propose: open two stores for three weeks, measure the real alerts, and decide the other 82 on what you have seen at home. That trial costs €8 of storage.
The simulation, as I ran it: I took 30 days of till logs kept locally in two pilot stores, ran them through the triage, and extrapolated to all 84.
· With no adapted rule: +40 raw alerts a week. That is the figure that made you give up, and it is accurate.
· With the 3 rules I wrote for that source: 6 alerts a week, 4 of which match situations your analysts would have wanted to know about — two administrator sessions opened on a till outside any planned intervention, and two card readers replaced outside procedure.
· The other 34 are absorbed by the triage, each with its viewable reason.
The ratio, plainly: +180 million events a month for 6 weekly alerts. The volume never reaches your analysts; it reaches correlation, and correlation is what I do.
And the benefit shows somewhere other than in alerts: those logs are what settles a perimeter in hours rather than days. The incident that took 6 days to scope this year would have taken less than one.
What I propose: open two stores for three weeks, measure the real alerts, and decide the other 82 on what you have seen at home. That trial costs €8 of storage.
All right. Where do we start?
With the supplier portal this week, the two pilot stores next week, the office file store straight after. The order is costed, and the collection mandate is written.
The order proposed, and the arithmetic behind it:
· 1. Supplier portal — half a day of connection work, negligible storage, and it covers access to your purchasing terms. Best ratio of reach to effort of the three.
· 2. Two pilot stores — €8 over three weeks, with the decision on the other 82 taken on your own figures.
· 3. Office file store — €90 a month, and it closes the gap that was missing this morning.
The collection mandate I propose, written, capped, dated:
· Purpose: read the logs of the listed sources, and nothing else. No access to business content, no writing to any system.
· Scope: the sources named individually, added one at a time and never by family.
· Term: three weeks for the pilots, renewed in one word on the figures.
· Withdrawal: in one word, at any moment — collection stops, the archives remain yours.
· Trail: every source activated is logged with the signature that covered it.
What it hands you after three weeks: a figure of your own, measured at home, on which to settle the remaining 82 stores. You sign, and the first source is collecting this afternoon. coverage-plan_order-and-mandate.pdf3 costed openings, €8 trial
✎ Framework · simulation over 30 days of archives, storage costs, collection mandate settings
The order proposed, and the arithmetic behind it:
· 1. Supplier portal — half a day of connection work, negligible storage, and it covers access to your purchasing terms. Best ratio of reach to effort of the three.
· 2. Two pilot stores — €8 over three weeks, with the decision on the other 82 taken on your own figures.
· 3. Office file store — €90 a month, and it closes the gap that was missing this morning.
The collection mandate I propose, written, capped, dated:
· Purpose: read the logs of the listed sources, and nothing else. No access to business content, no writing to any system.
· Scope: the sources named individually, added one at a time and never by family.
· Term: three weeks for the pilots, renewed in one word on the figures.
· Withdrawal: in one word, at any moment — collection stops, the archives remain yours.
· Trail: every source activated is logged with the signature that covered it.
What it hands you after three weeks: a figure of your own, measured at home, on which to settle the remaining 82 stores. You sign, and the first source is collecting this afternoon. coverage-plan_order-and-mandate.pdf3 costed openings, €8 trial
✎ Framework · simulation over 30 days of archives, storage costs, collection mandate settings
One quarter. Where do we stand, with figures?
All 1,400 weekly alerts are sifted, and your three analysts investigate what deserves it instead of picking 41 at random on a Monday.
What moved, task by task:
· Correlating events: 65 % → 7 % of the time spent on an alert.
· Qualifying an alert: 40 % → 6 %.
· Building the investigation file: 30 % → 4 %.
· Average time from an alert arriving to its qualification: 4 h 10 → 6 minutes.
· Alerts received: 1,400 → 640 a week, after the four tightened rules — and all 640 are qualified.
What it gave in security, and that is the only figure that truly counts: 2 real incidents detected in the quarter, one of them qualified in 11 minutes and contained within the next twenty. The previous incident of the same kind, last year, was discovered after 6 days.
Where the time went: +62 % of analyst hours on hardening and rule review, per your own activity records. That is the work that drives incident counts down, and nobody had time for it.
The figure that does not flatter me: of 47 signals qualified « to investigate » in three months, 2 turned out to be groundless — 6 analyst hours spent examining something that was not an incident.
The cause is clear: both came from my export-volume rule, fired by a data migration that was planned but not declared in the change calendar. The rule was not wrong; the information it lacked was.
The correction is made and measured: I now read the change calendar and the migration windows declared by operations before qualifying, and I obtained that migrations be entered there — 11 have been since. Over the last six weeks: 0 signals of that kind. A rule is judged on its precision and on how much hindsight backs it: this one has six weeks of hindsight, and I will hand you the measurement again at the quarter. quarter-review_1400-alerts-sorted.pdfQualification in 6 min, 1 incident scoped in 11 min
⛓ Sourced · SIEM, qualification log, analyst activity records, change calendar
What moved, task by task:
· Correlating events: 65 % → 7 % of the time spent on an alert.
· Qualifying an alert: 40 % → 6 %.
· Building the investigation file: 30 % → 4 %.
· Average time from an alert arriving to its qualification: 4 h 10 → 6 minutes.
· Alerts received: 1,400 → 640 a week, after the four tightened rules — and all 640 are qualified.
What it gave in security, and that is the only figure that truly counts: 2 real incidents detected in the quarter, one of them qualified in 11 minutes and contained within the next twenty. The previous incident of the same kind, last year, was discovered after 6 days.
Where the time went: +62 % of analyst hours on hardening and rule review, per your own activity records. That is the work that drives incident counts down, and nobody had time for it.
The figure that does not flatter me: of 47 signals qualified « to investigate » in three months, 2 turned out to be groundless — 6 analyst hours spent examining something that was not an incident.
The cause is clear: both came from my export-volume rule, fired by a data migration that was planned but not declared in the change calendar. The rule was not wrong; the information it lacked was.
The correction is made and measured: I now read the change calendar and the migration windows declared by operations before qualifying, and I obtained that migrations be entered there — 11 have been since. Over the last six weeks: 0 signals of that kind. A rule is judged on its precision and on how much hindsight backs it: this one has six weeks of hindsight, and I will hand you the measurement again at the quarter. quarter-review_1400-alerts-sorted.pdfQualification in 6 min, 1 incident scoped in 11 min
⛓ Sourced · SIEM, qualification log, analyst activity records, change calendar
What do you do without asking us?
Three gestures, and none of them touches your production. Anything that can stop a service lives in a written, capped, dated mandate, withdrawable in one word — and executes within minutes once signed.
· Sort and qualify alerts, with a written reason for each, viewable and reversible. 8,320 alerts handled this quarter.
· Enrich a signal before showing it to you: directory, tickets, change calendar, 90-day behaviour. That is what takes qualification from 4 h 10 to 6 minutes.
· Freeze a copy of the logs as soon as a signal passes the threshold you set. No effect on production, and it preserves exactly what containment would erase. 14 sealed copies this quarter, 2 of which were used.
What the mandates covered, and what they cost in time:
· 11 mandates signed in three months: 3 containments, 5 collection activations, 3 remediations touching a service.
· Median time from signature to execution: 4 minutes.
· 1 rollback executed, on a containment lifted after verification, in 80 seconds — proof that reversibility works, and it has been used.
· 0 gestures executed outside the scope of a mandate, and the log shows it line by line.
What I propose adding, costed: a standing containment mandate, capped to three situations you describe yourself — for instance « a service account authenticates outside its machine list between 22:00 and 06:00 ». Across the quarter that would have saved 34 minutes on the night incident alone, between detection and the CISO's signature. You write the three situations, you set the term, and you withdraw the mandate in one word the day it no longer suits you. mandate-framework_11-signed.pdf4 min from signature to execution, 80 s rollback
✎ Framework · mandate log, qualification log, register of sealed copies
· Sort and qualify alerts, with a written reason for each, viewable and reversible. 8,320 alerts handled this quarter.
· Enrich a signal before showing it to you: directory, tickets, change calendar, 90-day behaviour. That is what takes qualification from 4 h 10 to 6 minutes.
· Freeze a copy of the logs as soon as a signal passes the threshold you set. No effect on production, and it preserves exactly what containment would erase. 14 sealed copies this quarter, 2 of which were used.
What the mandates covered, and what they cost in time:
· 11 mandates signed in three months: 3 containments, 5 collection activations, 3 remediations touching a service.
· Median time from signature to execution: 4 minutes.
· 1 rollback executed, on a containment lifted after verification, in 80 seconds — proof that reversibility works, and it has been used.
· 0 gestures executed outside the scope of a mandate, and the log shows it line by line.
What I propose adding, costed: a standing containment mandate, capped to three situations you describe yourself — for instance « a service account authenticates outside its machine list between 22:00 and 06:00 ». Across the quarter that would have saved 34 minutes on the night incident alone, between detection and the CISO's signature. You write the three situations, you set the term, and you withdraw the mandate in one word the day it no longer suits you. mandate-framework_11-signed.pdf4 min from signature to execution, 80 s rollback
✎ Framework · mandate log, qualification log, register of sealed copies
And our technical logs, where do they go?
They stay with you. I run on local inference on a machine at the group, and your logs cross no outside network to be analysed.
Local inference means the model computes on your machine: a log line does not leave your network to be read. If you would rather not host a machine, the other route is an isolated resource hosted in France, under French law, dedicated to your group — no pooling with another company.
Why this is a security matter and not only a compliance one: your logs draw the exact map of your information system — server names, service accounts, address ranges, backup windows, production dependencies. It is the document an attacker would take months to rebuild, and you have already written it. It stays in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity, and it trains no model.
What that looks like day to day: role-based access — rights follow the job: an analyst opens the logs of their perimeter, not the full map —, encryption in transit and at rest, copies sealed by hash, and a full access log: who consulted which log, when, and over which window.
And what it hands you commercially, because this is not only an internal matter: your cyber insurer, your two largest customers and your payment provider ask the same question at renewal: where your logs are and who reads them. The answer fits on one page, produced in a few seconds, and it carries the name of every authorised person.
And you keep control wherever you are: a web dashboard, and supervision from your phone — you sign a containment mandate or withdraw it in one message, at 4 a.m. as easily as at noon.
The next step I propose: your 11 sources are covered and 3 openings are under way. Your two warehouses run on controllers producing logs nobody reads — 40 million events a month already written to disk. I read 30 days of them: 4 behaviours stand out, 2 of which would deserve a rule. Say the word and I hand you the full analysis on Friday. technical-framework_where-your-logs-live.pdfLocal inference, role-based access, processing in the EU targeted
✎ Framework · deployment architecture, role-based access matrix, consultation log
Local inference means the model computes on your machine: a log line does not leave your network to be read. If you would rather not host a machine, the other route is an isolated resource hosted in France, under French law, dedicated to your group — no pooling with another company.
Why this is a security matter and not only a compliance one: your logs draw the exact map of your information system — server names, service accounts, address ranges, backup windows, production dependencies. It is the document an attacker would take months to rebuild, and you have already written it. It stays in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity, and it trains no model.
What that looks like day to day: role-based access — rights follow the job: an analyst opens the logs of their perimeter, not the full map —, encryption in transit and at rest, copies sealed by hash, and a full access log: who consulted which log, when, and over which window.
And what it hands you commercially, because this is not only an internal matter: your cyber insurer, your two largest customers and your payment provider ask the same question at renewal: where your logs are and who reads them. The answer fits on one page, produced in a few seconds, and it carries the name of every authorised person.
And you keep control wherever you are: a web dashboard, and supervision from your phone — you sign a containment mandate or withdraw it in one message, at 4 a.m. as easily as at noon.
The next step I propose: your 11 sources are covered and 3 openings are under way. Your two warehouses run on controllers producing logs nobody reads — 40 million events a month already written to disk. I read 30 days of them: 4 behaviours stand out, 2 of which would deserve a rule. Say the word and I hand you the full analysis on Friday. technical-framework_where-your-logs-live.pdfLocal inference, role-based access, processing in the EU targeted
✎ Framework · deployment architecture, role-based access matrix, consultation log
"With us", fine. But the foundation itself — what does it rest on?
On a sovereign AI, and I will give it to you item by item rather than in one word.
· Where the computation happens: local inference on a machine in the group, hosted in France and operated under French law. Your 2.4 billion monthly events cross no external network to be analysed.
· Which model: an open-weights model, run on your premises, on a version that is pinned and dated. A model update is a documented change, not a silent switch on a Tuesday morning — for a security team, detection behaviour that changes without notice is an incident in itself.
· What goes back to the vendor: nothing from your logs. No sample, no signature, no statistic derived from your events.
· Who reads what: access by role, logged line by line, withdrawn with a word, effective at the next run. Your three analysts and your security manager do not see the same thing, and the log says who saw what and when.
· What you take with you if you leave: your detection rules, your correlations, the history of qualifications and the evidence files, in open formats. A dependency you cannot leave is not sovereignty, it is polite captivity.
· The limit, and I state it because it is the honest counterpart of the rest: the architecture is designed to reduce exposure to extraterritorial legislation — location alone does not guarantee immunity, and a machine hosted in France but operated by a third party under foreign law would protect you no better. What protects is the combination: place, applicable law, operator, and the fact that nothing leaves.
What it costs you in performance, measured here: qualifying an alert takes 6 minutes locally against 4 minutes on a shared remote resource. Two minutes an alert, for logs that never leave your walls — that is the trade-off, and it is yours to make.
✎ Framework · the sovereign foundation, item by item
· Where the computation happens: local inference on a machine in the group, hosted in France and operated under French law. Your 2.4 billion monthly events cross no external network to be analysed.
· Which model: an open-weights model, run on your premises, on a version that is pinned and dated. A model update is a documented change, not a silent switch on a Tuesday morning — for a security team, detection behaviour that changes without notice is an incident in itself.
· What goes back to the vendor: nothing from your logs. No sample, no signature, no statistic derived from your events.
· Who reads what: access by role, logged line by line, withdrawn with a word, effective at the next run. Your three analysts and your security manager do not see the same thing, and the log says who saw what and when.
· What you take with you if you leave: your detection rules, your correlations, the history of qualifications and the evidence files, in open formats. A dependency you cannot leave is not sovereignty, it is polite captivity.
· The limit, and I state it because it is the honest counterpart of the rest: the architecture is designed to reduce exposure to extraterritorial legislation — location alone does not guarantee immunity, and a machine hosted in France but operated by a third party under foreign law would protect you no better. What protects is the combination: place, applicable law, operator, and the fact that nothing leaves.
What it costs you in performance, measured here: qualifying an alert takes 6 minutes locally against 4 minutes on a shared remote resource. Two minutes an alert, for logs that never leave your walls — that is the trade-off, and it is yours to make.
✎ Framework · the sovereign foundation, item by item
Local inference · no data outside the EU
Your case is not here? That is exactly what a 15-minute conversation is for. Book the free audit →
Use cases
What does the agent actually do?
One agent, several stages of monitoring. All these uses work in support, subject to your approval.
Included in your agent
The 4 capabilities essential to this promise are included, at no extra cost.
From 601 € excl. VAT / month
Correlating events
Brings together the linked events on the same account or in the same time window.
Qualifying alerts
Applies your detection rules and presents the result obtained.
Investigation documentation
Keeps the chain of events and the timestamps of every signal.
Sovereign AI
The hosting and confidentiality foundation the agent rests on.
Controls and safeguards
These 5 controls are built into the agent: they frame what it does, whatever plan you pick. They are not chosen and are not added to your order.
Human validation, exceptions and escalation
Status, safe closure and audit trail
Access the technical context with least-privilege permissions
Run tests, security analysis and human review before any change
Version, log, roll back and measure quality
Need to go further?
These agents handle a different business process, with their own owner and their own price. They are added to this one.
Does your need fall outside this?
Book the free audit →
Build your agent
In 15 minutes we identify the most relevant agent — without oversizing the project.
The gain
How many alerts can a team look into?
By taking on the correlation, the effort shifts towards investigation and remediation. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Correlating the events
Qualifying an alert
Building the investigation file
Indicative figures, not contractual, to be confirmed by a pilot on your volume of logs and number of sources. Isolating an account, cutting off access or triggering an incident procedure has consequences for the business: those decisions belong to your security team.
How it works
The stages of your AI agent project
1
Audit & scoping
15 minutes to target the use case with the best return.
2
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
3
Design
We design the agent and its guardrails.
4
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
5
Rollout
Going live and training your team.
6
Operation
Continuous supervision and improvement.
Pricing
One package, one agent
A security monitoring agent (correlation, qualification, documentation), installed and operated for you.
Agility
Setup + controlled subscription
6,545 € excl. VAT setup
then 601 € excl. VAT/month — you invest at installation and pay a reduced subscription. Ideal for keeping the cost under control over time.
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Sovereign hosting in France, a dedicated and isolated resource
The simplest
Serenity
All inclusive, no setup fee
961 € excl. VAT /month
all inclusive, immediate start. No upfront investment: a single subscription. Ideal for starting quickly and simply.
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Sovereign hosting in France, managed end to end
100% Sovereign
On site, you own it
10,370 € excl. VAT setup
then 816 € excl. VAT/month · + hardware from 1,058 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract. 36-month commitment.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Not included in the packages: AI consumption (model tokens), re-invoiced at real cost with no margin, and tracked in real time in your client area. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices exclude VAT.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting in France for the package chosen, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Our commitment
Four guarantees that matter to your security
Your technical logs stay with youLocal inference or an isolated resource hosted in France; no log entrusted to a third party, no data used to train a model.
Data in France, under French lawYour technical logs and your security map: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
Your security team keeps the decisionThe agent produces alerts that are qualified and documented, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn your volume of logs and number of sources: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does the agent apply remediation measures?
No. It correlates, qualifies and documents. Isolating an account or cutting off access has consequences for the business: those acts belong to your security team.
What is the qualification based on?
On your detection rules, applied as they stand. The result is presented with the chain of events that produced it.
What sources does it connect to?
To your SIEM and the log sources you open to it, read-only. The scope is settled at the design stage.
Can the signals be used in an investigation?
Yes: correlated events and timestamps are kept for every signal, which makes it possible to reconstruct the sequence afterwards.
Are our logs protected?
Yes. The agent is hosted in France, on local inference or an isolated resource, with the deployment objective of processing and access operated within the European Union and an architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. Your logs are not used to train a third-party model.
How long does it take to deploy this agent?
A few months as a rule, depending on the volume of logs, the number of sources and your detection rules, after a free audit then phases of design, integration and testing.
Related use cases
Other agents for IT
Let's talk
Let's size up the potential in your security monitoring
15 minutes to frame your sources and your detection rules — hosted in France, supervised, with no commitment.