Mayfly Is OTM Cyber's Answer to the Agentic SOC Moment

When I started building Mayfly, the phrase agentic SOC came later.

The starting point was an analyst on shift with an alert in front of him, a customer environment to protect, and too many places to look before he could make a sound judgment.

The work is rarely one clean signal. It is usually a stack of context that has to be assembled before the real decision can be made:

• alerts and related detections,
• case notes and prior customer history,
• endpoint, identity, and network clues,
• detection history and customer-specific normal behavior,
• the question of what actually needs attention right now.

That is the part of SOC work people underestimate. A SOC can struggle because the evidence is scattered, the queue is noisy, the history lives somewhere else, and the analyst has to rebuild the same context over and over while the clock keeps moving.

That was the problem Mayfly was built around.

The operating pressure is now measurable

The case for agentic security operations is now supported by operational data. In February 2026, Microsoft published Omdia research that put numbers around what many analysts have felt for years:

• SOC teams were moving across an average of 10.9 consoles.
• Only about 59 percent of tools were pushing data into the SIEM.
• 66 percent of SOCs were losing at least 20 percent of the work week to aggregation and correlation.
• 46 percent of alerts were false positives.
• 42 percent of alerts were going uninvestigated.

The same research reported that 91 percent of security leaders had experienced serious events in the prior year, more than half had experienced five or more, and 75 percent worried their SOC was losing pace with new threats.

Those are operating metrics. They describe analyst capacity, visibility, queue quality, and the practical limit of a model that depends on people stitching context across too many tools by hand.

For a managed SOC, the effect is compounded. The analyst is working across customer environments, each with its own normal behavior, service dependencies, escalation expectations, and tolerance for disruption. In public safety, emergency communications, government, and critical infrastructure, a sloppy decision can become a service-impacting event for people who are already operating under real-world pressure.

Why 2026 is the moment

2026 is different because several pressures are converging at the same time.

1. The old alert-queue model is visibly overloaded. More tools often created more places to check, more duplicate evidence, and more partial views of the same activity. A human analyst can work hard and still lose time to mechanics that should already be assembled before the first decision point.
2. Attackers are using speed and volume against defenders. IBM's 2025 Cost of a Data Breach work reported a global average breach lifecycle of 241 days and a record U.S. average breach cost of USD 10.22 million. Organizations using AI and automation extensively in security saved an average of USD 1.9 million and reduced breach lifecycle by an average of 80 days.
3. AI itself has become part of the risk environment. IBM reported that 13 percent of organizations had breaches involving AI models or applications, and 97 percent of those organizations lacked proper AI access controls. It also reported that 63 percent of breached organizations either did not have an AI governance policy or were still developing one, and that 16 percent of breaches involved attackers using AI tools.
4. The architecture conversation has matured. Elastic described 2026 as a practical inflection point because agent frameworks, defenses against agent-specific attacks, and executive expectations for transparent and auditable outcomes are all maturing.

Research is moving in the same direction. The 2026 AgentSOC framework describes an operating loop for normalizing alerts, enriching context, generating hypotheses, validating feasibility, and producing policy-compliant response options. AgenticCyOps focuses on tool orchestration and memory as trust boundaries, with capability scoping, verified execution, memory integrity, and access-controlled data isolation. Its authors reported at least a 72 percent reduction in exploitable trust boundaries compared with a flat multi-agent design.

That combination is why the phrase agentic SOC is landing now. The need is measurable. The architecture is becoming more serious. The governance risk is visible. The work has moved from a future idea to an operating decision.

The agentic SOC is an operating model

An agentic SOC is a working model where specialized agents help with defined parts of the security operations loop.

• One lane can group related detections and reduce noise.
• One lane can enrich observables with endpoint, identity, network, and customer context.
• One lane can compare current activity against prior case memory.
• One lane can check reasoning before customer-visible language or case-changing action lands.
• One lane can prepare bounded action when policy allows it.

The important word is defined. Agents are useful when the task, tool access, memory boundary, approval requirement, and evidence trail are clear.

In a SOC, ambiguity is expensive. Before an agent can help safely, the operation needs clear answers to a few basic items:

• the tool the agent is allowed to query,
• the authority under which it is querying that tool,
• the customer environment in scope,
• the evidence supporting the conclusion,
• the action policy: allowed, review-required, or blocked.

That is where many automation efforts have struggled. They either stay too narrow to relieve the analyst, or they reach for autonomy before the surrounding controls are ready. A useful agentic SOC sits between those failures. It gives the analyst more completed work at the beginning of the case, while preserving the review and accountability that security operations require.

Why Mayfly is the right answer for OTM Cyber

Mayfly is well matched to this moment because it was built from inside the work, with OTM Cyber's SOC workflow in view from the beginning.

OTM Cyber already had the operating reality in front of us:

• CyberSystem grids and customer-specific context,
• endpoint and identity signals,
• historical cases and detection history,
• analyst notes and escalation paths,
• the steady pressure of a 24/7 queue.

Mayfly was built to help with that actual flow. It supports the way our SOC has to work for the organizations we serve.

At the center of that design is a simple standard I keep coming back to: if the output does not make the human better, faster, or more prepared, it is not progress.

Mayfly helps with the first pass that consumes too much analyst time. It can deduplicate related detections, assemble observable context, pull in customer-specific patterns, compare against prior cases, draft a case narrative, recommend a disposition, and identify where the work needs human judgment.

The analyst should be able to avoid spending the first stretch of every routine investigation proving that the same noisy pattern is the same noisy pattern. Mayfly can do that work and show its reasoning.

It also helps with consistency. A managed SOC runs across shifts. Different analysts may see the same customer at different times. Mayfly gives the workflow a stronger memory of what has already been checked, what has been noisy before, what a customer environment normally looks like, and what policy allows. SOC quality depends on repeatable decisions under time pressure as much as strong one-off investigations.

What Mayfly does before the analyst has to decide

The most useful work often happens before the final judgment. Mayfly is designed to bring the case closer to that point.

• Triage: It can group related detections, reduce duplicate noise, and help separate familiar low-value patterns from items that deserve attention.
• Enrichment: It can gather context from CyberSystem, endpoint providers, identity data, historical case memory, and grid-specific knowledge so the analyst begins with a fuller picture.
• Reasoning support: It can organize evidence, draft a defensible narrative, surface uncertainty, and recommend a disposition while leaving the decision with the analyst.
• Detection workflow: Where policy allows, it can prepare detection tuning work for review so noisy conditions are addressed rather than tolerated forever.
• Escalation discipline: It can park, route, or escalate work based on confidence, policy, customer context, and the need for human review.

These capabilities map to the exact places where SOC time disappears: looking up the same observables, switching tools, reconstructing prior history, writing the first version of the case, and deciding whether a noisy alert is safe to close or needs another look.

The guardrails are part of the product

The agentic SOC conversation can make autonomy sound like the main achievement. I see the achievement as useful autonomy under control.

Mayfly is designed for bounded autonomy. Different categories of work need different controls:

• Machine-speed support for repetitive, evidence-driven, lower-risk tasks when the inputs are clear.
• Review gates for customer-visible cases, detection policy changes, and operational response paths.
• Controlled operations for endpoint and server response actions.
• Traceability for detection tuning, case updates, recommendations, approvals, and follow-up work.

Vanguard, OTM Cyber's operator shell, is important for that reason. It gives the SOC queues, approvals, routing, visibility, and audit trails around the agent lanes. Mayfly can help move work forward, but Vanguard helps keep the work governable.

The SOC can see what is waiting, what was recommended, what was approved, what was changed, and where a human remained accountable. That structure matters to me because our customers are trusting us with environments where operational disruption has consequences.

The right answer is a faster path to a defensible decision, with enough visibility to explain how the SOC got there.

What changes for analysts and customers

For analysts, Mayfly changes the starting point. Instead of beginning with a blank case and a set of disconnected panes, the analyst can begin with:

• gathered context,
• related detections,
• prior history,
• suggested disposition,
• the parts of the work that still need review.

The job shifts upward toward validation, edge cases, detection quality, customer judgment, and real incident handling.

For customers, the benefit is steadier SOC execution:

• faster triage,
• richer investigations,
• fewer repetitive misses,
• better continuity across shifts,
• more consistent case handling across monitored CyberSystem grids,
• more analyst attention on the events that deserve it.

That is why Mayfly is OTM Cyber's answer to the agentic SOC moment. It fits the pressure the industry is now measuring, and it fits the operating model our customers need. It gives the SOC a way to move faster while preserving judgment. It strengthens the analyst rather than blurring responsibility.

The standard I keep coming back to

Some in the industry are calling 2026 the year of the agentic SOC. I understand why. The old model is under visible strain, and the statistics now match what analysts have felt on shift for years.

The real work is more grounded than the phrase:

• reduce noise,
• bring context together,
• preserve review,
• keep action auditable,
• make the human better prepared for the decision in front of them.

Mayfly is one step in that direction.

Sources referenced

• Microsoft Security, State of the SOC research summary, February 2026
• IBM, Cost of a Data Breach Report 2025
• IBM newsroom summary of 2025 breach findings
• Roy and Singh, AgentSOC: A Multi-Layer Agentic AI Framework for Security Operations Automation, 2026
• Mitra et al., AgenticCyOps: Securing Multi-Agentic AI Integration in Enterprise Cyber Operations, 2026
• Elastic Security Labs, Why 2026 Is the Year to Upgrade to an Agentic AI SOC, February 2026