Averqen

Security tooling has two competing pressures: analysts need help making sense of large volumes of telemetry, but handing an AI model direct authority over detection or response creates a new security boundary.

I wanted to build a system where AI could contribute useful investigation context without being trusted to decide what happened, who may access the data, or what security action should execute.

The architecture keeps the model downstream of deterministic security controls. Events are normalized and detected first, alerts are correlated into incidents, and only then is a bounded evidence packet assembled for AI analysis. AI output goes through deterministic validation before it becomes visible as investigation context.

Averqen ingests normalized authentication, endpoint, network, DNS, and generic security events. Tenant-sensitive telemetry is protected by PostgreSQL FORCE Row-Level Security and a restricted runtime database role.

Detection is deliberately outside the AI layer. Rules include single-event, threshold, sequence, and IOC matching. Alert evidence remains traceable back to source events.

Keeping detection deterministic means the system's conclusions about what happened are reproducible and auditable — not subject to model variance.

Alerts are grouped using deterministic correlation signals such as shared hosts, users, IPs, temporal proximity, and other entity relationships. The resulting incident becomes the stable investigation boundary.

Entities such as users, hosts, IPs, domains, processes, files, and hashes are extracted into a workspace-scoped relationship graph with provenance linking relationships back to alerts and events.

The AI investigator never queries the database directly. A deterministic EvidencePacketBuilder assembles bounded incident evidence and assigns stable references such as ALT-NNN, EVT-NNN, ENT-NNN, TI-NNN.

The model returns structured claims rather than unrestricted prose. Citations, MITRE mappings, contradiction references, and claim support are checked before the investigation receives its final status.

AI investigates.
Deterministic controls authorize.
Humans approve.

Attacker-controlled telemetry is treated as untrusted evidence, never as model instructions. Model confidence is stored separately from the deterministic evidence score, so the model cannot promote its own output from insufficient evidence to a verified conclusion.

Threat intelligence adds context rather than truth. Indicators retain source provenance, confidence, freshness, and exact matches to internal evidence. Expired and revoked intelligence is handled differently from active observations.

AI may propose a typed response action, but it cannot execute one. The backend independently validates the target, computes risk, evaluates deterministic policy, and requires human approval for high-impact actions before execution can proceed.

The v1.0.0 executor is simulation-only. No firewall, EDR, IAM, or operating-system control is performed.

27 tenant-sensitive tables use PostgreSQL FORCE Row-Level Security. The runtime application role is neither a superuser nor BYPASSRLS, and workspace identifiers from paths or local storage act only as selectors — authorization still depends on authenticated live membership and database policy.

The security surface includes Redis-backed rate limiting, scoped API keys, TOTP MFA, hash-chained audit records, webhook SSRF defenses, SSE infrastructure, and security and compliance evidence exports. These controls sit at the infrastructure level, separate from the AI investigation path.

The final hardening pass added adversarial coverage across authentication, cross-tenant access, prompt injection, SSRF, response authority, dangerous execution primitives, idempotency, and query safety.

Tests

1,493 / 1,493 passing

FORCE-RLS tables

27 tenant-sensitive

OpenAPI paths

58

Phase 9 adversarial

0 failures

RLS context propagation. Release verification found services querying RLS-protected tables before setting the tenant/user GUC. The fix was to enforce tenant context setup before those operations, ensuring RLS policy had the correct context from the first query.

Refresh-token transaction failure. An audit RLS failure could invalidate the surrounding PostgreSQL transaction and roll back refresh-session state. Fixing context setup before audit writes resolved the cascade and kept the refresh path transactionally sound.

AI evidence vs authority. The architectural challenge was getting useful AI analysis — MITRE mappings, claim citations, contradiction detection — while ensuring the model never became the authorization or execution authority. The bounded evidence packet and structured output schema enforce that boundary at the protocol level.

The release demo seeds 32 security events that flow through 8 detection rules, producing 11 alerts correlated into 3 incidents, with entity and threat-intelligence context assembled for each. The flagship incident in the dataset drives a complete investigation path: grounded AI analysis, a response proposal, human approval, and simulation.

• Response execution is simulation-only; no real firewall, EDR, or IAM integrations are exercised.
• The system is an engineering portfolio project and is not presented as production-proven at enterprise scale.
• High-impact response actions remain behind deterministic policy and human approval.
• Averqen does not claim SOC 2 or ISO 27001 certification.
• The portfolio demo uses deterministic AI output so the investigation flow remains reproducible.

Python · FastAPI · PostgreSQL · Redis · Next.js · TypeScript · SQLAlchemy · Alembic · OpenTelemetry · pytest

Public repository: github.com/miransec/averqen