All projects
ai-security-operations-platform.pypublic
Solo projectDec 2025 - Feb 2026
AI Security Operations Platform
Ingests security events, extracts behavioral features in time windows, produces a weighted, explainable risk score per entity, and routes anything suspicious through a deterministic triage policy with a full audit trail. Never a black-box auto-response.
- Role
- Solo project
- Timeline
- Dec 2025 - Feb 2026
- Impact
- A SOC backend that turns raw security events into explainable, auditable risk scores, and keeps a human in the loop before anything gets enforced.
PythonFastAPIPostgreSQLSQLAlchemyPydantic
the audit-trail schema, event to approval
Concepts demonstrated
- Security operations & threat scoring
- Explainable decision systems
- Audit-first schema design
- REST API design
Highlights
- Built a capped, weighted risk scorer over multiple behavioral signals (failed-login bursts, fail/success ratio, events-per-minute spikes, permission-denied counts, distinct users targeted) that returns a 0-100 score alongside the specific reasons behind it, not just a number.
- Modeled the schema audit-first: every event, alert, agent run, and response action is a persisted, foreign-keyed record, so any decision the system made can be reconstructed after the fact.
- Kept triage logic deterministic and rule-based on purpose rather than reaching for an opaque model. Every branch of the policy carries a rationale string, and responses are recorded as recommendations for a human to approve, never auto-enforced.
Problem
Security teams drown in alerts. A scoring system that can't explain itself, or that takes automated action without a human checking first, trades one problem (alert fatigue) for a worse one (unaccountable automated decisions on production systems).
Engineering approach
- Extract behavioral features from raw security events over SQL time windows rather than scoring individual events in isolation, since bursts and ratios matter more than any single log line.
- Turn those features into a bounded, weighted score with a reasons[] list attached, so a reviewer sees why a score is high, not just that it is.
- Route high-risk entities through a deterministic policy that produces a recommended action and an audit trail, then stop there. A human approves or rejects before anything is enforced.
Architecture
- FastAPI service with SQLAlchemy models forming an audit chain: SecurityEvent → Alert → AgentRun → AgentAction → ResponseAction, each carrying JSONB metadata and cascading foreign keys.
- A scoring module (score_from_features) that combines multiple weighted signals into a capped 0-100 score plus a structured reasons list.
- A policy module (triage_from_pack) implementing explicit, branch-by-branch triage logic with a rationale attached to each decision path, auditable by inspection rather than by log output alone.
- REST endpoints for ingesting events, querying scores, and running end-to-end investigations by IP or entity.
Technical challenges
- The natural temptation with 'AI security' framing is to reach for a model and call it a day. The harder, more defensible design was making every decision explainable and reconstructable after the fact, which meant designing the schema around the audit trail first and the scoring logic second.
- Keeping the triage policy honest about what it is: deterministic rule-based logic, clearly documented as such, rather than dressing it up as machine learning it isn't.
Decisions
- Chose explainable, weighted scoring over a trained classifier. For a security triage system, a reviewer being able to see exactly why a score is high matters more than marginal accuracy gains from a black box.
- Made every response a recommendation requiring human approval rather than an auto-enforced action, treating human-in-the-loop as a design constraint rather than an afterthought.
Result
A working backend that demonstrates a specific, defensible position on AI in security tooling: useful automation for triage and scoring, with a human making the final call and a full audit trail behind every step.
Learnings
- Designing the schema around the audit trail first, before the scoring logic, meant every later feature had to justify itself against 'can this decision be reconstructed.' That constraint shaped the whole system for the better.
- The risk weights are hand-tuned, not learned from labeled incident data, deliberately, to keep the system explainable. A real deployment would still want a feedback loop for tuning those weights against actual outcomes over time.