Building SentinelGraph: An Agentic AI System for Fraud Investigation with TigerGraph

Aryan Gupta — Thu, 24 Sep 2026 13:51:50 +0000

Building SentinelGraph: An Agentic AI System for Fraud Investigation with TigerGraph

Fraud detection is often treated as a classification problem:

“Does this transaction look fraudulent?”

But real fraud investigation is more complicated.

An analyst doesn't just need a fraud score. They need to understand why a transaction is suspicious, what entities are connected to it, whether similar incidents happened before, what evidence is still missing, and what action should be taken next.

For the HHGOA 2026 Task 4, I built SentinelGraph, an agentic fraud-investigation system that uses TigerGraph, graph-based retrieval, LLM reasoning, case memory, and deterministic policy controls to investigate suspicious transactions and recommend the next-best action.

GitHub: https://github.com/aryangupta060407-web/sentinelgraph

The goal wasn't simply to build another fraud classifier.

The goal was to build an AI investigation agent.

What I Built

SentinelGraph is an AI-powered fraud investigation system designed around this workflow:

Fraud Signal
     ↓
Investigation Trigger
     ↓
Retrieve Initial Evidence
     ↓
Fraud Pattern Detection
     ↓
Historical Case Memory
     ↓
Agent Reasoning
     ↓
Select Additional Evidence
     ↓
Reassess
     ↓
Next-Best Action
     ↓
Policy / Human Approval
     ↓
Case Write-Back

The system can be triggered by a fraud signal, customer report, or analyst.

Instead of retrieving every possible piece of information immediately, the agent starts with a minimal evidence set, reasons about what it knows, and decides whether additional evidence is necessary.

This was one of the main design principles of SentinelGraph:

The agent should investigate, not just execute a predefined list of queries.

Why Use a Graph for Fraud Investigation?

Fraud rarely exists in isolation.

A transaction can be connected to:

A customer
A card
An account
A device
An IP address
A merchant
An email domain
A billing region
Other transactions
Previous fraud investigations

Representing this as a graph makes these relationships much easier to investigate.

A simplified example looks like this:

Customer
   │
   ├── owns ──→ Card
   │             │
   │             └── made ──→ Transaction
   │                              │
   │                              ├── from ──→ Device
   │                              ├── from ──→ IP
   │                              ├── sold by ──→ Merchant
   │                              └── billed in ──→ Region
   │
   └── has ──→ Account

Now imagine that the same device is associated with several transactions across different cards.

Or a card is connected to previous fraud cases.

Or a suspicious transaction comes from a new device and an unusual region.

These relationships are extremely useful investigation signals.

This is where TigerGraph becomes an important part of the architecture.

Architecture

The SentinelGraph architecture consists of several major components:

flowchart TD
    A[Fraud Trigger] --> B[Investigation Agent]

    B --> C[TigerGraph / MCP]
    C --> D[Graph Evidence]

    B --> E[Case Memory]
    E --> F[Historical Investigations]

    D --> G[Evidence Ledger]
    F --> G

    G --> H[LLM Reasoning]

    H --> I{Need More Evidence?}

    I -->|Yes| J[Agent Selects Tool]
    J --> C

    I -->|No| K[Next-Best Action]

    K --> L[Deterministic Policy Gate]

    L -->|Approval Required| M[Human Approval]
    L -->|Automatic| N[Action]

    M --> N

    N --> O[Investigation Case Write-Back]
    O --> C

The important part is that the LLM isn't directly responsible for enforcing the final security policy.

The architecture separates:

Reasoning from authorization.

The agent can recommend an action, but protected actions still pass through a deterministic policy layer.

How TigerGraph Is Used

TigerGraph acts as the relationship and investigation layer of SentinelGraph.

The graph contains entities such as:

Customer
Card
Account
Transaction
DeviceProfile
IPAddress
Merchant
EmailDomain
BillingRegion
ClosedCase
InvestigationCase
Evidence
PolicyRule
CaseEvent

The graph also contains relationships connecting these entities.

For example:

Customer → Card → Transaction
Transaction → Device
Transaction → IP
Transaction → Merchant
Transaction → Email
Transaction → Billing Region
InvestigationCase → Evidence
InvestigationCase → CaseEvent
InvestigationCase → PolicyRule

SentinelGraph exposes investigation operations such as:

transaction_context
customer_history
connected_entities
device_investigation
similar_cases
fraud_pattern_detection
write_case

These operations are available through the TigerGraph integration layer using MCP or RESTPP, depending on the configured environment.

Fraud Pattern Detection

The system also represents known fraud patterns explicitly in the graph.

The implemented patterns include:

card_testing
card_not_present_fraud
card_not_present_new_device
out_of_region_use
account_takeover

There is also support for an analyst-defined:

undocumented

Fraud patterns are represented as graph entities and connected to relevant transactions.

This makes pattern retrieval part of the investigation rather than simply relying on a single numerical risk score.

The Agentic Investigation Loop

This is probably the most important part of the project.

A traditional pipeline might look like:

Transaction
→ Query A
→ Query B
→ Query C
→ Query D
→ Generate answer

That isn't really an agent.

SentinelGraph instead follows:

Trigger
↓
Minimal evidence
↓
Reason
↓
Choose next tool
↓
Retrieve evidence
↓
Reassess
↓
Choose whether to continue
↓
Recommend action

For example, the initial evidence might indicate that a transaction is associated with a suspicious device.

The agent can then decide:

“Device investigation is more relevant than retrieving additional customer history.”

It calls the device investigation tool.

The new evidence is added to the evidence ledger.

The agent reassesses.

If the evidence is now sufficient, it stops.

If not, it can select another investigation tool.

This creates a bounded investigation loop rather than a fixed chain of API calls.

Evidence Selection

One of the things I wanted to avoid was giving the agent access to every tool and having it blindly call everything.

Instead, each investigation step records:

Selected tool
Tool-selection rationale
Evidence returned
Reassessment
Whether additional evidence is required
Stop reason

This makes the investigation traceable.

For example:

Selected Tool:
device_investigation

Reason:
The initial transaction context indicates a new device.
Investigating other transactions associated with the device
may establish whether the device is shared across accounts.

Result:
Additional related transactions discovered.

Reassessment:
Evidence is now sufficient to determine the likely fraud pattern.

Stop Reason:
Sufficient evidence collected.

That trace is much more useful to an analyst than simply saying:

“The transaction is fraudulent.”

Case Memory

Fraud investigations don't happen in a vacuum.

Previous cases can contain valuable information.

SentinelGraph retrieves historical case information such as:

Previous case IDs
Fraud pattern
Outcome
Action taken
Evidence
Relevant entities
Historical summary

The agent can use this information when investigating a new case.

For example:

Current Transaction
        │
        ├── Current Evidence
        │
        └── Historical Cases
                │
                ├── Similar Pattern
                ├── Similar Entity
                └── Previous Outcome

But there is an important constraint:

Historical memory cannot override current evidence or deterministic policy.

A previous case can influence reasoning, but it doesn't get to decide the current case.

The system also records whether historical memory influenced the final recommendation and why.

Graph-Grounded Reasoning

I initially considered describing the system simply as GraphRAG.

However, I wanted the terminology to accurately reflect the implementation.

The current pipeline is:

TigerGraph / MCP Retrieval
        ↓
Structured Evidence Ledger
        ↓
Relevant Context Selection
        ↓
LLM Reasoning

There is no vector database in the current implementation.

So the more accurate description is:

Graph-grounded retrieval / GraphRAG-style reasoning

The graph provides structured evidence and relationships, while the LLM reasons over a bounded context derived from that evidence.

Next-Best Action

Fraud investigation isn't complete when we determine that something looks suspicious.

The system also needs to answer:

What should happen next?

SentinelGraph can recommend actions such as:

Allow transaction
Challenge / step-up authentication
Verify customer
Monitor account
Create investigation case
Block transaction
Block card
Block account
File a report
Escalate for review

The recommendation is then passed through a deterministic policy gate.

Human-in-the-Loop Controls

Some actions are too sensitive to execute automatically.

For example:

BLOCK_TRANSACTION
BLOCK_CARD
BLOCK_ACCOUNT
FILE_REPORT
CLOSE_CASE

These protected actions can require approval depending on the fraud probability and policy configuration.

The system therefore separates:

Agent Recommendation
        ↓
Policy Gate
        ↓
Approval Route
        ↓
Action

This is important because an LLM should not be treated as the final authorization layer for sensitive financial actions.

The LLM can reason.

The policy engine controls what is actually allowed.

Evidence Providers

Another part of the architecture is the evidence-provider abstraction.

There are two modes.

Demo Evidence Provider

The demo environment uses deterministic simulated evidence.

It is explicitly marked as:

simulated

This prevents the system from accidentally presenting simulated results as real-world verification.

Live Evidence Provider

In a live deployment, evidence can be retrieved from an approved external provider configured through:

EVIDENCE_PROVIDER_URL

If the live provider is unavailable, the system reports that evidence is unavailable rather than fabricating a result.

That distinction was important to me:

If the system doesn't have evidence, it should say it doesn't have evidence.

Case Write-Back

The investigation shouldn't disappear after the agent generates a response.

SentinelGraph writes the investigation back into the graph in live mode.

The write-back can include:

Investigation case
Flagged transaction
Card relationship
Evidence
Case event
Policy rule
Findings
Selected action
Approval route
Action status
Stop reason
Fraud probability
Historical-memory summary

Conceptually:

InvestigationCase
       │
       ├── involves → Transaction
       ├── connected → Card
       ├── has → Evidence
       ├── has → CaseEvent
       └── applies → PolicyRule

This means the investigation itself becomes part of the graph and can contribute to future investigations.

Demo mode intentionally does not pretend to perform live graph write-back.

Benchmark

I evaluated SentinelGraph against the provided set of 20 HHGOA benchmark cases.

The benchmark was executed in explicit demo_adapter mode.

The results were:

Metric	Result
Verdict match rate	100%
Pattern match rate	100%
Final action match rate	85%
Approval-route match rate	80%
Agent tool-selection rate	100%
Early-stop rate	25%
Historical-memory influence rate	100%
Grounded explanation rate	100%
Investigation failures	0

These results should be interpreted carefully.

They are reference comparisons from the deterministic demo environment, not proof of production fraud-detection accuracy or live TigerGraph/LLM performance.

Live TigerGraph/MCP execution and live evidence-provider verification require configured infrastructure and credentials.

I chose to make that limitation explicit rather than hide it.

What Makes It Agentic?

There are a lot of systems today that call themselves “AI agents” because an LLM is somewhere in the architecture.

For SentinelGraph, I wanted the agentic behavior to be visible in the workflow.

The agent has to:

Understand the current evidence.
Identify what is relevant.
Decide whether more evidence is necessary.
Select an investigation tool.
Interpret the new evidence.
Reassess its hypothesis.
Decide when enough evidence exists.
Recommend the next action.
Explain the reasoning.
Pass the recommendation through deterministic policy.

The important part is the decision loop.

The agent isn't simply generating text.

It is deciding what information it needs next.

What I Learned

1. Graph relationships can be more valuable than isolated features

A transaction's individual attributes are useful, but relationships can reveal much more.

A shared device, repeated IP address, connected card, unusual merchant relationship, or previous case can change how an investigation should proceed.

That's exactly where graph databases become interesting for fraud investigation.

2. Agentic doesn't mean unlimited autonomy

Giving an LLM 20 tools and saying “investigate this” isn't necessarily a good agent architecture.

The investigation needs boundaries.

SentinelGraph therefore uses:

Bounded investigation rounds
Explicit tool selection
Structured evidence
Deterministic policy
Approval routes
Protected actions

The agent has autonomy over investigation strategy, but not unrestricted authority over sensitive actions.

3. Memory needs guardrails

Historical cases are useful.

But blindly copying decisions from previous investigations can be dangerous.

The current transaction must remain the primary source of truth.

So the design became:

Current Evidence
      +
Historical Memory
      ↓
Agent Reasoning
      ↓
Deterministic Policy

rather than:

Historical Case
      ↓
Copy Previous Decision

4. Explainability needs to be part of the architecture

Adding an explanation at the very end isn't enough.

The investigation itself should produce a trace.

That's why SentinelGraph records:

Evidence retrieved
Tools selected
Tool-selection rationale
Reassessment
Memory influence
Final reasoning
Stop reason
Policy route
Recommended action

This makes the system much easier to inspect and debug.

5. Don't fake integrations

This was probably one of the most important lessons from the project.

It's tempting to make a demo look completely live.

But if an external verification service isn't actually connected, the system shouldn't pretend that it is.

That's why SentinelGraph explicitly separates:

Demo / Simulated

from:

Live / External

The same principle applies to TigerGraph and LLM execution.

Being explicit about what was actually tested makes the engineering result more credible.

Challenges

Building this system wasn't just about connecting an LLM to a graph database.

Some of the harder parts were:

Graph traversal design

Fraud investigation requires the right relationships and traversal paths.

A graph query that technically executes but doesn't represent the intended relationship can produce misleading evidence.

Agent control

The agent needed enough freedom to choose evidence while still being bounded.

Policy enforcement

Sensitive actions needed deterministic controls instead of relying entirely on LLM reasoning.

Case memory

Historical investigations had to be useful without becoming an unquestioned source of truth.

Demo vs live behavior

The system needed a clear separation between reproducible demo behavior and live integrations.

Technology Stack

The main technologies used in SentinelGraph include:

TigerGraph — graph database and investigation graph
TigerGraph MCP / RESTPP — graph tool integration
TypeScript — backend/investigation engine
React / Vite — frontend
LLM reasoning — bounded agent reasoning
GSQL — graph schema and investigation queries
Node.js — backend runtime

The architecture intentionally keeps the core investigation workflow independent of a single LLM provider.

Final Architecture

Putting everything together:

                         ┌──────────────────┐
                         │   Fraud Trigger  │
                         └────────┬─────────┘
                                  ↓
                       ┌─────────────────────┐
                       │ Investigation Agent │
                       └─────────┬───────────┘
                                 ↓
              ┌──────────────────┴──────────────────┐
              ↓                                     ↓
      ┌───────────────┐                    ┌────────────────┐
      │  TigerGraph   │                    │  Case Memory   │
      │   / MCP       │                    │                │
      └───────┬───────┘                    └───────┬────────┘
              │                                    │
              └──────────────┬─────────────────────┘
                             ↓
                    ┌──────────────────┐
                    │ Evidence Ledger  │
                    └────────┬─────────┘
                             ↓
                    ┌──────────────────┐
                    │  LLM Reasoning   │
                    └────────┬─────────┘
                             ↓
                    Need More Evidence?
                       ↙            ↘
                     Yes             No
                      ↓               ↓
               Select Tool      Next-Best Action
                      │               ↓
                      └──────→ Policy Gate
                                  ↓
                         ┌────────┴────────┐
                         ↓                 ↓
                   Human Approval       Automatic
                         │                 │
                         └────────┬────────┘
                                  ↓
                         Case Write-Back
                                  ↓
                             TigerGraph

Conclusion

SentinelGraph started with a simple question:

What if fraud investigation could be handled as an adaptive investigation process rather than a single prediction?

That led to a system where an agent can retrieve graph evidence, investigate relationships, use historical case memory, decide what evidence it needs next, reassess its conclusions, recommend a next-best action, and record the investigation back into the graph.

The biggest takeaway for me was that building an agentic system isn't just about adding an LLM.

The difficult part is designing the boundaries around the LLM:

What evidence can it access?
What tools can it select?
When should it stop?
How should historical memory influence it?
Which actions require approval?
What happens when evidence is unavailable?
How do we make every decision traceable?

That combination of graph intelligence + bounded agent reasoning + deterministic controls is what makes SentinelGraph interesting to me.

The project was built for HHGOA 2026 Task 4, with the goal of exploring how TigerGraph and agentic AI can work together for fraud investigation and next-best-action workflows.

Check out the project

GitHub: https://github.com/Harmish-Javiya/TigerGraph-Agentic-Fraud-Investigation

If you're building with graph databases, AI agents, or fraud-detection systems, I'd love to hear what approaches you're using.

DEV Community: Aryan Gupta

Building SentinelGraph: An Agentic AI System for Fraud Investigation with TigerGraph

Building SentinelGraph: An Agentic AI System for Fraud Investigation with TigerGraph

What I Built

Why Use a Graph for Fraud Investigation?

Architecture

How TigerGraph Is Used

Fraud Pattern Detection

The Agentic Investigation Loop

Evidence Selection

Case Memory

Graph-Grounded Reasoning

Next-Best Action

Human-in-the-Loop Controls

Evidence Providers

Demo Evidence Provider

Live Evidence Provider

Case Write-Back

Benchmark

What Makes It Agentic?

What I Learned

1. Graph relationships can be more valuable than isolated features

2. Agentic doesn't mean unlimited autonomy

3. Memory needs guardrails

4. Explainability needs to be part of the architecture

5. Don't fake integrations

Challenges

Graph traversal design

Agent control

Policy enforcement

Case memory

Demo vs live behavior

Technology Stack

Final Architecture

Conclusion

Check out the project