It's two o'clock at night. SentinelCore discovers an actively exploited vulnerability (CISA KEV catalog) on a server exposed in DMZ. No analyst is awake to read it. In the model we know today, that vulnerability waits for the beginning of the morning shift — and in the meantime stay there, exploitable. It is exactly the scenario that the architecture introduced with SentinelCore v1.2.0 it starts to make it passable, and it is worth understanding why.

One language to speak to the whole suite

With this version, SentinelCore's MCP (Model Context Protocol) server switches from read to read only phase 2: an authorized AI agent can no longer only consult vulnerabilities and risks, can Acting — change the state of a vulnerability, assign it to a team, start a scan — with the same authorization (RBAC, brooms, audits) that would have a human user logged in consoles. No shortcuts: every call of an agent passes by the same controls of a click on a button.

The most interesting part, however, is not the single tool. It is that this phase 2 is built over a Shared MCP contract at suite level — same protocol, same form of authentication, same structure of responses — thought from the first day to SentinelCore, FireDog and CyberSheppard together, not for an isolated product.

A scenario: when the risk results in an action, not in a ticket

Let's try to imagine where this direction takes. SentinelCore detects the KEV vulnerability we were talking about, calculates a risk score out of scale (real safety, not CVSS "plate") and reports it. An orchestrator agent, speaking the same MCP language, could:

• Today, already possible: question SentinelCore about vulnerability detail, check the asset and exposure, automatically assign the case to the competent team based on the declared skills — and, on the other hand, question the FireDog MCP server (already active, same shared contract) to know if that host is already covered by a rule, if it is among the blocked IPs, or what is the status of the target policy — everything without opening two different consoles. The MCP server of FireDog today is already phase 2, reading and writing — law rules, threats and IPs blocked, and can create new ones or modify them, the same orchestrator agent can close the circle: ask FireDog to apply a micro-regulation of containment on the exposed host — not a patch, but a gain of time while the human team intervenes — without anyone having to copy an IP from one tool to another.

It is not science fiction, and the cross-reading part between the two products is already a concrete reality today, not only an intention. The missing piece — the writing side FireDog — is the explicit goal of the same architecture, and SentinelCore v1.2.0 is the first product of the suite to arrive in full.

NIS2 and ISO 27001 are not just a check form

Those who must report NIS2 compliance (Article 21, risk management and accident management) or SGSI ISO/IEC 27001 (in particular A.8.8 control over technical vulnerability management) know the problem well: it is not enough have a tool for vulnerability management, needs to be able to demonstrate that the risk is traced, prioritized with a coherent and managed criterion within defined times.

Here the real risk/tier of SentinelCore (not the raw CVSS, replaced everywhere with this version) stops being an aesthetic detail of the reports: it is the evidence that the priority criterion required by NIS2 and ISO 27001 exists, is applied evenly, and is traceable — SLA for severity, complete audit logs, reports that can be performed in one click for the auditor or the CISO that must respond to the board.

What is needed for this not to remain theory

An instance that runs clearly in HTTP, without a safe way to be updated, is not the basis on which to build critical automation. For this reason v1.2.0 also bears the foundations: HTTPS enabled by default on each new installation, and a real in-place update mechanism (upgrade.sh) with automatic backup and rollback if something goes wrong — minimum requirement, not an option, if the goal is that SentinelCore becomes the central point from which to orchestrate actions, not only a dashboard to consult.

To complete the picture: granular notifications by event (email, Slack, Telegram) instead of the "all or nothing" of before, more reliable network discovery thanks to mDNS and NetBIOS, and a complete user manual in Italian — available online or downloadable in PDF. The complete technical changelog, with all the details and correct bugs along the path from beta to this release, is on GitHub.

To download SentinelCore v1.2.0 (track package, OVA appliance or qcow2), the reference page is sentinelsuite. dognet-technologies. online online.

---

It might also interest you

• Autonomous Response: How MCP and AI Agent are revolutionizing Cybersecurity with SentinelSuite
• Continuous Monitoring: why do Vulnerability Management not only mean performing scans. How to use Openvas + SentineCore for your CM
• CVSS and EPSS: Key Standards to Prioritize Security Vulnerability