We Let an AI Agent Triage Our Security Alerts. Here's What Happened.

Last Tuesday I watched an AI agent investigate a security finding faster than I could open the right CloudWatch tab. Four findings, two principals, full MITRE mapping, triage verdicts — done in about 30 seconds. I've been doing this job for years and the same workflow takes me 15 minutes on a good day.

That's not a brag about the agent. It's an indictment of how we've been doing alert triage.

Here's the thing nobody talks about with detection systems: the hard part isn't detecting anomalies. We have 14 detectors running in parallel against every CloudTrail event. They're good at finding weird stuff. The hard part is what happens after the alert fires. Someone has to open it, pull context from three different places, figure out if it's actually bad, write up why, and decide what to do. Hundreds of times a day. Most of it turns out to be nothing.

So we did what any reasonable engineering team would do — we gave the boring part to a robot.

How We Wired It Up

We built an MCP server that exposes our investigation workflow as tool calls. MCP (Model Context Protocol) is basically a standard way to let AI models call your APIs. You define tools — "list findings," "get detector scores," "correlate by principal" — and the model decides when and how to call them.

Our MCP server sits in front of the same APIs our analysts use. It has auth, rate limiting, tenant isolation, and an audit trail. The agent can't see other tenants' data. It can't do anything an analyst couldn't do. It's just faster at the mechanical parts.

The investigation pipeline has four stages. We didn't invent this — it's how every halfway-decent SOC operates:

• Detect — What fired? Are the detectors healthy? Any gaps in coverage?
• Correlate — Is this isolated or part of a pattern? What does MITRE say about this detector combination?
• Investigate — Pull the full packet. Principal history, baseline status, sequence analysis, related findings.
• Triage — Make a call. True positive, false positive, or needs a human. Show your work.

The Session That Sold Us

The agent started its shift the same way I do — polling for open findings and checking detector health. It ran both calls in parallel, which is a small thing, but I always forget to check detector status first. Bad habit.

list_new_findings({ min_score: 0.35, since_minutes: 60 })
get_detector_status()

It found four open findings across two service account principals. Both were accessing files in a production bucket — specifically, quarterly reports across different departments. Three scored 1.0 (critical), one scored 0.39 (medium). All triggered by the sequence detector.

First thing the agent flagged: only 12 of 14 detectors were reporting in the status response. Two were missing. I wouldn't have noticed that for hours, maybe days. The agent mentioned it in its first paragraph of analysis.

Correlation and MITRE Mapping

The agent ran correlation queries on both principals — by identity, by source IP, by bucket, by time window. It also mapped the triggered detector to MITRE ATT&CK techniques.

Correlation came back empty. The underlying CloudTrail events were months apart, so no time-window overlap. But the agent noticed something the correlation engine didn't surface: both principals shared a trace identifier prefix. It called that out as a possible indicator of coordinated activity. Whether that's meaningful depends on your architecture, but the point is — the agent noticed a structural signal that a simple time-based correlator would miss.

MITRE mapping returned T1530 (Data from Cloud Storage) and T1485 (Data Destruction). The sequence violation pattern matched known collection and impact behaviors. Not conclusive on its own, but it tells you what neighborhood you're in.

The Investigation Packet

For each critical finding, the agent pulled a full investigation packet — principal identity, baseline training status, all detector scores, related findings, MITRE mappings, recommended actions. Everything you'd want on one screen.

Here's where it got interesting. The agent found:

• Both principals had zero training events. Their baselines were completely cold — the system had never learned what "normal" looks like for these identities.
• No MFA on either principal. Not unusual for service accounts, but it widens the attack surface if credentials leak.
• Both were classified as non-human identities, yet they were pulling sensitive departmental reports. Service accounts don't usually read quarterly finance spreadsheets.
• One principal was hitting the bucket from outside the network. For a service account, that's a red flag.
• The sequence detector scored 1.0 — a hard rule violation, not a probabilistic score. Something in the access pattern was categorically wrong.

And Then It Found Our Bug

This is the part I didn't expect. While pulling principal context, the agent noticed that one identity's baseline fingerprint was returning metadata belonging to a different principal. It flagged it: "cross-contamination between principals in the baseline store."

That's not a security finding. That's a data integrity bug in our platform. The agent caught it as a side effect of doing a thorough investigation. We'd been shipping that bug for at least a week.

The best security investigation agents don't just find threats. They find bugs in your detection pipeline. Anything that looks wrong gets flagged, whether it's an attacker or a broken JOIN.

Triage: Show Your Work

Before submitting any verdict, the agent wrote out its reasoning. Not "alert is bad, closing ticket." Actual reasoning:

// Sequence score 1.0 = hard rule violation, not noise
// Cross-department file access by a service account
// External IP on an identity that should be VPC-only
// No MFA on either principal
// Cold-start baseline weakens confidence but doesn't clear them
// MITRE T1530 + T1485 alignment
//
// Verdict: true_positive, confidence 0.85
// Action: escalate (insufficient trust tier for auto-remediation)

Notice the confidence is 0.85, not 1.0. The agent explicitly downgraded its confidence because the baseline was cold and detailed sequence context wasn't available for these older events. That's the behavior you want — an agent that knows what it doesn't know.

For the medium-severity finding (score 0.39, internal IP, same cold baseline), the agent submitted "needs_review" instead of true_positive. It explained that the lower score combined with zero training data made a definitive call premature. I'd have made the same decision.

Why the Agent Can't Just Fix Things

You might be wondering why the agent escalated instead of just revoking the session. We did that on purpose.

Every agent starts at a "new" trust tier. It can investigate all day long, but it can't touch anything until it proves its judgment is sound. Here's how trust works:

• New — Investigate and triage only. No remediation.
• Provisional — Non-destructive actions (suppression rules, escalations). Earned through verified triage accuracy.
• Trusted — Destructive remediations with human approval. Earned through sustained accuracy.
• Verified — Auto-remediation for critical findings above 0.95 confidence. Earned over months, not days.

I know this sounds slow. It is slow. Deliberately. The number one failure mode of security automation is a bot revoking production credentials because it misread a CI/CD job as an exfiltration attempt. We learned this the hard way at a previous company. The trust ladder exists because the cost of a wrong automated action is way higher than the cost of escalating to a human for a few weeks while the agent builds its track record.

False Positives Are the Real Test

True positives are straightforward — the signals align, you triage and escalate. The real measure of an investigation agent is how it handles false positives.

Imagine a high-scoring alert fires on a service account at 3 AM. The agent investigates, finds the principal is a known batch processing pipeline that runs nightly, accesses cross-department data as part of its normal job, and has done this every night for six months. It submits "false_positive" with reasoning referencing the pipeline's expected behavior.

That's ten minutes of analyst time saved on a single alert. Multiply by the 40-60 false positives a typical SOC sees daily and you start to understand why this matters.

Multi-Agent Consensus for the Hard Stuff

Some incidents are ambiguous enough that one opinion isn't enough. We support collaborative investigation sessions where multiple agents independently investigate the same finding and submit separate verdicts.

Think of it like a panel review. Three agents look at the same evidence, each forms its own conclusion with a confidence score and written reasoning. If all three land on "true positive" with high confidence, you have a much stronger signal than any single verdict. If they disagree, that's useful information too — it tells you where the evidence is genuinely ambiguous and a human needs to break the tie.

Real SOC teams do this with senior analyst reviews. The difference is that agent consensus takes seconds instead of scheduling a meeting.

Stuff the Agent Caught That I Would've Missed

Looking back at the session, the agent surfaced things that would have taken me multiple rounds of investigation:

• Two detectors were missing from the health check. I check detector status maybe once a week. The agent checked it first thing.
• Baseline cross-contamination between two principals. This was a platform bug, not a security finding. I wouldn't have noticed it during a normal triage workflow.
• Cold-start awareness. The agent recognized that zero training events meant the anomaly scores were less trustworthy, even at 1.0, and explicitly lowered its confidence.
• Structural correlation via shared trace prefixes, even after the time-based correlator returned empty. I would have stopped at "no correlations found."
• Proportional response. It escalated instead of trying to auto-fix, because the evidence was suggestive but incomplete. That restraint matters more than speed.

If You Want to Build This

Nothing about this approach is proprietary to Entroptics. If you have a detection system that produces scored findings, you can build the same thing. Some hard-won advice from getting it to work:

• Expose primitives, not conclusions. Give the agent raw detector scores and let it reason. If you pre-digest findings into "bad" and "not bad," you've built an expensive webhook.
• Map to MITRE. It gives the agent a vocabulary for threat classification that humans can audit. Without it, the agent's reasoning is a black box.
• Start read-only. The trust ladder isn't optional. Let the agent prove it understands your environment before giving it write access.
• Log everything. Every tool call, every reasoning chain, every verdict. Immutable audit trail. This is how you build organizational confidence in the system.
• Handle missing data honestly. When context is unavailable, the agent should say "I don't have enough information" and lower its confidence. Hallucinated evidence is worse than no evidence.

Where This Is Going

We're not trying to replace security analysts. If that's what you heard, re-read this post. We're trying to move analysts from doing the mechanical parts of investigation — the context-gathering, the correlation, the MITRE lookups — to reviewing verdicts and handling the genuinely ambiguous cases that require human judgment.

Thirty seconds versus fifteen minutes. Four findings, two principals, full MITRE mapping, written reasoning, proportional triage decisions, and a platform bug caught as a bonus. That's one session.

The MCP integration ships on Enterprise plans. If you're already running Entroptics, ask your account contact to turn it on. If you're evaluating, book a demo — we'll run a live triage session against your actual S3 workloads and you can watch the agent work.