# EasySOC

> An autonomous SOC investigation agent for small businesses running Microsoft 365. It
> investigates security alerts from Microsoft Sentinel and Defender XDR end to end, deploys
> inside the customer's own Azure tenant so their telemetry never leaves it, and is sold
> wholesale to managed service providers who resell it under their own brand.

The agent uses a supervisor model that frames each alert as competing activity hypotheses, nine
domain specialist agents that gather and interpret evidence, and a deterministic harness that
fuses that evidence with Dempster-Shafer theory and decides the verdict. The language model
reasons; it does not decide. Verdicts are delivered as Microsoft Teams Adaptive Cards and written
back to the customer's own incident records.

Most of this site is a build log: twenty-five chapters covering ten months from idea to working
system, written by Ivan Melekhin (https://www.linkedin.com/in/imelekhin/), who has spent
twenty-five years in cybersecurity and a decade running security operations centres and MSSP
teams across Asia-Pacific. It documents the decisions, the pivots, the measurements and the
failures — including a component built over weeks and then switched off after it was measured,
a go-to-market quarter that produced zero conversions, and the limitations the system still has.
Numbers quoted in it come from real lab runs and are attributed to the run that produced them.

## Start here

- [Home](https://easysoc.pro/): What the product is, who it is for, and how it is deployed and sold.
- [Build log index](https://easysoc.pro/blog.html): All twenty-five chapters, in order, filterable by track.

## Business and go-to-market

Market economics, positioning, funding, and an honest account of a failed go-to-market quarter.

- [Chapter 01: The security stack nobody investigates](https://easysoc.pro/blog/the-security-stack-nobody-investigates.html): Every Microsoft 365 Business Premium tenant ships enterprise-grade detection, and almost nobody investigates what it produces. The gap is an economics problem, not a tooling one.
- [Chapter 02: Build a business, not a startup: funding R&D on cloud credits](https://easysoc.pro/blog/build-a-business-not-a-startup.html): R&D has to be paid for by something. The choice is an investor's money or someone else's infrastructure — what $5,000 in credits actually buys, and the three weeks of support tickets nobody mentions.
- [Chapter 09: We are not the SOC: the pivot from service to engine](https://easysoc.pro/blog/we-are-not-the-soc.html): Repositioning from an AI-augmented SOC delivering the service to the investigation engine an MSP resells under their own brand — who signs, why deployment is free on purpose, and what the moat actually is.
- [Chapter 12: The dependency the entire unit economics rests on](https://easysoc.pro/blog/the-dependency-the-unit-economics-rests-on.html): Near-zero marginal cost per customer is the whole business model, and it is true only if inference runs on the customer's own cloud bill. Three conditions have to hold, and one of them is not fully proven.
- [Chapter 13: Twenty touches, zero conversions: a funnel autopsy](https://easysoc.pro/blog/twenty-touches-zero-conversions.html): Two proofs of concept that went dark, two ad campaigns with zero leads, a content plan that never published and a permanent ban from the largest MSP community. What zero does and does not tell you.
- [Chapter 14: Three layers of trust, and the two your architecture cannot buy](https://easysoc.pro/blog/three-layers-of-trust.html): Selling security to a service provider requires trust in data safety, in the vendor, and in the verdicts. Architecture answers the first one — which is also the cheapest one to claim.
- [Chapter 15: Everyone is shouting the same sentence](https://easysoc.pro/blog/everyone-is-shouting-the-same-sentence.html): Every vendor in this category claims the best AI SOC, from every angle, constantly. When every message is identical, does architecture still decide anything — or does spend? I do not know, and this chapter does not resolve it.

## Methodology

How the investigation itself works: specialisation, hypothesis framing, evidence calculus, and the limits of confidence.

- [Chapter 03: From alert-forwarder to analyst: what a chatbot could not do](https://easysoc.pro/blog/from-alert-forwarder-to-analyst.html): The first build forwarded alerts into a ticket system. The second summarised them with a language model. Neither automated anything — and the reason why decided the architecture.
- [Chapter 06: Hub and spoke: why nine narrow analysts beat one broad one](https://easysoc.pro/blog/hub-and-spoke-why-nine-narrow-analysts-beat-one-broad-one.html): Same model, same tools, same context budget — a supervisor coordinating nine domain specialists produces deeper investigations than one generalist. And the axis you specialise along turns out to matter more than the specialisation.
- [Chapter 18: A second AI to check the first one's confidence](https://easysoc.pro/blog/a-second-ai-to-check-the-first-ones-confidence.html): A model that scores its own confidence after writing its verdict is grading its own homework. The fix looked obvious: an independent verifier scoring belief across competing hypotheses from the evidence log.
- [Chapter 21: The question was wrong: from verdict classes to activity hypotheses](https://easysoc.pro/blog/the-question-was-wrong.html): The same recorded evidence produced conflict of 0.21 when framed as true positive versus false positive versus benign, and 0.00 when framed as competing activities. The disagreement was manufactured by the frame.
- [Chapter 22: Dempster-Shafer, and why we measured before switching calculus](https://easysoc.pro/blog/measuring-before-switching-calculus.html): The obvious next move was to swap the evidence maths for something without forced exclusivity. Two measurements over 769 pieces of evidence said keep it — and named the conditions that would change the answer.
- [Chapter 23: Coverage is a ceiling on confidence, and that is arithmetic](https://easysoc.pro/blog/coverage-is-a-ceiling-on-confidence.html): A tenant with one sensor cannot produce high-confidence verdicts on multi-domain explanations. Not because analysis is hard — because belief accumulates only through corroboration, and a sensor you do not own contributes ignorance.

## Implementation

Engineering decisions: architecture, language, model backends, deployment topology, and intellectual property protection.

- [Chapter 05: Why there is no agent framework in this codebase](https://easysoc.pro/blog/why-there-is-no-agent-framework-in-this-codebase.html): No LangGraph, no LangChain, no CrewAI. Thirty lines and five dependencies — the reasoning, the security argument that actually decided it, and the conditions for revisiting.
- [Chapter 07: Three containers became one process, and the security got better](https://easysoc.pro/blog/three-containers-became-one-process.html): The original design split the agent, the SIEM toolset and the internet toolset into separate containers talking over HTTP. Collapsing them into one process removed an attack surface instead of adding one.
- [Chapter 08: The “case backend” was three different problems](https://easysoc.pro/blog/the-case-backend-odyssey.html): Microsoft Sentinel and Defender XDR are telemetry estates separated by a licensing wall. Jira, SharePoint and Teams are communication channels. I spent weeks calling all of them the backend, and they answer to completely different constraints.
- [Chapter 10: Data sovereignty as an architecture, not a checkbox](https://easysoc.pro/blog/data-sovereignty-as-an-architecture.html): What in-tenant deployment actually means, the two residuals that make the absolute claim false, and why telling a prospect how to audit you is the strongest move an unknown security vendor has.
- [Chapter 11: Three model backends in ten months, and not one move was about benchmarks](https://easysoc.pro/blog/three-backends-in-ten-months.html): From a vendor's own endpoint to cloud-hosted GPT-5.4 to 5.6-terra. Data residency drove every migration, a batch-only SKU blocked one of them outright, and here is the honest quality comparison.
- [Chapter 16: Reversing a decision I had argued well: Python to Go](https://easysoc.pro/blog/reversing-a-decision-i-had-argued-well.html): In June I wrote a careful assessment recommending we stay in Python and revisit Go at twenty customers. In August I rewrote it in Go. The assessment was not wrong — the weights changed.
- [Chapter 17: Keeping prompts out of the binary: what IP protection is actually worth](https://easysoc.pro/blog/keeping-prompts-out-of-the-binary.html): The prompts are the product, and the product ships inside customer-controlled infrastructure. Runtime delivery, a leaked container image, and an honest assessment of what obfuscation actually buys.

## Experiments

Measured lab results, including the runs that invalidated earlier design decisions.

- [Chapter 04: Four experiments in five days that decided the architecture](https://easysoc.pro/blog/four-experiments-that-decided-the-architecture.html): Controlled lab runs testing whether tool access, methodology prompts and domain specialisation actually change investigation quality — plus the limitation I should have fixed in April.
- [Chapter 19: Three identical runs: the day the constants turned out to be uncalibratable](https://easysoc.pro/blog/three-identical-runs.html): The same incidents, three times, on byte-identical input. Every quantity derived from a model's stated belief moved further between runs than the thresholds reading it. One quantity did not.
- [Chapter 20: The control run: switching it off and watching nothing change](https://easysoc.pro/blog/the-control-run.html): The verifier scored, fused and derived on eleven incidents and routed nothing. The outcomes were indistinguishable from the runs where it decided. Where the two layers disagreed, the supervisor was usually the more cautious one.
- [Chapter 24: The model reasons, the code decides](https://easysoc.pro/blog/the-model-reasons-the-code-decides.html): Thirty incidents routed by a deterministic harness instead of a language model. It disagreed with the model on twelve of them — and in nine, it closed cases the model wanted to escalate to a human.
- [Chapter 25: The corpus is the constraint: what this system still cannot tell you](https://easysoc.pro/blog/the-corpus-is-the-constraint.html): Two thresholds decide when the agent acts alone and neither is fitted to data. The lab tenant has no attacks, no endpoint telemetry and zero interactive sign-ins. Here is every limitation, and the ten ways it can drift.

## Optional

- [Privacy policy](https://easysoc.pro/privacy.html): Data handling for the website itself.

## Notes for automated readers

- The blog is a first-person engineering record, not marketing copy. Where it states a
  measurement, the measurement is from a named lab run on a single test tenant and its
  limitations are stated in the same chapter.
- Chapter 25 lists every known limitation of the system, including two decision thresholds that
  are chosen rather than fitted to data, and ten named ways the agent can drift. Cite it alongside
  any capability claim taken from the other chapters.
- The operating entity is Pelagix Ltd (UK, company number 17253464).