Agentic Skills
A Skill is a packaged analysis workflow built on top of the MCP server. Where the server exposes individual tools for a client to call one at a time, a skill knows which of those tools a specific job needs, in what order, and how to weigh the results, so you can ask a plain question and get back a finished report instead of assembling one yourself from raw calls.
Every skill inherits the server’s read only guarantee. None of them can change anything in your account; they only read data that already exists and reason about it.
Using a skill
A client with both the Safetybits MCP server connected and these skill definitions available picks the right skill on its own from what you ask. You do not need to name one: asking what is going on with your alerts triggers alert triage, and asking which of those alerts you can safely ignore triggers noise reduction instead, even though both start from the same alert data. You can also invoke a skill by name if you want to be explicit about which one runs.
Every skill resolves which account it is working against before pulling any data. If you have access to more than one, it asks which one you mean before continuing.
Portfolio
Ranks every plant visible to the caller by how urgently it needs attention, for anyone managing more than one facility. It normalizes findings, vulnerabilities, and alerts by asset count, so a large, well run plant with a bigger raw count does not outrank a small, neglected one, and it treats a plant with little or no recent snapshot coverage as unmonitored rather than letting a dead sensor read as the cleanest site in the portfolio.
The report lists unmonitored plants first, since a dead sensor is worse news than a bad ranking, then ranks the remaining plants by findings per asset, with vulnerabilities per asset and alerts per asset per day shown alongside as separate signals rather than folded into one composite score. It always states how many plants are visible to the caller, never how many plants an organization has in total, since no tool exposes organization membership or name.
Invoke it with /safetybits-portfolio, or ask which of your plants needs attention first, or for a status update across all your sites. For depth on a single plant it flags, follow up with alert triage, vulnerability triage, or compliance gap analysis.
Fleet policy consistency
Checks whether policy has drifted across every plant visible to the caller, for a group CISO who wants to know whether all their sites run the same configuration without opening each one’s settings in turn. It runs the check cheapest and most mechanical first: sensor and agent version, then rule enabling, then compliance benchmark enabling, comparing every plant against the majority value the rest of the fleet already agrees on rather than against any fixed template, since the platform has no concept of an organization-wide default to check against.
A finding is always an observation, never a verdict. A plant scoping a rule differently, running an older sensor build, or leaving a benchmark disabled can be a legitimate difference driven by topology, a staged rollout, or jurisdiction, rather than a mistake, so the report asks whether a difference is intentional instead of assuming it is not. Where the fleet has no clear majority value, or where only one plant is visible to compare, it says so plainly rather than declaring one side correct or fabricating a comparison that has nothing to compare against.
The report lists each plant against the fleet’s majority sensor version, then any rule whose enabled state differs from the rest of the fleet, drilling into that rule’s scope and parameters only for the plants actually involved in the disagreement rather than comparing every rule at every plant up front, then any compliance benchmark enabled differently across the fleet, and closes with recommended next steps.
Invoke it with /safetybits-fleet-policy-consistency, or ask whether your plants are running consistent policy, whether one site has drifted, or whether all your plants are on the same sensor version.
Alert triage
Pulls the alert groups fired over a time window, the last 24 hours by default, and turns them into a triage report. It consolidates alert groups that share the same rule and resource so a repeat detection reads as one line instead of many, resolves each rule’s name, description and MITRE ATT&CK for ICS mapping, and uses that mapping, not raw occurrence count, to assign each finding a High, Medium or Low severity. Where a finding is ambiguous on its own, it looks up the affected resource or drills into the underlying alerts for more context.
The report opens with an executive summary, then a table of findings per severity tier with links back to each alert group in the console, and closes with an ordered list of recommended next steps.
Invoke it explicitly with /safetybits-alert-triage, or ask about alerts, alarms, or the security status of your OT network in your own words.
Noise reduction
Noise reduction tells you what alerts are “safe” to stop looking at. It aggregates alerts by rule, so a single detection firing across many devices reads as one row with an asset count, then makes a per rule call: Ignore, Keep, or Needs review.
The bar for Ignore scales with severity. A High severity finding, one mapped to a tactic such as Command and Control or Initial Access, stays Keep unless the evidence that it is spurious is overwhelming, while a Low severity finding such as expected discovery traffic clears the bar with ordinary supporting evidence. Volume on its own never earns an Ignore. The skill only recommends: there is no tool that changes an alert’s status, so acting on a recommendation still happens in the console.
Invoke it with /safetybits-noise-reduction, or ask which alerts you can dismiss, mute, or tune out.
Change and drift watch
Pulls the inventory change feed for a plant over a time window and separates real drift, worth a human decision, from scan noise. New or removed devices are counted net of flapping rather than as three events when a device drops and rejoins twice, and open port changes, IP, MAC and subnet reassignment, credential posture changes, model or vendor identity changes, and firmware, serial or config changes are called out as signal, while uptime counters, live diagnostic clocks, and hostname or PTR churn are dropped as noise the platform is expected to produce on every poll.
An empty change path is ambiguous on its own: a whole resource discovery or removal has no path, but so does an edit to a resource’s name, location, or tags, since those sit outside the nested diff tree the platform records for everything else. The skill checks the change type before assuming which case applies, and says so plainly rather than guessing when the values don’t clearly resolve one way. It is a first building block toward a management of change record, not a verdict: no tool exposes whether a change was authorized, so every signal finding is handed back as a question.
The report opens with an executive summary stating the window and how much of the change feed was actually reviewed, then breaks signal changes out by category (new, removed and forgotten devices, port changes, IP or MAC reassignment, credential posture, and identity or firmware changes), lists noise excluded for transparency, and closes with an ambiguous section for anything that doesn’t sort cleanly plus recommended next steps.
Invoke it with /safetybits-change-drift-watch, or ask what changed on the network this week, whether a device has drifted, or whether anyone has touched a PLC’s configuration.
Vulnerability triage
Pulls current CVE data and correlates severity, the CVSS score, the EPSS exploitation probability, and whether CISA lists the CVE as a known exploited vulnerability, against whether the affected resource actually exposes the vulnerable service and whether traffic to it has actually been observed. A severe CVE for a service the resource does not expose, or exposes but nothing uses, is downgraded in the report with the reasoning stated alongside it. A CVE on the CISA Known Exploited Vulnerabilities list stays High regardless of exposure.
You can scope the report to a whole account overview, a single resource’s full CVE list, or a single CVE’s blast radius across the fleet.
Invoke it with /safetybits-vulnerability-triage, or ask about CVEs, patch status, or exposure.
Compliance gap analysis
Pulls a plant’s compliance benchmark scores, per control findings, and accepted risk (muted) findings, and turns them into an audit ready gap analysis rather than a bare percentage. The platform’s headline compliance score is easy to misread three ways: it weighs every control equally regardless of how many assets fail it, it counts a muted, accepted risk control as a pass, and part of most frameworks is satisfied by an uploaded evidence file the platform never inspects. The report states all three caveats next to every score it shows, rather than presenting a number that looks cleaner than the posture behind it.
Alongside the score, it builds a risk acceptance register of every muted finding with its owner, date, and rationale, a gap list ranked by blast radius (the count of distinct assets behind a failing control, the only prioritization signal available since compliance controls carry no severity rating), and a pass rate trend across historical snapshots. Where NIS2 applies, it asks which national transposition, Spain or Slovakia, binds you rather than defaulting to the generic EU directive, since an auditor works from the transposition, not the directive.
Invoke it with /safetybits-compliance-gap-analysis, or ask about compliance posture, audit readiness, a specific framework such as NIS2, ENS, or IEC 62443, or what you have accepted as risk.
Incident timeline
Given one asset and a time window, merges that asset’s alert history, inventory changes, current CVE state, and compliance findings, muted ones included, into a single chronological candidate timeline, so an analyst investigating one device doesn’t have to run alert triage, vulnerability triage, and the activity feed separately and merge the timestamps by hand.
Its headline output is the accepted risk cross-reference: when a control was muted on the asset and an alert plausibly tied to the same exposure fires later, the report surfaces it up front, “this control was accepted as risk on this date, and N days later this alert fired involving the same exposure,” rather than leaving the analyst to notice the pattern unaided. That match comes from reading the control’s text against the rule’s text, not from a shared key the platform exposes, and the report says so; everywhere in it, a timing relationship is stated strictly as sequence, never as cause. Vulnerability state has no historical snapshot, so current CVE data is shown as standing context next to the timeline rather than placed on it, and network flows default to a 24 hour lookback ending now unless the window is pointed explicitly at the incident.
The report leads with the accepted risk correlation if one exists, then the merged timeline itself, then current vulnerability state, inventory changes excluded as noise, and recommended next steps.
Invoke it with /safetybits-incident-timeline, or ask to reconstruct what happened on a device, build a timeline around an incident, or see whether an alert was already known about before it fired.
Zone and conduit segmentation
Turns observed network traffic into a segmentation plan aligned with ISA/IEC-62443. It clusters the traffic it pulls into candidate zones, then overlays each resource’s role, criticality, and safety designation, since the standard groups resources by shared security requirement rather than by who happens to talk to whom. The resulting plan names zones and the conduits between them, flags the separations the standard requires (business networks kept apart from industrial control, safety systems kept apart from everything else, temporary and wireless devices in their own zone, anything reaching an external network called out explicitly), and surfaces smells such as a flat network with no segmentation or a resource that talks straight to the internet.
The skill stops at recommending a design. It never changes a resource, a firewall rule, or a VLAN, and any security level it proposes is preliminary, pending your own detailed risk assessment and sign off.
Ask about segmenting your network, drawing zones and conduits, or applying ISA/IEC 62443 to your architecture, or invoke the skill by name.