EmilyAI: The Triage Layer That Keeps Human Analysts Focused on Real Threats

Alert fatigue is one of the most documented and least solved problems in security operations. The average enterprise SOC receives tens of thousands of alerts per day. The vast majority are false positives, duplicates, or low-priority events that don't require immediate human attention. The consequence is that analysts spend a disproportionate amount of their time triaging noise — and real threats occasionally slip through while an analyst is working through a queue of benign alerts.

This problem doesn't get smaller as the monitored environment gets smaller. In some respects it gets worse, because a single analyst serving multiple small clients has to context-switch between environments constantly, and each context switch has a cognitive cost.

EmilyAI was built to solve this. Not to replace analysts — to protect their attention.

What EmilyAI Does

EmilyAI is our AI-assisted triage and enrichment layer that sits between raw SOC365 alerts and the analyst queue. Before any alert reaches a human analyst, EmilyAI has already done the following:

• Contextual enrichment: Looked up the source and destination IPs against threat intelligence feeds, checked the relevant domain's registration age and category, queried the CVE database for any known vulnerability associations, and assessed whether the involved assets are known to hold sensitive data.
• Baseline comparison: Compared the event to the established behavioural baseline for the asset, user, and network segment involved. An authentication event from a user who always logs in from the same office IP and suddenly authenticates from a Bulgarian hosting provider is flagged. The same authentication event from a user whose travel pattern has been previously observed is not.
• Duplicate suppression: Collapsed repeated instances of the same underlying event — the same misconfigured device generating a thousand identical log lines — into a single enriched case record rather than a thousand separate alerts.
• Priority scoring: Assigned a composite priority score based on the enrichment data, the baseline comparison, the asset's criticality, and the current threat landscape relevant to the client's sector.

By the time the alert reaches an analyst, it's not a raw log line. It's a structured case with context, recommended queries, related events, and a suggested priority. The analyst's job is to evaluate, decide, and act — not to research from scratch.

Why This Matters More for SMB Deployments

In a large enterprise SOC deployment, a dedicated team of analysts serves a single client environment. They develop deep familiarity with that environment over time, which provides some natural noise reduction: an experienced analyst knows which servers generate noisy logs, which users travel frequently, which external services are legitimately used by the business.

In the SOC in a Box model, a named analyst serves each client — but that analyst also serves others. EmilyAI compensates for the reduced opportunity for deep environmental familiarity by codifying what an experienced analyst would know into an automated enrichment layer. The environment's behavioural baseline is continuously updated, meaning the analyst's knowledge of the environment compounds over time without requiring manual documentation.

The practical result is a significant reduction in false positive escalation — alerts that would have reached an analyst under a simpler system, been evaluated as benign in 30 seconds, and consumed 30 seconds of human time multiplied across hundreds of similar events per day. That time is instead spent on the events that actually matter.

The Baseline Learning Period

One of the questions we get most often from prospective clients is: "How long does it take before EmilyAI knows our environment?" The honest answer is that useful triage begins immediately — EmilyAI starts with generic industry baselines for the client's sector and begins learning the specific environment from the first telemetry. Within two weeks, the false positive rate for most environments drops to a level that makes the analyst's queue highly actionable. Within a month, it's calibrated well enough that genuinely unusual events stand out clearly.

This learning period is also why we include an active detection tuning phase in the first 30 days of every deployment. The named analyst and EmilyAI work together to establish the baseline — the analyst reviews the initial alerts, provides feedback on false positives, and that feedback feeds back into the triage model for the specific environment.

EmilyAI Is Not the SOC

We want to be clear about this, because it matters. EmilyAI is a triage tool. It makes analysts more effective. It does not make decisions, it does not escalate incidents, and it does not contact clients. Every escalation that leaves the SOC is a human decision, made by a named analyst who has reviewed the enriched case and applied their judgement.

We've seen competitors advertise "AI-powered SOC" services that turn out to mean automated alert handling with a human nominally available if the automation flags something critical enough. That's not what we built. EmilyAI exists to give our analysts more time, better context, and higher confidence — so that the human judgement applied to each real threat is sharper, not replaced.

Next week: DecoyPulse. The deception technology that generates zero false positives — because if something touches a decoy, it shouldn't be there.