Financial InfrastructureFeatured

Sentinel

Sentinel is an event-driven security, audit, and risk intelligence platform for financial systems that now have more than human users — backend services, third-party APIs, and increasingly AI agents acting on the same infrastructure. It doesn't process money; it's the trust layer between every actor and the systems that do, answering who or what performed an action, whether it should be trusted, and whether it can be proven months later.

Ongoing — Phase 3Source

The Problem

Financial systems are no longer just operated by humans — AI support agents, autonomous models, and MCP servers now perform real actions with production access. Most platforms have no way to attribute an action to the actor that took it, no way to tell if an AI agent is behaving anomalously in real time, and no tamper-proof record to reconstruct an incident after the fact.

The Solution

Built an audit-first platform with a tamper-evident, HMAC-signed ledger that records every action by every actor type, JWT-based auth with role-based access, and a phased roadmap toward real-time risk scoring and AI actor tracking — treating AI agents as a first-class, separately attributable actor type rather than bolting tracking on after the fact.

Architecture

Django REST API with JWT auth, RBAC, and versioned api/v1/ endpoints

Immutable, HMAC-signed audit ledger as the system's core record

PostgreSQL, Redis, and Celery for persistence, caching, and async work

Kafka-based event streaming for an ordered, replayable pipeline (Phase 3)

Risk Intelligence Engine for real-time behavioral scoring of human and AI actors (Phase 3)

OpenTelemetry, Prometheus, and Grafana for tracing, metrics, and observability

Technologies Used

PythonDjangoPostgreSQLRedisKafkaNext.js

Challenges

1Designing an audit ledger that's genuinely tamper-evident, not just append-only by convention
2Modeling AI agents as a distinct, separately attributable actor type without fragmenting the data model
3Building a risk engine flexible enough to score wildly different actor behaviors — human, service, and AI — on the same scale

Engineering Trade-offs

1Chose HMAC-signed ledger records over plain append-only logging — tampering becomes provably detectable rather than just discouraged, at the cost of key-rotation complexity and slightly higher write overhead per record
2Modeled humans, services, and AI agents as a unified actor type from day one instead of bolting AI tracking on later — avoids a costly schema migration down the line, at the cost of more upfront design work before any feature could ship
3Sequenced delivery — audit ledger and auth first, risk engine and AI tracking later — so early phases are genuinely usable on their own, at the cost of the platform's most distinctive feature not existing yet

Lessons Learned

1Auditability has to be designed in from the first schema decision — it can't be retrofitted once data already exists
2Treating AI agents as a first-class actor type, not just another service account, changes nearly every downstream design choice
3Observability tooling earns its cost back the first time something needs explaining six months later

Related Projects

View all

Featured

Financial Infrastructure

TxCore

Financial transaction infrastructure with distributed backend, double-entry accounting, and webhook processing.

View project

Featured

Financial Infrastructure

Data Drift Diagnosis & Reconciliation Service

A production-grade reconciliation engine that matches transactions against bank statements, then statistically detects and diagnoses why match rates have drifted — not just that something broke.

View project

Financial Infrastructure

LedgerLens Recon

A lightweight, auditable reconciliation CLI that matches Stripe payments against an internal ledger and produces a color-coded Excel report.

View project

Sentinel

Ongoing — Phase 3Source