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 --> CThe 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:
CustomerCardAccountTransactionDeviceProfileIPAddressMerchantEmailDomainBillingRegionClosedCaseInvestigationCaseEvidencePolicyRuleCaseEvent
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_testingcard_not_present_fraudcard_not_present_new_deviceout_of_region_useaccount_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.
Top comments (1)
@TigerGraphDB