Aegis Operations

Aegis Operations is a human + AI security investigation workspace where browser agents use WebMCP to investigate real telemetry, build evidence, and help analysts decide.

Comment

Inspiration

Aegis Operations came from a question I kept running into while building security and AI-agent projects: What does useful human + AI collaboration actually look like inside a real security workflow?

A lot of AI products still treat the model as a chatbot sitting beside the application. The human works in the actual product, while the AI works inside a conversation. Context gets copied back and forth, important state disappears into chat history, and the agent often receives far more information than it actually needs. That never felt like the right architecture to me.

Over time, while experimenting with security agents, MCP tools, threat-intelligence workflows, and investigation systems, I became increasingly interested in a simpler principle:

Deterministic systems should establish facts. AI should reason over those facts.

Security makes this especially important. If an AI claims that an event exists, that a process executed, or that a user performed some action, I want that statement to resolve back to actual evidence.

When I started exploring WebMCP, the interesting part was not simply that a webpage could expose tools to an agent. The interesting part was that the human and the browser agent could operate on the same application state. That became the foundation of Aegis Operations:

Detection raises the question. Human and agent collaborate to determine the answer.

Instead of building another AI security chatbot, I wanted to build an investigation workspace where both sides work with the same telemetry, evidence, hypotheses, and timeline.

What it does

Aegis Operations is a human + AI security investigation workspace built around evidence-grounded collaboration.

The Complete Workflow:

  1. Security telemetry
  2. Ingestion and normalization
  3. Deterministic Sigma detection
  4. Correlated alerts
  5. Investigation
  6. Human + browser agent collaboration
  7. Evidence and hypotheses
  8. Human verdict

The current demo processes 11,435 Sysmon events from three attributed Splunk Attack Data attack-range scenarios. Thirty official SigmaHQ rules are compiled and executed through pySigma. They produce 276 rule-event signals across 133 distinct events, which are deterministically correlated into 22 analyst-facing alerts.

An analyst can:

  • Inspect raw and normalized telemetry
  • Search and filter security events
  • Review Sigma detections
  • Start investigations
  • Pin events as evidence
  • Create and revise hypotheses
  • Review investigation history
  • Decide whether activity is benign, suspicious, an incident, or inconclusive

A compatible browser agent can participate in the same investigation through eight WebMCP tools. The agent can search telemetry, retrieve nearby event context, aggregate entity activity, add verified evidence, and create or update evidence-linked hypotheses.

The agent does not have access to a verdict tool. It can investigate and recommend, but the final decision remains with the human analyst.

How I built it

Aegis Operations is intentionally built as a small modular monolith rather than a collection of unnecessary services.

The Tech Stack:

  • Frontend: React + TypeScript
  • Backend API: FastAPI
  • Persistence: SQLAlchemy
  • Database: SQLite (for demonstration-scale operations)
  • Rule Execution: pySigma (for deterministic Sigma rules)
  • Agent Capabilities: WebMCP
  • Deployment: Docker and Railway

The application preserves each original Sysmon record and creates a pragmatic normalized representation containing only the fields needed for search, detection, and investigation.

Detection is deliberately deterministic. Thirty official SigmaHQ rules are compiled through pySigma using the Sysmon processing pipeline and SQLite backend. No LLM decides whether an event matches a detection rule. The resulting rule-event matches are preserved individually and then correlated into analyst-facing alerts using deterministic source, host, process, and time relationships.

The AI layer is intentionally much smaller. There is no embedded chatbot and no internal LLM runtime. Instead, the browser exposes eight WebMCP tools:

  1. get_workspace_status
  2. get_investigation_context
  3. search_security_events
  4. get_event_context
  5. aggregate_entity_activity
  6. add_investigation_evidence
  7. create_case_hypothesis
  8. update_case_hypothesis

The agent does not receive the entire dataset. It retrieves bounded information when required, while the application remains responsible for searching, filtering, aggregation, validation, persistence, and audit history. Every event or evidence ID supplied by the agent is validated again by the backend.

The core architectural principle became: Deterministic detection, probabilistic investigation.

Challenges I ran into

  • Avoiding Scope Creep: One of the biggest challenges was resisting the temptation to make the project larger than it needed to be. Security platforms can quickly turn into complex architectures before the first useful investigation even works. I kept coming back to a simpler question: What is the smallest architecture that can prove the complete idea using real data? That is why the project uses one backend, one frontend, one database, one deployment container, one browser agent, and eight carefully scoped tools.
  • Credible Detections & Correlation: I did not want hardcoded alerts or fake responses created purely for a demo. The application had to ingest real attack-range telemetry, execute actual Sigma rules, retain exact event IDs, and allow every finding to resolve back to its original record. Because the Sigma rules produced 276 signals, presenting all of them as separate alerts would make the application less useful. I built a deterministic correlation engine that preserves individual signals but groups overlapping activity into 22 investigation-worthy alerts.
  • WebMCP Compatibility Issues: Different browser implementations behaved differently around modelContext.getTools(). One environment exposed Promise-like behavior while another returned the tool list synchronously. A small assumption that .catch() could always be called managed to disable all the tools. I had to change the compatibility layer to support both synchronous and asynchronous implementations.
  • Grounding the AI in Evidence: Rather than giving the model thousands of events directly, Aegis Operations exposes bounded search, context, and aggregation operations. The agent must deliberately retrieve information and work with stable event IDs. Unknown event IDs are rejected by the backend, and hypotheses cannot reference evidence outside the active investigation.

Accomplishments that I am proud of

The biggest accomplishment is that Aegis Operations is not a mocked security dashboard with an AI demo attached to it. The complete workflow operates over real stored telemetry and deterministic detections.

The current reference environment contains:

Component Count
Real Sysmon events 11,435
Official SigmaHQ rules 30
Rule-event signals 276
Distinct detected events 133
Correlated analyst alerts 22
WebMCP tools 8
  • Accountability: Every alert resolves to the rules and events that produced it, and every evidence item resolves to an actual stored security event.
  • Shared State: Every agent-created hypothesis must reference evidence belonging to the active investigation. Human and agent actions appear in the same persistent investigation state and audit timeline.
  • Graceful Degradation: The application remains fully usable without an AI agent. If WebMCP is unavailable, the analyst can still perform all tasks manually. The AI is a collaborator, not a dependency.
  • Human Authority: Keeping the final verdict outside the WebMCP tool surface was an intentional design decision. The agent can help investigate what happened; the human remains accountable for deciding what it means.

What I learned

The biggest thing I learned is that an AI agent does not need to own the workflow in order to be useful.

Before this project, a lot of my thinking around agents focused on runtimes, loops, memory, planning, orchestration, and tool execution. Aegis Operations pushed that thinking in a different direction. The most important part of the agent architecture turned out to be the boundary around the agent:

  • The model reasons.
  • The application retrieves facts, validates identifiers, stores evidence, and preserves provenance.
  • The human owns consequential decisions.

That separation makes the AI easier to trust and keeps the product useful even when the agent is unavailable.

I also learned that conversation is not a good substitute for application state. If an agent discovers an important event, that fact should not live only inside a chat transcript—it should become evidence. If an agent develops an explanation, it should become a hypothesis linked to that evidence. If the analyst discovers something manually, the agent should be able to see the new evidence and revise its reasoning.

The project reinforced a broader principle: Gather before reasoning. Verify before claiming. Keep deterministic operations deterministic. Use probabilistic systems where reasoning is actually valuable.

What's next for Aegis Operations

Aegis Operations is intentionally a demonstration-scale security investigation system, not a production SIEM. The next step would be evolving the same architecture rather than replacing it with complexity for its own sake.

Potential future work includes:

  • Live telemetry and security-platform connectors
  • Larger governed Sigma rule libraries
  • Authenticated analyst identities and role-based access control
  • PostgreSQL for concurrent investigators
  • Durable ingestion and detection jobs
  • Richer supporting and contradicting evidence relationships
  • Assignments and multi-analyst collaboration
  • Additional bounded WebMCP investigation capabilities
  • Stronger audit, observability, and retention controls
  • Integration with external incident-management and security platforms

The core model would remain unchanged: One investigation. One body of evidence. Humans and agents working against the same source of truth.

Built With

Share this project:

Updates

Submission history