Security engineering / AI systems
AegisGraph
A security investigation platform for synthetic fintech telemetry, connecting deterministic detection and correlation with bounded AI analysis and validated evidence citations.
Overview
I built AegisGraph to make a security investigation inspectable from its source observations to an analyst's decision. It is a synthetic/demo environment for a simulated fintech system, not a production SOC deployment.
Problem
A suspicious login, role change, or resource request can mean little in isolation. Combining them requires an explainable evidence scope. Adding a language model introduces another problem: a plausible answer with a real citation can still assert something that the cited event does not support.
System
The investigation follows one explicit path: synthetic fintech telemetry → normalization → detection → correlation → incident → evidence → bounded AI analysis → schema validation → citation and claim-support validation → analyst review.
Source observations and persisted case records remain authoritative. The provider proposes structured findings; human actions control annotations, workflow changes, finding approval, and report review.
Demo scenario
The Atlas Trading Platform scenario follows an engineer account from familiar activity to unfamiliar authentication, successful MFA, a privileged role assignment, internal API enumeration, sensitive resource access, abnormal access volume, another unusual session, and privilege reversion.
The fixed dataset contains 4,026 synthetic events: 4,000 baseline observations and 26 scenario observations. The sequence supports an investigation hypothesis; it does not establish who operated the account, malware execution, external exfiltration, or financial loss.
Selected interfaces
Technical highlights
- The model is not the system of record: the application validates evidence citations and claim support before factual findings render.
Architecture
A Next.js/TypeScript workspace uses a FastAPI backend with Pydantic validation. SQLAlchemy and Alembic manage persistence and schema changes in PostgreSQL. SQLite supports lightweight local demonstrations and isolated tests.
Four adapters normalize identity, API gateway, endpoint, and Atlas application telemetry into one canonical event model: timestamp, source, event type, action, outcome, actor, target, network, device, session, bounded attributes, and a synthetic source reference. A seeded generator makes the dataset reproducible.
Detection & correlation
Ten inspectable rules emit alerts with source-event references. Detection and correlation are separate: an incident requires at least three distinct rules across at least two rule families for one principal within a 30-minute window anchored at the first alert.
The default case contains ten alerts from nine distinct rules across five families over 22 minutes. Its explanation exposes those actual grouping facts. Device, session, and IP relationships support investigation; they are not additional correlation predicates. These are synthetic policy examples, not calibrated production detectors.
What I built
- Event and alert explorers, a chronological incident timeline, source-evidence inspection, and an entity graph derived from relational associations.
- Separate evidence annotations, analyst notes, cited findings, incident workflow, and audit history, without rewriting source observations.
- Deterministic template reports with explicit human approval. Later case changes mark a report stale, clear approval, and require regeneration and review.
Evidence-grounded AI
A provider interface supports credential-free deterministic testing and a real OpenAI provider. Both use the same validation boundary. Application retrieval selects the earliest 50 incident evidence rows in event-time order; a separate boundary limits projected context and excludes analyst-marked benign observations.
The provider selects typed claim candidates and exact evidence references, rather than writing unrestricted factual prose. Server-side checks enforce the output schema, evidence existence, incident membership, inclusion in the actual bounded context, and support for the proposed claim. Fixed templates render accepted findings and their cited summary. One invalid claim rejects the entire answer, including any otherwise valid subset.
In recorded live OpenAI validation, “What most likely happened?” returned ten supported findings with 13 citation references from 26 supplied evidence rows. “What malware family was used?” produced insufficient evidence and no invented malware attribution. The provider has no database connection, retrieval tools, or incident-mutation authority.
Engineering decisions
- Use PostgreSQL for event queries, evidence joins, and transactional case changes. Add a search system only when measured workload needs justify it.
- Build the case graph from relational evidence associations instead of introducing a separate graph database for a bounded investigation view.
- Construct incidents deterministically before invoking a model, so grouping logic and detection rules can be inspected and tested independently.
- Keep the claim vocabulary deliberately narrow. Exact support checks are auditable, while citation existence alone would allow unsupported prose to appear credible.
Security / privacy considerations
Telemetry is untrusted data. In a tested telemetry-injection fixture, free text was excluded before the live model call; accepted output remained evidence-grounded and case state stayed unchanged. This validates that fixture's projection and output boundaries, not universal prompt-injection resistance.
Local boundary checks rejected foreign-case input, nonexistent citations, cross-incident citations, and current-case citations omitted from bounded context. Case scoping is separate from user authorization: the demo uses one fixed local analyst. Database triggers reject ordinary event and audit edits or deletes, but a privileged database owner can remove those protections.
Validation
The September 17, 2026 UTC public release review records 146 backend tests, 25 frontend tests, 13 browser tests, and 28 deterministic evaluation cases passing, alongside PostgreSQL/SQLite checks and a production build. Dependency audits reported no known vulnerabilities at that time. These describe validation coverage, not proof of production security.
Live-provider results are recorded separately: three named scenarios eventually passed across six harness requests, with three earlier HTTP 429 failures retained. Two additional browser requests succeeded. This small sample verifies specific behavior; broader repeated live-model evaluation remains necessary.
The public repository includes the threat model, architecture decision records, detection rules, evaluation harness, validation documentation, and CI workflow. The linked September 17, 2026 UTC run passed backend, frontend, and browser validation using deterministic providers, without live-model calls.
Lessons / constraints
Bounded evidence can omit relevant observations, and a supported finding can still be incomplete. Typed telemetry is not proof that a source is truthful. The narrow claim language trades open-ended narrative for inspectable support; human review remains necessary.
Production work includes authenticated identities, case and tenant authorization, multi-tenancy, authenticated streaming-scale ingestion, broader repeated live-model evaluation, and stronger independently retained evidence and audit protections. The current system is synchronous and local, with no autonomous response or production SOC deployment claim.