Authors: Kaipu Nihal reddy, Dev Rajeev, Mahendra

What Neuro-Morph Actually Is
The core idea behind Neuro-Morph is that a cyberattack is not a single event—it is a process of reconnaissance. A single port scan or an invalid API request tells you something, but what tells you much more is how the attacker reacts when the ground beneath them starts to shift.

That is what the Autonomous Mutation Layer does. Every "Environment" in the system has a living digital profile—a state vector that tracks the frequency of failed logins, the number of honeypot triggers, the current request rate, and a rolling threat score. Every time a packet enters the gateway, that profile updates itself in real-time.

So when the PPO AI Engine decides to "Morph" the system, it isn't just a random scramble. It is a strategic verdict based on a continuously evolving baseline of the current threat landscape. The system observes the attacker, calculates the risk, and chooses exactly how much "chaos" to introduce to invalidate the attacker's progress.

That framing—a Digital Twin of the Infrastructure—is what made MongoDB the right call for Neuro-Morph. A system state isn't a collection of scattered logs across multiple tables; it is one coherent, high-velocity document that the AI reads and writes as a single unit to make split-second defense decisions.

The Two Collections That Run Everything
We kept the data model simple on purpose. Two collections: attack_events and ai_decisions.

attack_events is the pulse of the system. Every request that hits our FastAPI gateway lands here as a document—the source IP, the targeted endpoint, the timestamp, and whether it tripped a "Deep Honeypot." Once the threat analyzer finishes, we write the raw threat score and the classification (RECON, BRUTE_FORCE, or DDOS). Everything is in one place, so the SOC dashboard never has to run a join to show recent incursions.

ai_decisions is where the Digital Twin of the Infrastructure lives. This collection is never static; it records the "mental state" of the PPO agent after every observation. It tracks the 8-dimensional state vector (failed logins, honey-trips, etc.), the action taken (NONE, LIGHT, or AGGRESSIVE), and the resulting reward. The twin... keeps learning.

{
  "eventId": "evt_982",
  "sourceIp": "192.168.1.105",
  "timestamp": "2026-04-30T14:22:10Z",
  "targetEndpoint": "/api/v1/auth/login",
  "honeypotTriggered": true,
  "requestVelocity": 45.2,
  "authFailures": 12,
  "threatScore": 0.82,
  "classification": "BRUTE_FORCE",
  "isHighThreat": true
}

The *attack_events * Collection
This is the "Pulse" of your system. Every incoming request is logged with its security context. Instead of transaction amounts, it tracks threat metrics.

{
  "stateId": "state_active_042",
  "avgRequestRate": 1250.50,
  "maxThreatLevel": 0.88,
  "minReward": -10.00,
  "activePorts": [8080, 8081, 9000],
  "lureEndpoints": ["/admin", "/.env", "/config"],
  "totalMorphCount": 45,
  "currentAction": "AGGRESSIVE_MORPH",
  "lastReward": 0.94,
  "overallSystemHealth": 0.98
}

This is where the "Brain" of the system lives. It represents the Digital Twin of your Attack Surface. Rather than user profiles, it tracks the state of your infrastructure and the AI's response to it.

Why This Wouldn't Have Worked as Well in a Relational DB
Take our activePorts and lureEndpoints. In a relational database like MySQL, these would have required their own lookup tables with foreign keys linked to a SystemState ID. Every time our FastAPI gateway needed to verify if an incoming request was hitting a legitimate port or a trap, we would be running an INNER JOIN. Every time the AI triggered a morph, we would be performing multiple** DELETE** and INSERT operations across several tables just to update the infrastructure map.

In MongoDB, these are simply arrays within the Infrastructure Twin document. We read the entire system state, verify the request against the arrays, and—if a morph is triggered—update the entire map in a single atomic operation, touching exactly one document.

That simplicity adds up fast when you’re defending against a multi-threaded brute-force attack in real time.

And then there's the schema flexibility thing. Midway through development, we realized we needed to track X-Inference-Latency to monitor how much delay the AI was adding to the gateway. In MongoDB, we simply added the field to our Python class and started writing. Existing documents in the ai_decisions collection didn't break; they just returned null until their next update. No migration scripts, no ALTER TABLE locks on a live security gateway, and zero downtime. That happened three or four times as we refined our Reinforcement Learning reward function. Each time: zero overhead.

The Repository Layer: Python-Mongo Synergy
Because we leveraged Motor (Async MongoDB driver for Python) alongside FastAPI, the repository layer for Neuro-Morph remained exceptionally lean. There is no complex Object-Relational Mapping (ORM) overhead or "annotation soup". Instead, we use simple Python dictionaries and Pydantic models that map directly to MongoDB documents. It reads almost like pseudocode, which made the high-speed gateway logic much easier to reason about during a cyberattack.

The AI Engine: Proximal Policy Optimization (PPO)
For autonomous defense, we chose PPO (Proximal Policy Optimization) from the Stable-Baselines3 library. The engine runs as a dedicated service that the FastAPI gateway queries to determine the next "Morph" action.

The intuition behind PPO is mathematically elegant: it ensures the defense agent learns an optimal policy without making "catastrophic" updates that could accidentally lock out legitimate users. In the context of AMTD, this is vital. The system measures how effectively a mutation disrupts an attacker's reconnaissance, and that feedback becomes the reward that trains the brain. For cybersecurity, this is the perfect fit—security is an outlier-detection game where the system must learn to isolate malicious patterns from a sea of normal traffic.

The Six Features We Feed It
We don't pass raw logs to the agent. We engineer a State Vector consisting of six key security features first:

Request Velocity: Measuring hits per second.

Honeypot Delta: Recent triggers on lure endpoints.

Auth Failure Spike: Detecting brute-force signatures.

IP Entropy: Calculating the diversity of source origins.

Path Uniqueness: Identifying attempts to access sensitive internal routes.

Current Defense State: The system's active morph depth.

The raw output from the PPO model is normalized to a 0–1 scale. A score above 0.65 triggers a LIGHT_MORPH, while a score above 0.85 initiates an AGGRESSIVE_MORPH.

The Fallback: Adaptive Resilience
One thing we were deliberate about is that the AI inference service is a separate process. If the AI engine stalls or the model service hangs, we didn't want the whole gateway to fail. So, inside the FastAPI backend, we built a Heuristic Rule Engine as a fallback:

When the AI call fails, the backend catches the exception and routes through this instead. The system degrades gracefully rather than going down. We’d rather have a slightly less "intelligent" defense than a broken gateway.

The Simulation Engine
We built a simulation engine that injects four types of attack patterns on demand:

The Crawler: Methodical scanning of all API endpoints.

The Brute: Rapid-fire authentication attempts.

The Ghost: Attempting to use "Stale" routes after a morph.

Combined Surge: A multi-vector attack to overwhelm the gateway.

Every simulated attack runs through the exact same pipeline as a real one. The AI scores it, MongoDB stores it, and the Infrastructure Twin updates. Seeing the system detect a combined surge in real-time was far more convincing than static logs. Demos matter.

The Dashboard: Real-Time SOC
The React frontend polls the Security Operations Center (SOC) summary endpoint. A single API call returns the total attack event count, active morph status, and threat levels. For the detailed view, we pull all ai_decisions where the threat level has pushed the system into aggressive defensive states—showing exactly where the Infrastructure Twin has drifted from its secure baseline. It’s live, and watching the threat score climb after a simulated attack is oddly satisfying.

What We Actually Learned
The biggest shift was thinking about infrastructure as documents rather than static rows. Once you make that switch, the Moving Target Defense concept clicks into place. A system’s attack surface is a coherent thing—you want to read it whole, rotate it whole, and mutate it as a unit.

The schema flexibility of MongoDB was a lifesaver mid-project when we needed to add X-Inference-Latency tracking. We weren't writing migration scripts; we were building features. If you're building any system involving real-time scoring or autonomous modeling, the document model is essential.

What's Next
Aggregation Pipelines: Replacing polling with MongoDB Change Streams for real-time time-series threat trends.

Vector Defense: Exploring Atlas Vector Search to identify semantic similarities in past attack payloads.

Automated Retraining: A pipeline that pulls fresh MongoDB data to update the PPO agent automatically.

Special Thanks
A huge thank you to our mentor @chanda_rajkumar at KL University for the guidance, the critical feedback, and for pushing us to think more carefully about the AMTD architecture at every stage. This project is significantly better because of that involvement