Comparison
The proposed platform improves the investigation phase of endpoint detection. Traditional EDR products can detect suspicious behavior, but analysts still spend significant time reconstructing context, mapping techniques, and deciding what to do next.
Traditional EDR vs proposed AI-assisted EDR
| Feature / capability | Traditional EDR | Proposed AI-assisted EDR |
|---|---|---|
| Alert explanation | Mostly manual analyst interpretation | AI-generated structured reasoning |
| MITRE ATT&CK mapping | Often analyst-driven or manual | Retrieval-grounded mapping using Pinecone and AI |
| Similar-event retrieval | Usually manual search or filtering | Semantic retrieval of similar historical events |
| Follow-up queries | Not available or handled outside the alert | Event-level AI chatbot |
| Multi-event correlation | Mostly manual | AI-assisted multi-alert incident narrative |
| IOC extraction | Analyst manually derives indicators | AI extracts IOCs from alert context when evidence supports them |
| Investigation time | Higher due to manual analysis | Reduced through automated explanation and support |
| Consistency of interpretation | Depends heavily on analyst skill and workload | More standardized explanations grounded in evidence |
What changes for analysts
- They start with a structured explanation instead of raw telemetry alone.
- They can inspect process lineage and supporting evidence beside the AI output.
- They can ask follow-up questions without leaving the alert.
- They can extract investigation-relevant IOCs from the event context.
- They can correlate multiple related alerts into one incident-level story.
What changes for the platform
- Detection rules remain portable and versionable as JSON.
- Retrieval adds MITRE ATT&CK and similar-event context before generation.
- Bedrock access stays in the backend rather than the browser or endpoint.
- The dashboard becomes an investigation workspace, not only an alert table.