DEV Community: SHIVAM JAISWAL

Building Incident AI Agent: A Memory-Powered AI for Cyber Incident Response

SHIVAM JAISWAL — Wed, 12 Aug 2026 17:56:01 +0000

Introduction

Cybersecurity incident response often has a frustrating problem: the same investigation patterns can appear again and again.

An analyst may investigate an SSH brute-force attack today, resolve it successfully, and then encounter a similar attack weeks later. The technical details may be different, but the investigation process, root cause, mitigation strategy, and lessons learned can be surprisingly similar.

Traditional automation can execute predefined rules.

An AI agent can reason about an incident.

But an AI agent with persistent memory can potentially do something more useful:

Learn from previous incident investigations and use that experience when analyzing future incidents.

That idea led us to build Incident AI Agent, a memory-powered cybersecurity incident response system developed as part of Team ALPHA++.

A typical cybersecurity incident-response workflow looks like this:

Security Alert
      ↓
Incident Investigation
      ↓
Identify Attack
      ↓
Find Root Cause
      ↓
Choose Response
      ↓
Resolve Incident

This workflow works, but one important piece of information can easily get lost: the experience gained from previous incidents.

For example, imagine an analyst investigates an SSH brute-force attack. During the investigation, they identify the affected system, determine the likely root cause, apply a successful response, and document the lessons learned.

Weeks later, a similar attack occurs.

The new incident may contain different IP addresses, timestamps, users, and logs, but the underlying attack pattern and response strategy may be very similar.

Without persistent memory, the new investigation can effectively start from scratch.

We wanted to explore a different approach:

New Incident
      ↓
Current Evidence
      +
Past Incident Experience
      ↓
Investigation
      ↓
Recommendation
      ↓
Store Outcome

The idea was simple: if an incident produced useful knowledge, that knowledge should remain available when a similar incident happens again.

Our Approach

Instead of treating every security incident as an isolated event, we designed Incident AI Agent around the idea of persistent incident experience.

The agent can analyze the current incident, investigate the available evidence, search for relevant historical incidents, and use previous outcomes as additional context when generating a recommendation.

The goal is not to blindly repeat a previous response.

The goal is to give the analyst more context before making a decision.

At a high level, Incident AI Agent follows this workflow:

Current Incident
↓
Analyze
↓
Investigate
↓
Retrieve Relevant Experience
↓
Generate Recommendation
↓
Human Review
↓
Response
↓
Store Outcome

This creates a feedback loop in which the outcome of one incident can become useful experience for future investigations.

System Architecture

Incident AI Agent is built as a modular system where the AI reasoning layer is connected to investigation tools, persistent memory, and a security dashboard.

The backend acts as the bridge between incoming security data, the AI agent, investigation functions, and the memory system.

This separation allows each component to have a clear responsibility while allowing the agent to coordinate the overall investigation.

Security Logs
      ↓
FastAPI Backend
      ↓
AI Agent
   ↙     ↘
Investigation   Hindsight
   Tools         Memory
      ↘         ↙
    Recommendation
          ↓
   Security Dashboard
          ↓
     Human Review

FastAPI Backend

The FastAPI backend acts as the central communication layer of the system.

It receives incident-related requests from the dashboard, coordinates the AI agent, exposes investigation functionality, and connects the application with the memory layer.

This separation keeps the frontend focused on visualization while the backend handles the core application logic.

AI Agent

The AI agent acts as the reasoning layer of Incident AI Agent.

Instead of performing every operation itself, the agent can use specialized functions to analyze evidence, investigate incidents, retrieve historical context, and generate response recommendations.

This tool-based approach gives the agent structured capabilities while keeping individual operations separated from the reasoning layer.
Some of the capabilities exposed to the agent include:
analyze_log()
identify_attack()
investigate_incident()
find_similar_incidents()
get_previous_resolution()
generate_recommendation()
store_incident_memory()

Hindsight Memory

The memory layer is one of the core components of Incident AI Agent.

We use Hindsight to preserve useful experience from previous incident investigations and make that experience available to future investigations.

Instead of storing only raw incident data, the system is designed around information that can be useful for future reasoning, such as attack patterns, possible root causes, response actions, outcomes, and lessons learned.
For example, an SSH brute-force investigation could produce a memory entry like:
Attack Pattern:
SSH Brute Force

Root Cause:
Exposed or compromised credentials

Successful Response:

Block malicious IP
Disable compromised account
Rotate credentials
Enable SSH key authentication

Outcome:
Incident contained successfully

Lesson Learned:
Credential exposure was a major contributing factor.
When a similar incident appears later, the agent can search its historical experience and use the retrieved information as additional context.

This allows the system to move from a purely reactive workflow toward an experience-informed investigation process.

Incident Investigation Example

To demonstrate the workflow, consider a simple SSH brute-force incident.

The system receives security logs showing a large number of failed authentication attempts against an SSH service.

Incoming Incident

Example signals:

147 failed SSH login attempts
Multiple authentication failures from the same source
Repeated attempts against a privileged account
Unusual authentication activity outside the normal pattern
The agent first analyzes these signals and identifies the incident as a likely SSH brute-force attack.

Investigation

The agent then investigates the incident to understand the likely root cause and affected resources.

Possible findings could include an exposed SSH service, repeated authentication attempts against a valid account, or evidence suggesting compromised credentials.

Historical Context

At this point, the memory layer becomes useful.

The agent searches Hindsight for previous incidents with similar characteristics.

If a relevant incident is found, the previous investigation, response, outcome, and lessons learned can be retrieved and used as additional context for the current investigation.

Recommended Response

Based on the current evidence and relevant historical experience, the agent can generate a response recommendation such as:

Block the malicious source IP
Disable or secure the affected account
Rotate potentially compromised credentials
Prefer SSH key-based authentication
Review authentication logs for additional affected accounts
Monitor the system for repeated attempts

Outcome and Memory

After the incident is reviewed and resolved, the useful outcome can be stored as new incident experience.

This creates a continuous learning loop:

Incident
↓
Investigation
↓
Recommendation
↓
Human Review
↓
Response
↓
Outcome
↓
Memory
↓
Future Incident

Human-in-the-Loop

Incident AI Agent is designed as a decision-support system rather than a fully autonomous response engine.

The agent can investigate an incident and generate response recommendations, but critical actions can remain under human approval.

This allows security analysts to review the available evidence, evaluate the recommendation, and decide whether the proposed response should be executed.
This approach provides a balance between AI-assisted automation and human oversight. It also creates a feedback loop because the outcome of a reviewed incident can become useful experience for future investigations.

Technology Stack

We built Incident AI Agent using a combination of modern web technologies, AI tooling, backend services, and persistent memory.

Frontend

Next.js + Tailwind CSS

The frontend provides the security dashboard where analysts can view incidents, investigation results, recommendations, and relevant security information.

Backend

Python + FastAPI

FastAPI handles the backend APIs and acts as the communication layer between the frontend, AI agent, investigation tools, and memory system.

AI Layer

LLM + Function Calling

The LLM provides the reasoning capability, while function calling allows the agent to interact with specialized investigation functions instead of relying only on text generation.

Memory

Hindsight

Hindsight provides the persistent memory layer used to store and retrieve useful experience from previous incident investigations.

Data

Synthetic Cybersecurity Logs

For development and demonstration, we used synthetic cybersecurity log data representing different incident scenarios.

What We Learned

Building Incident AI Agent changed the way we think about AI agents.

The biggest takeaway was that an agent becomes more useful when it can combine current evidence with relevant historical experience.

Without memory, the workflow looks like:

Incident → Reason → Response

With memory, it becomes:

Incident
↓
Current Evidence + Past Experience
↓
Reason
↓
Recommendation
↓
Outcome
↓
New Experience

1. Memory adds context, not just storage

A memory system is more valuable when it can retrieve information that is relevant to the current situation.

For incident response, that context can include previous attack patterns, root causes, successful responses, outcomes, and lessons learned.

2. Tools make agent capabilities more structured

Instead of expecting the LLM to perform every task through text generation, specialized functions can give the agent clearly defined capabilities.

This makes the overall system easier to reason about, test, and extend.

3. Human oversight is still important

Cybersecurity decisions can have significant consequences.

For that reason, we designed the system so that AI recommendations can be reviewed by a human before critical actions are taken.

The goal is not to replace security analysts, but to give them better context and reduce repetitive investigation work.

Limitations and Future Improvements

Incident AI Agent is currently a prototype focused on demonstrating memory-powered incident investigation. There are several areas where the system can be improved before it could be considered production-ready.

Current Limitations

The current implementation primarily works with synthetic cybersecurity logs and controlled incident scenarios.

Real-world security environments generate much larger and more diverse volumes of telemetry from systems such as SIEM platforms, EDR tools, firewalls, cloud infrastructure, and identity providers.

The accuracy of recommendations can also depend on the quality of the available logs and the relevance of retrieved historical experiences.

Future Improvements

Some areas we would like to explore in future versions include:

Integration with real SIEM and security monitoring platforms
Support for richer security telemetry from EDR, network, cloud, and identity systems
More advanced incident correlation across multiple data sources
Better evaluation of memory retrieval quality
Confidence scoring for AI-generated recommendations
More detailed analyst feedback and learning loops
Stronger access controls and audit logging
Production-scale deployment and monitoring

Conclusion

Incident AI Agent explores a simple but powerful idea: cybersecurity incident response can benefit from remembering what happened before.

By combining an AI reasoning layer with investigation tools and persistent memory, the system can use both current incident evidence and relevant historical experience when generating recommendations.

The goal is not to replace cybersecurity analysts or blindly automate critical decisions.

Instead, the goal is to reduce repetitive investigation work, preserve useful incident knowledge, and give analysts better context when similar incidents occur.

For us, the most interesting part of the project was seeing how memory changes the behavior of an AI agent.

Without memory, every incident can look like a new problem.

With memory, previous investigations can become part of the context for the next one.
We believe this idea can be extended beyond cybersecurity: any domain where decisions improve through accumulated experience could potentially benefit from memory-powered AI agents.

Project

Incident AI Agent was built as part of Team ALPHA++.

Team

Shivam Jaiswal
Sanskar Maurya

The project is focused on exploring how persistent memory can improve AI-assisted cybersecurity incident investigation.

Source Code

The complete source code is available on GitHub:

https://github.com/shivamjaiswal008/Incident-AI-Agent

Building a Financial Risk Intelligence Agent That Learns from Every Investigation

SHIVAM JAISWAL — Sun, 07 Jun 2026 14:15:39 +0000

Enhancing Fraud Investigations Through Memory-Powered AI Agents

Traditional fraud detection systems are excellent at identifying suspicious transactions, but they have one major limitation:

They don't remember.

Every transaction is treated as a brand-new event. The model generates a score, the analyst reviews the case, and once the investigation is complete, all the valuable knowledge gained during that process disappears.

After building several fraud detection systems, I realized the biggest problem wasn't model accuracy—it was the lack of memory.

So I built a Financial Risk Intelligence Agent that learns from every investigation.

Instead of relying only on risk scores, the system retrieves similar historical investigations before making recommendations, allowing the agent to reason using past experience.

The Problem with Traditional Fraud Detection

A typical fraud detection workflow looks like this:

Transaction → ML Model → Risk Score → Alert → Analyst Review → Case Closed

This approach works well for detecting known patterns, but it ignores something critical:

Analyst expertise.

Experienced fraud investigators don't make decisions based solely on scores.

They ask:

Have we seen this pattern before?
Was it confirmed fraud?
Was it a false positive?
What actions resolved the case?
What indicators mattered most?

Traditional systems cannot answer these questions because they have no memory.

The Core Idea

Instead of asking:

"How risky is this transaction?"

The system asks:

"Have we seen something similar before, and what did we learn from it?"

That small shift transforms a fraud detector into an intelligence system.

System Architecture

The solution consists of four layers.

1. Transaction Analysis Layer

This layer extracts transaction features such as:

Transaction amount
Geography
Device fingerprint
Merchant category
Transaction timing

These features provide the context needed for investigation.

2. Fraud Detection Engine

The extracted features are passed to a machine learning model.

The model generates:

Risk score
Risk category
Confidence level

Example:

Risk Score: 77%
Category: High Risk
Confidence: 91%

This is the standard component found in most fraud detection systems.

3. Memory Layer (The Key Innovation)

This is where the system becomes different.

Instead of storing raw transactions, it stores investigation outcomes and lessons learned.

Each memory contains:

Fraud type
Transaction characteristics
Risk indicators
Analyst decision
Investigation summary
Resolution steps
Final outcome

When a new transaction arrives, the system performs semantic similarity search and retrieves the most relevant historical investigations.

The agent receives context before making a recommendation.

4. AI Investigation Agent

The agent combines:

Current transaction data
Risk score
Historical memories

It then generates a complete investigation report with reasoning and recommendations.

Instead of producing a number, it produces actionable intelligence.

Real-World Example

Incoming Transaction

Amount: ₹475,000
Location: Dubai
Type: Wire Transfer
Time: 01:45 AM

Model Output

Risk Score: 72%
Confidence: 91%

Without memory, the investigation ends here.

The analyst simply sees:

High Risk Transaction

What Happens with Memory?

The system retrieves:

3 previously confirmed fraud cases
1 similar false-positive case

The false-positive case involved a customer who had an active travel notice on file.

The agent now generates:

Risk Score: 72%. Three previously confirmed fraud cases match this transaction profile. One similar case was a false positive due to an active travel notice. Recommendation: Freeze transaction pending verification and check travel records before contacting the customer.

Same model.

Completely different investigation quality.

The Learning Loop

The most important part of the architecture is the feedback loop.

Step 1

Transaction arrives.

Step 2

ML model generates a risk score.

Step 3

Memory layer retrieves similar historical investigations.

Step 4

AI agent creates a contextual investigation report.

Step 5

Analyst confirms the outcome.

Step 6

The outcome is written back into memory.

Every completed investigation becomes training data for future investigations.

The system continuously improves through experience.

What Changed After Adding Memory?

The improvement wasn't just accuracy.

The behavior of the entire system changed.

Before Memory

Relied almost entirely on risk scores
Generic recommendations
Limited explainability
Low analyst trust

After Memory

Referenced historical cases
Provided evidence-backed recommendations
Better handling of false positives
More contextual reasoning
Higher analyst confidence

The biggest difference was trust.

Analysts were far more willing to follow recommendations when those recommendations were supported by previous cases rather than a single percentage score.

Key Lessons

1. Memory Can Be More Valuable Than Model Improvements

Small gains in model accuracy often produce less impact than adding historical context.

Experience matters.

2. Analyst Knowledge Should Not Be Lost

Every investigation contains valuable information.

A memory layer turns analyst decisions into reusable organizational intelligence.

3. Explainability Drives Adoption

People trust systems that can explain their reasoning.

Evidence-backed recommendations outperform black-box predictions.

4. Feedback Loops Create Compounding Value

Every completed investigation improves future investigations.

The system becomes more useful over time.

5. Fraud Evolves Constantly

Static models struggle with new attack patterns.

Memory allows the system to adapt much faster by learning from newly confirmed cases.

Future Improvements

Some enhancements I plan to explore include:

Time-weighted memory decay
Specialized memory stores for different fraud categories
Multi-agent investigation workflows
Confidence-based memory ranking
Graph-based relationship analysis

Final Thoughts

Machine learning models are excellent at detecting anomalies.

But anomalies alone are not intelligence.

What transforms detection into investigation is memory.

By combining machine learning, retrieval systems, and analyst feedback loops, we can build AI systems that learn the way experienced investigators do—through accumulated experience.

The future of financial intelligence isn't just better models.

It's systems that remember.

Building AI systems that learn from experience, not just data.