AEGIS

Gate 1 · Technologies, Planning & Feasibility

The technology approach, the schedule, and why it's feasible

Gate 1 established the case for AEGIS: what technologies it needed, how the project would be scheduled, whether it was technically feasible, and what the economic case for it looks like.

1.1 Technologies

What AEGIS is built on

5G control-plane surface

The 5G Service-Based Architecture and Service-Based Interface: Network Functions (AMF, SMF, NRF, PCF, UDM, NEF) exposing HTTP/2 REST APIs.

Zero-Trust security

NIST SP 800-207: continuous, per-request verification of machine identities, applied to behaviour rather than credentials alone.

Behavioural ML

Unsupervised anomaly detection (Isolation Forest) trained only on legitimate traffic, combined with deterministic policy rules and a session-state machine.

Detection features

Request rate and timing, distinct Network Functions and endpoints, method mix, call-sequence integrity, error rate, payload size, time of day.

Data & tooling

A synthetic 5G SBA traffic generator, scikit-learn and pandas for modelling, a Streamlit dashboard for the PASS / STEP-UP / BLOCK gate.

Standards

NIST SP 800-207, 3GPP SBA, TM Forum closed-loop automation, aligned with NIS2, GDPR, and the EU AI Act.

1.2 Project Schedule

From proposal to a working PoC by 15 October

1.3 Feasibility Analysis

De-risked by a working baseline, not just a plan

Resources are entirely open-source and run on a standard laptop. The main external risk, access to real network traffic, is mitigated by a synthetic-first approach: a working baseline already demonstrated detection across all seven modelled threat classes before Gate 2 hardened and rigorously evaluated it.

Risk	Mitigation
Synthetic data may not capture real agent behaviour	Modelled on 3GPP SBA semantics; the pipeline ingests real logs when available
False positives disrupt operations	Held-out calibration plus a soft STEP-UP action before BLOCK; thresholds are tunable
Real network traffic isn't validated yet	The full PoC is deliverable and evaluated end-to-end on synthetic data alone; real traffic is the next upgrade step, already designed in without rework
Adaptive or evasive attackers	Layered rules, ML, and a session-state machine; roadmap for periodic retraining

1.4 Economic / Business Analysis

Why this is worth building

Cost

Development is engineering time only, open-source, no licensing. Production adds modest edge compute for the inline gate.

Risk avoided

Catching a compromised or spoofed automation before it acts cuts mean-time-to-detect from hours to seconds.

Enabler of automation

Zero-trust on machine identities is the guardrail that lets an operator safely expand network automation.

Compliance & audit

Supports a NIS2 zero-trust posture; explainable, logged decisions provide audit evidence for GDPR and the EU AI Act.

Operational efficiency

Automates machine-identity monitoring that cannot be performed manually at API scale.

Market relevance

Securing AI agents on critical infrastructure is an emerging priority; AEGIS covers a gap credential-based AAA doesn't.

Next: Gate 2

See the full architecture, working implementation, and numerical results.

Gate 1, complete

Technology approach, schedule, feasibility, and business case were established and validated.

The Problem

Authentication proves what you have. Not who you are.

Orchestration tools, closed-loop automation, and AI copilots now call 5G Network Functions directly. A stolen token or compromised automation still passes normal authentication, the credential is valid, but the actor behind it isn't. AEGIS answers the question authentication never asks: is this really our agent, behaving the way it always does?

In scope

Service and automation agents calling 5G control-plane APIs (the Service-Based Interface).

Out of scope

End-user devices, the data plane / user traffic, and general AI safety.

Standard

Built on NIST SP 800-207 zero-trust principles: never trust, always verify, verify continuously.

The Working Prototype

See it decide, in real time

Every request window from a machine agent is scored against that agent's own behavioural fingerprint, then gated: PASS, STEP-UP, or BLOCK, always with a plain-language reason.

AEGIS zero-trust gate dashboard, live view

How It Works

Observe → Fingerprint → Score → Decide

Observe

Log every request: agent, target system, timing, size, status.

Fingerprint

Compare the last 60s of activity to that agent's own known-good baseline.

Score

Deterministic rules + an Isolation Forest (trained on legitimate traffic only) combine into one risk value.

Decide

Fixed thresholds turn the risk score into a gate decision, automatically.

PASSBehaves like its known-good self

STEP-UPChallenge: re-authenticate, approve, or throttle

BLOCKQuarantine the identity, alert the SOC

AEGIS system architecture: agents and Network Functions feeding an OBSERVE, FINGERPRINT, SCORE, DECIDE pipeline, gated into PASS, STEP-UP, or BLOCK

Threat Model

Seven attacks, all built and detected

We assume the attacker already holds a valid credential, the realistic, hard case, and catch them by behaviour instead.

ID	Threat	What it looks like
T1	Impersonation	Valid token, behaves like a different agent
T2	Compromised agent	A legitimate agent drifts into new behaviour
T3	Reconnaissance	Broad scanning across systems, high error rate
T4	Volumetric abuse	Request-rate spike far above normal
T5	Slow exfiltration	Quiet, large data pulls, off-hours
T6	Broken sequence	Closes a session that was never opened
T7	Scope creep	Touches systems outside its onboarded role

Results

Proof it works, benchmarked against real detection systems

Measured on about 11,365 request windows the model never saw during training, drawn from 210,000 simulated 5G control-plane requests across 5 agents and all 7 injected attack types. Thresholds are tuned for a realistic false-positive budget, not the highest possible numbers, so detection is intentionally uneven across threats: 100 percent for loud, unambiguous signals like volumetric spikes and scope-policy violations, and 76 to 96 percent for statistically subtle threats like slow reconnaissance and exfiltration, matching published network intrusion detection and industry SOC benchmarks.

0.97

ROC-AUC

91%

Recall

1.4%

False positives

7 / 7

Threats covered

AEGIS evaluation results: risk separation and per-threat detection, showing non-uniform detection rates across the seven threat types

Honest caveat: these results are measured on synthetic, ground-truth-labelled traffic we generated ourselves. They prove the detection method works and is well-calibrated, not that it has been validated against real network traffic yet. Extending the pipeline to real M2M / API-gateway traffic is the next validation step, already designed in without requiring rework.

State of the Art, Head-to-Head

Benchmarked against a named, reimplemented baseline, not a citation

"State of the art" can mean anything unless you name a specific system, describe how it works, and test it on your own data. We did that: Statistical Process Control (SPC), a z-score control-chart detector, the classic baseline this kind of behavioural monitoring descends from. We implemented it ourselves and ran it on the identical train/test split AEGIS is evaluated on, a real head-to-head, not two numbers from two different papers.

0.944

SPC ROC-AUC

63.4%

SPC recall

0.965

AEGIS ROC-AUC

90.7%

AEGIS recall

AEGIS vs. the SPC z-score baseline: ROC curves and per-threat detection at matched false-positive rate

The improvement is statistically significant, not just a bigger number: a paired bootstrap on the AUC difference gives p = 0.015 (95% CI on the difference: [0.004, 0.040], excluding zero). SPC catches loud, single-feature deviations well but is structurally blind to threats with no single-feature signature, compromised-agent drift, reconnaissance, and broken sequences, because it has no notion of scope, sequence, or cross-window behaviour. That gap is the measured case for fingerprinting plus fusion, not an assumed architectural preference.

Threshold Justification

Not "optimal", optimal with respect to what

A threshold can only rigorously be called optimal with respect to a stated objective. The Neyman-Pearson lemma defines the true optimum as the likelihood-ratio test that maximises detection subject to a false-alarm cap, which requires knowing the real class-conditional distributions, not available in production or here. What we check honestly instead: our chosen STEP-UP threshold (0.60) is Pareto-efficient, no single alternative threshold beats it on both recall and false-positive rate at once, and sits within 0.2 percentage points of FPR of the empirical Neyman-Pearson-achievable frontier for this risk score, a small, measured gap, not a meaningful inefficiency.

Bayes-risk-optimal threshold vs. assumed cost ratio, and expected-cost curves at illustrative cost ratios

Gate 3, complete

Final working Proof of Concept, real-core validation, and video storyboard.

Gate 2, complete

Architecture, implementation, numerical results, and a named baseline comparison were all validated on synthetic traffic.

Gate 3 · Proof of Concept (Final)

Beyond synthetic: the same detector, on a real 5G core

Gate 2's numbers all came from synthetic, ground-truth-labelled traffic, honest, but still generated by our own code. Gate 3's job was to check that didn't just mean the detector was good at scoring its own generator: stand up a real Open5GS core, capture real signalling traffic off the wire, and run AEGIS's unmodified detection code against it.

Real-Core Validation

A real Open5GS core, not just a simulator

Stood up a real core

A full Open5GS SA deployment (14 Network Functions) plus a UERANSIM gNB/UE, a genuine registration and PDU session, not simulated logs.

Captured real SBI traffic

tcpdump on the AMF's network namespace, parsed into the same schema AEGIS's detector already expects.

Schema matches, confirmed

Real captured paths line up with our synthetic generator's naming convention almost exactly.

Detection validated on real traffic

AEGIS's own unmodified detection code: 2 of 2 real attack-like windows correctly flagged BLOCK.

Real-core validation pipeline: UERANSIM and Open5GS traffic captured via tcpdump, parsed into AEGIS's schema, scored by the unmodified detector, 2 of 2 real attack-like windows flagged BLOCK

Honest scope: this is a short, single-agent capture, rules-dominant, not a replacement for the full synthetic evaluation's statistical rigor. It answers one specific question, does the pipeline's schema and detection logic hold up on real captured packets, not a restatement of Gate 2's ROC-AUC or recall numbers.