We build Agents. You build the Future.
● B2B offer — Vulnerability & patch managementVulnerabilities and patches: which advisory hits which machine, in what order, and on what evidence
A security advisory is published about a product; it says nothing about you until your inventory speaks. Your agent works on the inventories, software bills of materials and scanner reports you open to it: it looks for where that product runs, in which version, exposed how and under whose ownership, explains the order of work factor by factor, then prepares the ticket, the tests, the change window and the rollback. Data hosted in France; the AI model is called at its publisher, except with the Sovereign model option. With the 100% Sovereign package, the map of your versions and weak points does not leave the company. Deploying a patch stays a human decision, taken by the asset owner and recorded.
Updated on
Fictional simulation — not a client result
Every match carries a confidence level and the evidence behind it; the order of work recomposes factor by factor, together with the policy rule that may have raised it.
An asset whose version is unknown is marked under investigation, never fixed.
🔗 Sourced · inventories, bills of materials and reports deposited, with their date and age
A patch applied without a rollback turns a production capability into a bet: the decision belongs to the asset owner, execution to your operations team, and the effect is declared achieved only after the next inventory is read back.
✎ Framework · change prepared, decision and deployment human
For an organisation established outside the European Union, the law of its own country applies; at its request, we put equivalent safeguards in place (human review before any action, a log of the criteria, information for the people concerned).
A Blue Lemon Agent for vulnerability and patch management, working on the inventories, software bills of materials and reports you deposit: it matches each published advisory to the assets carrying the product, displays its confidence and its evidence, explains the order of work factor by factor, prepares the ticket, tests, window and rollback, then assembles the evidence file. Deployment orchestration runs in simulation by default: any real write requires a confirmed asset and version, a patch from an approved source, the required tests passed, an available rollback and a recorded human approval. Data hosted in France; the AI model is called at its publisher, except with the Sovereign model option. With the 100% Sovereign package, the map of your versions stays with you, an architecture designed to reduce exposure to extraterritorial legislation, location alone not guaranteeing immunity.
Reference points describing our offer, not results measured at a customer site. How far the gain reaches, across your assets, advisories and owners, is confirmed by a pilot.
Indicative estimate, to be confirmed by a pilot on your real files (general terms of sale, article 4).
One core, one agent
One vulnerability and patch management agent (inventory, matching, prioritisation, plan, evidence), installed and operated for you, with four advisory sources included: CERT-FR, ENISA's European Vulnerability Database (EUVD), CVE programme identifiers and five vendor feeds named in the contract. Any other source is added as an option, quoted individually.
Setup + controlled subscription
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Hosting in France, a dedicated and isolated resource
All inclusive, no setup fee
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Hosting in France, managed end to end
On site, you own it
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
What does the agent actually do?
Twelve modules included in the core, from the reconciled inventory to the evidence file, with links to neighbouring agents. The agent carries out by itself what you authorise it to do; any real write requires a recorded human approval.
Reconciled cyber inventory
Brings your inventory sources together — endpoint estate, configuration database, cloud accounts, image registries, dependency manifests — into one table of assets, components, versions and owners, each with its source and its age.
Advisory collection and normalisation
Takes in CERT-FR advisories, entries from the European Vulnerability Database (EUVD) and the bulletins of the vendors named in the contract, together with the reports you open to it; normalises them into a single format and keeps, for every value, its source and its publication date.
Vulnerability-to-asset matching
Matches each advisory to the assets carrying the affected product, with the observed version, the affected range, a mandatory confidence level and the evidence retained.
Explainable contextual prioritisation
Builds the order of work with a versioned deterministic engine: every score recomposes on screen factor by factor, and every policy rule displays its identifier.
Remediation plan
Writes, for each case, the action, the owner, the due date taken from your policy, the required tests and the rollback — and flags the case that is missing one of the four.
Tickets, changes and escalations
Prepares the ticket and the change request in the form you already produce, with no duplicate when a case is replayed, and drafts the escalation as a due date approaches.
Patch checks before it goes on
Checks the patch's approved provenance, its prerequisites, the tests it must pass and the pilot group it proves itself on before it is proposed to the whole estate.
Guarded orchestration
Shows in simulation what would be triggered, case by case. A real write requires a confirmed asset and version, an approved patch, passing tests, a compliant window, an available rollback and a recorded approval.
Verification after remediation
Reads the next inventory to confirm the effect obtained, separates a complete fix from a partial one and names the assets left open with their reason.
Dated exceptions and compensating controls
Drafts the exception with its scope, compensating controls, owner, approver, expiry date and revocation conditions — and reopens the case at the due date.
Bills of materials and exploitability statements
Uses the software bills of materials (SBOM) and exploitability statements (VEX) you or your suppliers produce, ties each component to the delivered version and prepares the product-security case.
Evidence and steering
Logs source, decision, case, exception, action, acknowledgement and delay, and puts its own inventory coverage at the top — the file an internal auditor or a statutory auditor asks for.
Sovereign AI
The hosting and confidentiality foundation the agent rests on.
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.
Cybersecurity & logs
Correlating the events of an incident and qualifying an alert starts from a fact observed in your logs; the vulnerability cycle starts from an advisory published outside.
Cybersecurity & logs from 311 € excl. VAT / month Discover the agent →Advanced technical support
Resolving a request raised by a user belongs to support; here, cases exist whether or not anyone raises them, with due dates that run while nobody calls.
Advanced technical support from 291 € excl. VAT / month Discover the agent →Code generation & review
Writing the fix for a dependency happens in the repository; knowing on how many assets that dependency is deployed, and how exposed they are, happens here.
Code generation & review from 324 € excl. VAT / month Discover the agent →Regulatory control
Showing that an obligation is met, and keeping the file that proves it, belongs to compliance control; here the material is technical — an asset, a version, a patch — and the verification record produced feeds that file rather than replacing it.
Regulatory control from 371 € excl. VAT / month Discover the agent →Technical support & documentation
Writing and maintaining operational documentation belongs to that agent; here documentation is an input — maker data sheets, release notes — and the output is a dated change file, ready to sign.
Technical support & documentation from 344 € excl. VAT / month Discover the agent →Testing & software quality
Designing and running an application test campaign belongs to that agent; here regression tests are a CONDITION of the deployment window, required on file and checked before the change goes out.
Testing & software quality from 272 € excl. VAT / month Discover the agent →In 30 minutes we identify the most relevant agent — without oversizing the project.
See the agent at work
5 everyday 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 companyVergaray Participations — active holding company, six subsidiaries
- Sector
- Active holding company, NAF 64.2 — six subsidiaries: one manufacturer, two service companies, three distributors
- Headcount
- 31 people at head office, two of them in IT. No CISO, no security analyst. 1,240 employees across the six subsidiaries
- Who it serves
- The six subsidiary boards, a supervisory board, two statutory auditors
- Order of magnitude
- About 900 endpoints and 140 servers spread across the six subsidiaries; quarterly financial consolidation; treasury centralised at head office
- Tools already in place
- Three configuration databases out of six kept current, a weekly scanner at two subsidiaries, the head-office ticketing tool, the internal-control document store — the agent reads what the group opens to it, nothing is replaced
- The manufacturing subsidiary
- Fournils de Vaubourg — one site, two production lines running three shifts, 3 people in IT and 2 automation engineers; owner of the legacy regulatory-reporting server
- The plant's constraint
- One single planned line stop night a month — that constraint, not a vendor rating, governs the order of work on the manufacturing scope
- Who decides
- The chief financial officer arbitrates priorities and any risk acceptance; the head-office IT manager prepares the cases; each subsidiary director remains the owner of their assets and alone authorises changes to them
- The improvement points
- No single version table across the six subsidiaries; nobody at head office knows the version of the shared identity gateway; the regulatory-reporting server is out of vendor support
Vergaray Participations steers six subsidiaries that share neither an inventory tool, nor a patching rhythm, nor an owner. Head office receives vendor advisories like everyone else and has no way of saying, within a week, which subsidiary is concerned. The agent reads the three configuration databases that are kept current, the weekly scanner reports of two subsidiaries, the head-office ticketing tool and the group provider register. It matches, quantifies, explains and prepares — the chief financial officer arbitrates, and each subsidiary director authorises whatever touches their machines. The exchanges below cover one week, from advisory intake to evidence file. The fifth tab opens the MANUFACTURING scope of the subsidiary that already owns the regulatory-reporting server: four plant assets, one stop night a month, and safety impact as a priority factor.
This company, its figures and the exchanges that follow were invented for the demonstration. They illustrate a common situation; they describe no real client.
Fictional simulation — not a client result
This demonstration uses entirely fictional data. No system is scanned or changed.
The sovereign AI foundation chosen at quotation — local inference or an isolated resource hosted in France — carries this agent: your exports and your advisories stay inside that space.
The scope loaded:
· 4 group assets: the consolidation portal, the centralised treasury hub, the shared identity gateway serving all six subsidiaries, the legacy regulatory-reporting server.
· 4 fictional advisories, prefixed DEMO-CVE so that none can be mistaken for a real vulnerability.
· 5 simulated sources: the subsidiaries' configuration databases, the weekly scanner reports of two of them, the head-office ticketing tool, the group provider register, the internal-control document store.
· Advisory collection and normalisation, already done: the 4 advisories arrive in four different shapes and leave in one — a product, an affected version range, a source, a publication date. That normalisation is what makes line-by-line matching possible.
· Demonstration policy demo-policy-1.0, with its four thresholds and six priority rules — yours would apply, not mine.
And the two gaps, named:
· The version of the shared identity gateway is unknown — it is operated by a provider under a group framework contract, and none of your databases carries it.
· The regulatory-reporting server has no owner at head office: it belongs to the manufacturing subsidiary, which alone authorises changes to it.
An unknown value stays unknown throughout. It is neither healthy nor fixed, and you will see that it blocks a closure rather than manufacturing one. deposit-of-sources_vergaray-group.pdfINPUT DOCUMENT · 5 exports deposited, 4 advisories, 0 writes
⛓ Sourced · 5 exports deposited on 07/09, ages shown, group threshold 72 h
Here is the reconciled cyber inventory of the group first: your five exports come back as a single table — asset, component, version, owner, source and age of the data. Everything that follows rests on that reconciled table.
Inventory coverage is the measure that governs all the others: an asset missing from an inventory is invisible to me, and it is precisely the forgotten asset that causes trouble. The attachment gives you coverage subsidiary by subsidiary, with what each one lacks.
What I propose, and the arithmetic: the four group assets head office operates itself are 100 % covered, because you keep that inventory. The three subsidiaries without a current database represent, in this fictional scenario, about 380 endpoints and 46 servers on which I can affirm nothing. Rather than opening six inventory projects at once, I propose starting with the manufacturing subsidiary: it hosts the out-of-support regulatory-reporting server, so it is where the ignorance costs the most today.
The decision is yours, and it is taken on a figure: three inventory projects, or one, on the asset you already know is out of support. inventory-coverage_six-subsidiaries.pdf3 entities out of 6, 2 named gaps
⛓ Sourced · inventory coverage given ahead of any score
Fictional simulation — not a client result
· DEMO-CVE-F01 → consolidation portal, observed version 6.1.0, affected range < 6.1.1. Affected, confirmed, confidence 0.99. Evidence: the version recorded in your configuration database, and that week's scanner report.
· DEMO-CVE-F02 → centralised treasury hub, version 4.7.3, range < 4.7.4. Affected, confirmed, confidence 0.98.
· DEMO-CVE-F04 → regulatory-reporting server, version 12.0, range 12.x. Affected, confirmed, confidence 0.94, and the asset is out of vendor support — no patch is published for it.
· DEMO-CVE-F03 → shared identity gateway: under investigation, confidence 0.35. The version is unknown. The advisory is severe and declared actively exploited in the scenario; that is exactly why I refuse to show it as confirmed on a product-name match alone.
A fuzzy match is never presented as a confirmed one. matching_four-cases.pdf3 confirmed matches, 1 under investigation
⛓ Sourced · versions read from the configuration database and the scanner report
It is classed « review required » by rule PR-APP-UNK-001, which is evaluated before any other: a case under investigation gets no numeric score. The absence of a score is information, not a zero — a zero would have sent it to the bottom of your list.
What I have already prepared, and attached: a request for evidence to the provider, drafted, addressed to the right contact under the framework contract, asking for three things and nothing else — the version in service, the date of its last deployment, and the status of DEMO-CVE-F03 on that version, as a dated, signed exploitability statement. The software bills of materials (SBOM) and exploitability statements (VEX) your suppliers produce come in through the same door: I tie each component to the delivered version, and the product-security case fills up as the answers arrive. The group provider register gives me the contact; the letter is ready and goes out when you approve it.
And I have set the consequence: until that evidence is on file, closure is blocked. Not deferred to a reminder that gets forgotten — blocked, with the date on which it is missing.
What this changes for you: a holding company does not scan a provider's machine, it holds a contract against it. I turn a technical question you cannot ask into a contractual request you can, and I track its deadline. evidence-request_identity-provider.pdf3 questions, 1 deadline, closure blocked
✎ Framing · contractual request drafted, closure blocked while evidence is missing
Fictional simulation — not a client result
This is contextual prioritisation, and it is explainable line by line: the order comes from YOUR context — exposure, criticality, business impact, known exploitation — and every score displays the factors that produced it.
· Consolidation portal — DEMO-CVE-F01 — score 98 out of 100, immediate review. Origin of the priority: rule PR-KEV-001 and the threshold, both. The rule alone would have sufficed: a vulnerability declared actively exploited on an exposed, critical asset is raised to immediate review even when another metric is missing.
· Regulatory-reporting server — DEMO-CVE-F04 — score 51, planned. Origin: rule PR-EOL-001 and the threshold. The asset is out of support, which adds 10 points and triggers a priority floor.
· Treasury hub — DEMO-CVE-F02 — score 54, planned. Origin: the threshold alone.
· Shared identity gateway — DEMO-CVE-F03 — no score, review required.
Two points that matter here: the treasury hub scores 54 although its technical severity is 7.6 — because it is barely exposed (0.4), and it is your group's context, not the vendor's rating, that produces this ordering. And a policy rule can RAISE a priority, never lower it silently: it displays its identifier, here PR-EOL-001, and its explanation. priority-calculation_consolidation-portal.pdfScore 98 recomposed factor by factor
⚙ Computed · policy demo-policy-1.0, every score recomposable on screen
The arithmetic first, to the point: the consolidation portal scores 98 because it accumulates four things the treasury hub does not — known exploitation (25 points), maximum exposure (15 points), an exploitation probability of 0.91 (9.1 points) and an available, trusted fix (5 points). The treasury hub sits behind your segmentation: exposure 0.4, worth 6 points instead of 15, and no known exploitation, worth 0 instead of 25. The 44-point gap comes from there and nowhere else.
What I propose, quantified: if your finance department holds that centralised treasury must rise whatever happens, that is written as a policy rule, not as a score adjustment. For instance: any asset in the « Centralised treasury » service has a floor priority of « expedited ». The rule would carry an identifier, an explanation, a version, and it would be tested like the other six.
I would advise against raising the weight of business impact: it is already at 10 on the hub, its maximum, and raising it would also lift the three distribution subsidiaries — you would get eight immediate reviews instead of one, which amounts to having none.
Weights and thresholds are administered, versioned and tested. No conversation with me changes them, and that is what makes your ordering defensible in front of your supervisory board.
✎ Framing · weights and thresholds administered, versioned and tested — never by conversation
Fictional simulation — not a client result
How I know its versions, since I scan nothing: from the inventories the subsidiary opens to me — maintenance management system, intervention records, maker data sheets — and from what the site historian declares. No active scan is run on a line in production, and that is not a setting: a scan on a running controller can disturb the process.
The four assets: remote-maintenance gateway, line 2 engineering workstation, packaging controller no. 7, site historian.
And the factor your five other subsidiaries do not have: safety impact enters the priority calculation, with a weight of its own. The packaging controller carries the maximum value, because a fault on it reaches an operator, not a spreadsheet.
Three of the four cases therefore carry a HIGHER priority than their score would give, and every rule shows its identifier:
· Remote-maintenance gateway — 100 — immediate review (PR-KEV-001 and threshold).
· Line 2 engineering workstation — 60 — expedited by PR-OT-HIGH-001: safety impact 0.8 and rollback not ready yet.
· Packaging controller no. 7 — 56 — expedited by the same rule: safety impact 1.0 and no patch published.
· Site historian — 49 — planned by PR-OT-SAFE-001.
The principle fits in one sentence: a policy rule raises a priority, it never lowers one silently, and it does not touch the score. 49 stays 49, and the displayed priority carries the name of the rule that raised it — you see the calculated risk AND the safety decision, without either disguising the other. safety-rules_four-industrial-cases.pdf3 priorities raised, none lowered
⚙ Computed · safety impact taken as a factor, rules named
What produces its score of 100: a vulnerability declared actively exploited (25 points), an exposure of 0.9 because the gateway is reachable from outside (13.5 points), maximum criticality (15 points) and a safety impact of 0.7 (7 points). The raw calculation gave 103.8, bounded to 100 — a bound is a bound, not a convenient rounding.
What I prepared, and the order is the point: isolation first, patch second. Restricting access to a time window agreed with the maker and to its declared addresses requires no line stop. The patch itself enters the stop night, with its tests and its rollback available.
You get the exposure reduction straight away, without spending your night, and the maintenance contract stays served on a written, revocable slot.
Two things isolation does not do, and I would rather say them: it does not close the case, and it does not lower the score — only a VERIFIED compensating control, backed by a dated attestation, subtracts points. And I change no access rule on my own initiative: I draft the slot request, your production manager signs it. isolation-plan_remote-maintenance-gateway.pdfExposure reduced, 0 minutes of line downtime
✎ Framing · isolation prepared, no access rule changed by the agent
What I prepared, awaiting two signatures: three compensating controls — restriction of the administration path, targeted monitoring of access to the controller, removal of the controller from the segment reachable from office workstations — each with what it reduces and what it does not.
The two signatures are not interchangeable: the quality and safety manager, because the measure touches equipment whose fault reaches an operator, and the production manager, because implementing it changes how the line runs. Dual approval on assets with a high safety impact is configurable, and it is enabled here.
What I write on the maker's side: a request for a written position on DEMO-CVE-O03, with the same three items as for any third party — affected version, whether a patch is planned, date. The request is drafted, not sent: it goes out when you approve it.
And here is what enters the stop night, and what does not. In goes the gateway at 3.4.1, tests written and rollback available. Out stays the engineering workstation, whose patch exists but whose rollback is not ready: the orchestration stays guarded — I show in simulation the change that would go out, and the guard holds the submission back while displaying its reason and its unblocking action. An engineering workstation without a rollback, on a line running three shifts, would make the line the gamble — and that block is your own rule, applied without a silent exception. The historian, for its part, comes out of the night: it does not interrupt the line, so I hand you that time back. mitigation_packaging-controller-7.pdf3 compensating controls, 2 signatures awaited
✎ Framing · compensating controls prepared, two signatures awaited
Fictional simulation — not a client result
· Consolidation portal — emergency change ready. Action: upgrade to 6.1.1. Owner: head-office finance. Prerequisites, regression tests on quarterly consolidation, rollback available, proposed window, communication to the six subsidiaries drafted, expected evidence named. Approval: pending.
· Treasury hub — planned change within a window, same structure, rollback available.
· Regulatory-reporting server — no patch exists. I have therefore prepared a mitigation case and a dated exception, attached: exact scope, reason, described risk, three compensating controls, owner, approver, start date, expiry date, review date, revocation conditions. The exception expires; it never renews itself — at the due date the case reopens.
· Shared identity gateway — the evidence request has gone out, closure stays blocked.
One point of your governance that I apply: the reporting server belongs to your manufacturing subsidiary. The exception is therefore addressed to its director, not to head office — and your CFO appears on it as the approver of a group risk, not as the owner of the machine. dated-exception_regulatory-reporting.pdfScope, approver, expiry date, review
✎ Framing · changes drafted, decision with the asset owner
In this scenario's simulation:
· Consolidation portal — remediation verified. Version 6.1.1 observed, simulated check negative, simulated change successful. I propose closure; you pronounce it.
· Treasury hub — remediation verified, same pattern.
· Regulatory-reporting server — exception pending approval. No closure, and that is the right outcome: an unapproved exception is not an exception.
· Shared identity gateway — evidence missing. The provider did not answer in the simulation. State: evidence missing. The case stays open, the deadline runs, and the escalation is prepared for the framework-contract owner.
And on the manufacturing subsidiary's side, in the same simulation: the remote-maintenance gateway is isolated, then fixed at 3.4.1 — remediation verified, closure proposed; controller no. 7 stays open, compensating controls awaiting two signatures and a dated review. The statement carries them in the same table, under the same rules.
What you hold at the end of the week, and that is the real deliverable: three demonstrated fixes across two scopes, one exception carrying an end date, two cases waiting on a named piece of evidence or a named signature — and a dashboard that puts its own coverage, its missing data and its low-confidence matches at the top, not in a footnote.
A partial fix never becomes an overall success, and missing evidence never becomes a closure. That is what makes the statement usable the day your statutory auditor asks for it. verification-statement_week.pdfOUTPUT DOCUMENT · 3 fixes verified, 0 forced closure
⛓ Sourced · effect confirmed on the next inventory, never on the order sent
Your case is not here? That is exactly what a 30-minute conversation is for. Discuss your project →
The stages of your AI agent project
Audit & scoping
30 minutes to target the use case with the best return.
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
Design
We design the agent and its guardrails.
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
Rollout
Going live and training your team.
Operation
Continuous supervision and improvement.
What does an AI agent bring to your patch management?
An advisory whose affected asset, observed version and owner are all visible is settled in a minute; a vendor bulletin cross-checked by hand takes a week.
! What is at stake
NIST describes patch management as preventive maintenance to be planned, not as a reaction to an event (NIST, SP 800-40 Rev. 4, “Guide to Enterprise Patch Management Planning”, published April 2022). The work that jams is not the decision: it is knowing whether the affected product runs anywhere in your estate, in which version, exposed how, and who answers for the machine. That work is systematic, and it can be prepared.
✓ Our answer
Your asset owners receive cases that are already worked up: the advisory, the asset, the observed version with its source, the confidence level, the order of work recomposed factor by factor, and the change drafted with its tests and its rollback. They decide, and their reasoned decision is kept with its date and its author. An unknown version stays unknown: it blocks a closure rather than manufacturing a certainty. Data hosted in France on an isolated resource; the AI model is called at its publisher, except with the Sovereign model option. With the 100% Sovereign package, the map describing your versions, and therefore your weak points, does not leave the company.
Your version map: sovereignty & confidentiality
The list of your unpatched assets says where your weak points are. Keeping it confidential is itself a security matter; here is how that is held.
Local inference
With the 100% Sovereign package, the agent runs on a machine inside your organisation: no inventory, no bill of materials and no scanner report leaves the network.
Hosting in France
Otherwise, with the Agility and Serenity packages, a dedicated, isolated resource hosted in France, under French law: data hosted in France; the AI model is called at its publisher, except with the Sovereign model option.
Reduced extraterritorial exposure
For your version map and your unpatched assets, the architecture aims to reduce exposure to the Cloud Act and FISA 702; location in France or in the European Union does not on its own guarantee immunity.
Entities kept apart
Each subsidiary, entity or site has its own space: a remediation case never shows another entity's assets, and roles follow that separation.
Decisions kept
Every decision keeps its author, date, reason and the policy version applied; encryption, role-based access (RBAC) and logging usable in an audit. Read, write and approval rights are separated.
AI Act: governed deployment
The agent carries out what you have authorised; no patch deployed, no risk accepted and no case closed automatically; traceability and human oversight 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.
How many advisories can a team work through?
By taking on the matching, the search for the owner and the reconstruction of versions, the effort moves towards the decision. How far the gain reaches depends on your estate and is confirmed by a pilot.
Four commitments that matter for your estate
Related resources
Your questions, our answers
Does the agent replace our vulnerability scanner or our asset management?
Can it deploy a patch automatically?
How does it connect to our tools?
Which advisory sources are covered?
What does it do when an asset's version is unknown?
And when no patch exists?
Does it run active scans, or penetration tests?
Does this page prove our compliance with any text?
Other agents for IT
Let us size the potential on your next batch of advisories
30 minutes to scope your inventory sources, your environments and your owners — hosted in France, supervised, no commitment.