From the counter
52 posts
-
Small firms are 96% of ransomware victims: why MSPs should rank agent-running developer machines first
DBIR 2026, as summarised by CRI, puts small firms at 96% of ransomware victims, with 73% of victims hit by stolen credentials first. MSPs should rank client machines by the credentials they hold, and agent-running dev laptops hold the most.
-
Your clients' staff are installing AI agents: an MSP's first 90 days of agent governance
MSP AI guidance covers chat tools and data leakage. Clients now run coding agents that install packages and load MCP servers. A 90-day plan - discover, set a default policy, enforce on managed endpoints, report.
-
Your MSP's AI agents have admin on your tenant: seven questions clients will ask, and good answers
When an MSP's own AI agents act inside client tenants, clients will ask about scope, oversight, data flow and exit. Good answers point to evidence (an inventory, scoped credentials, logs, a tested kill switch), not to a policy PDF.
-
The MCP spec's own security MUSTs, read by a buyer: five requirements to make any MCP vendor prove
The MCP spec already sets security obligations: no token passthrough, per-client consent, verified requests, exact-command consent, safe URL handling. Ask vendors to prove each, in the spec's own words.
-
Approved last month, malicious today: a re-verification cadence for MCP servers and skills
Install-time vetting decays the moment a server or skill changes. Tie every approval to an immutable version or hash, re-check on every change, and sweep on a schedule. Cadence by artifact type inside.
-
The official MCP Registry has no security fields: what a registry listing does and doesn't tell you
An MCP Registry listing proves a publisher controls a namespace and, for packages, the package. It does not prove review, safe code, or control of a remote URL. The schema has no security field at all.
-
Allowlist, denylist or both? Designing MCP server policy after GitHub's enterprise allowlists
An allowlist stops servers nobody approved. A denylist stops approved servers that later turn bad. MCP policy needs both, matched on URL or command, never on name alone.
-
Malicious packages are not vulnerabilities: why your CVE scanner can pass a package that is malware by design
Malware gets a malware advisory, not a CVE, and lives in separate datasets. In our 15 October test, npm audit flagged three of four known-malicious versions; the fourth is listed in OSV but not in GitHub's database.
-
Tabletop: a malicious MCP server in your engineering org, with the kill-switch question every team fails
A 60-minute tabletop built from the postmark-mcp case. Five injects, a scoring sheet, and the question most teams cannot answer yet - how fast can you turn one MCP server off on every machine?
-
Lethal trifecta audit: a worksheet to find agent setups that mix private data, untrusted content and egress
Exfiltration risk comes from a combination: private data, untrusted content and a way to send data out, in one agent session. This worksheet audits each configuration for all three and shows which leg is cheapest to break.
-
Known bad, no known bad, unknown: a three-state policy model for agent artifacts
Most agent artifacts have never been checked by anyone. Splitting verdicts into known bad, checked with nothing found, and never checked lets policy block, log or ask a person without calling unreviewed code safe.
-
Unpatched edge devices sit behind 29% of opportunistic attacks: a KEV-only alert rule an MSP can staff
Alert clients only when a CISA KEV entry hits an internet-facing device or remote-access tool they actually run. In 2026 that has meant about 1.5 catalog entries a week to match, not the 1,200-plus CVEs a week a 66,000-CVE year implies.
