Engineering deep-dive
Would we have caught the last 60 days?
We took the agentic incidents of the last two months and asked, honestly, which Sekeye control would have surfaced each one, and which phase that control actually belongs to. Three surfaced cleanly, two were made discoverable, zero were stopped.
Why write this down
It is easy to publish a campaign page per incident and imply coverage. This note does the harder version: for each incident, which control would have surfaced it, whether that control is shipping today or on the roadmap, and where the honest answer is "we would not have stopped that."
Two rules for reading this:
- See is shipping. Discover every agent, MCP server, skill, and local model across laptops and servers; compute blast radius per agent; match live threat intel including AI-infrastructure CVE and KEV; produce remediation and credential-rotation guidance. The agent is read-only.
- Govern and Catch are not yet shipped. Allowed-tools enumeration, config-drift alerting, Ask-to-Install for agent surfaces, and the optional inline MCP-proxy sit in Govern. The flight recorder and rogue-behaviour signals sit in Catch. Both are roadmap. Anywhere the honest answer depends on one of those, it is labelled.
All incident details below are cited from research collated in this project and are not independently verified.
LiteLLM MCP RCE (CVE-2026-42271, CISA KEV)
Control: version-range matching against the pypi and container-image
inventory, with the KEV signal escalating it into the P0 band.
Phase: shipping. This is the closest thing to a clean answer in this note, it is an exposure-engine finding on an artefact we already collect, and the KEV listing is in the intel feeds.
What it would not have done: nothing here stops exploitation of an unpatched proxy. It shortens the window between the KEV listing and someone knowing which hosts are affected, and it names the credentials in scope for rotation before the incident call starts.
Amazon Q workspace config exfil
Control: enumeration of MCP server definitions per host, including workspace-scoped configs, with egress destinations surfaced as a risk indicator.
Phase: discovery is shipping. The control that would actually have mattered here, config-drift alerting when a repository introduces a new agent tool definition, is Govern, and is roadmap.
What it would not have done: the exfiltration happens in the seconds after the config loads. A read-only inventory agent reporting on its next snapshot is too late for that specific call. What it changes is that the config is discoverable at all, and that the rotation scope is known rather than guessed.
MCP stdio transport RCE
Control: agent-client version inventory across Cursor, VS Code, Windsurf, and Claude Code, matched against the affected build ranges.
Phase: shipping. This one is a genuine strength, because the hard part is not the patch, it is knowing which client versions are deployed across a fleet of auto-updating agent IDEs. That question is normally unanswerable.
What it would not have done: if a host was on an affected build when the advisory landed, code execution had already been possible. We narrow the population and evidence the closure.
JadePuffer (agentic ransomware via Langflow CVE-2025-3248)
Control: discovery of AI-infrastructure services as installed software on servers, plus CVE matching with exploit-availability signals.
Phase: shipping for the discovery and matching. The rogue-behaviour signals that would flag an agent enumerating and staging are Catch, and are planned rather than built.
What it would not have done: this is the clearest boundary in the note. The ransomware payload executing is EDR's job, and the cloud-side impact is cloud security's job. What Sekeye addresses is the exposed, unpatched, uninventoried Langflow instance that let the agent in, a known CVE on a service nobody had recorded as infrastructure. We shrink the exposure that leads in. We do not claim the kill.
Hugging Face agentic infrastructure breach
Control: inventory of server-side agents with a blast-radius profile, filesystem scope, credential names in the environment, shell, egress, ranked so the over-credentialed agents surface ahead of the harmless ones.
Phase: shipping for inventory and blast radius. Constraining what an agent may do is Govern, and is roadmap.
What it would not have done: an agent that is legitimately credentialed and behaving within its granted scope looks normal to an inventory-and-exposure layer. The value is upstream: fewer agents holding production credentials than before, and a record of which ones did.
The honest tally
Of five incidents, the shipping product would have surfaced the exposure in three cleanly (LiteLLM, MCP stdio, Hugging Face inventory) and would have made two discoverable without changing the outcome on the day (Amazon Q, JadePuffer). Zero would have been stopped by the agent, because the agent is read-only and does not sit in the execution path.
That is the accurate claim, and it is still a useful one. Most organisations cannot currently answer "which agents run on our fleet, what credentials do they hold, and which of them are on an affected version" at all. Answering that question quickly is what shrinks the exposure the next incident walks through.
The controls that would change outcomes on the day, gating, allow-deny, Ask-to-Install, the inline MCP proxy, the flight recorder, are the roadmap, and we would rather say so here than imply them in a headline.