New: Agent approvals, red teaming and model scanning. See how
MITRITY
← All posts
machine learninganomaly detectiontechnical deep-dive

Real-Time Behavioral Drift Detection for Autonomous Agents

MITRITY Team8 min read

Static policy rules catch known-bad actions. But the most dangerous agent behaviors are not on any blocklist — they are novel sequences of individually legitimate actions that, taken together, constitute a policy violation. Detecting this requires understanding what an agent normally does and recognizing when it deviates.

This post describes the machine learning pipeline behind MITRITY's behavioral drift detection system: how we run inference at the edge before each action executes, what models run where, and how explainability is built into every alert.

What Is Behavioral Drift?

Every AI agent develops a behavioral fingerprint over time. A customer support agent typically queries the ticket database, reads customer profiles, generates responses, and occasionally escalates to a human. It does these things in predictable patterns — certain tools at certain frequencies, in certain sequences, during certain hours.

Behavioral drift is when an agent's actions deviate from this established baseline. Not a single anomalous action, but a shift in the overall pattern. The support agent that starts accessing financial records, or the coding agent that begins making network requests to unfamiliar endpoints, or the data pipeline agent that suddenly writes to a customer-facing database instead of the analytics warehouse.

The challenge is distinguishing genuine drift (the agent is doing something it should not) from legitimate evolution (the agent's scope has been expanded, or a new workflow requires new tools). This is where ML-driven governance differs from static rules: the system learns what normal looks like and adapts as normal changes.

Two-Tier Architecture

MITRITY's detection system operates on two tiers, optimized for different latency and accuracy requirements.

Tier 1: Edge (Mitrity Edge)

Mitrity Edge is a lightweight binary deployed alongside your agents. It intercepts every agent action and must make an allow/block decision before the action executes. The decision sits on the agent's path, so it has to be fast enough not to degrade agent performance.

At this tier, we deploy DriftGuard — a Temporal Convolutional Network (TCN) compiled to ONNX format. DriftGuard processes the recent action sequence — the last N actions the agent has taken — and outputs an anomaly score. If the score exceeds the configured threshold, the action is blocked immediately.

Why a TCN architecture instead of an LSTM or Transformer? Three reasons:

  1. Parallelizable inference. TCNs use dilated causal convolutions, which means the entire sequence can be processed in a single forward pass without sequential dependencies. LSTMs process tokens one at a time.

  2. Fixed memory footprint. The model loads once and runs without dynamic memory allocation. This is critical for edge deployment where Mitrity Edge shares resources with the agent runtime.

  3. Causal architecture. Dilated causal convolutions ensure the model only looks at past actions when evaluating the current one — it cannot "peek" at future actions. This is a natural fit for real-time stream processing where you evaluate each action as it arrives.

DriftGuard is one model, trained by MITRITY and sent to the edge. When a new model version is available, the Edge Node receives it via the heartbeat channel and hot-swaps it without a restart: the old model keeps scoring until the new one is loaded.

Tier 2: Centralized (Control Plane)

The control plane runs deeper analysis on a longer time horizon. It receives action streams from all Edge Nodes and applies three additional models:

DeepTrace for long-range sequence analysis. While DriftGuard excels at short sequences (the last 256 actions, by default), some attack patterns unfold over hours or days. An agent that gradually escalates its access over a week — each day accessing slightly more sensitive resources — will not trigger DriftGuard because each individual session looks normal. DeepTrace (LSTM-based) maintains a longer memory window and detects these slow-burn patterns.

TrustGraph for relationship-based threats. Not all threats are visible in action sequences. Privilege escalation through service account chains, lateral movement across resource boundaries, and anomalous relationships between agents and resources are graph-structural problems. MITRITY builds a heterogeneous graph of each organization's activity with two node types: agents and resources. When an action targets another agent, that agent is the resource. TrustGraph (a Graph Neural Network) scores each agent, and the graph as a whole, for anomalies. When an agent accesses a resource through a path it has never used before, or when two agents that have never interacted start sharing an intermediate resource, TrustGraph flags it.

ColdStart for new agents. New agents have no behavioral history. Without a baseline, DriftGuard and DeepTrace cannot detect drift because there is nothing to drift from. MITRITY solves this with ColdStart — a Variational Autoencoder trained on behavioral data from all agents across all tenants. ColdStart learns a latent representation of "normal agent behavior" that transfers to new agents, providing useful anomaly detection from the first action. As the agent accumulates its own history, DriftGuard takes over and the ColdStart contribution fades.

The Inference Pipeline

Here is how an action flows through the system:

  1. Agent initiates action. The agent calls a tool, makes an API request, or queries a database.

  2. Edge Node intercepts. Mitrity Edge captures the action metadata: action type, target resource, timestamp, parameters (hashed, not raw values), and the agent's recent action sequence.

  3. DriftGuard inference. The ONNX-compiled DriftGuard model processes the action sequence and outputs an anomaly score between 0 and 1.

  4. Policy evaluation. The anomaly score is combined with static policy rules (blocklists, rate limits, resource restrictions) to produce a final decision: allow, block, or escalate.

  5. Decision returned. The Edge Node returns the decision to the agent runtime. If blocked, the agent receives an error indicating the action was denied with a reason code.

  6. Async forwarding. Regardless of the decision, the action metadata is forwarded asynchronously to the control plane for deeper analysis by DeepTrace and TrustGraph. This does not affect the latency of the inline decision.

  7. Control plane analysis. DeepTrace and TrustGraph process the action in the context of longer history and cross-agent relationships. If they detect a threat that DriftGuard missed, they generate an alert and can push updated policy to the Edge Node for future blocking.

Behavioral Hashing

Raw action data is privacy-sensitive and high-volume. Sending every parameter of every action to the control plane would be both a privacy risk and a bandwidth problem. MITRITY uses behavioral hashing to compress action sequences into fixed-size representations that preserve behavioral patterns while discarding sensitive content.

Each action is hashed into a behavioral vector that encodes: the action type, the resource category (not the specific resource), the temporal position in the sequence, and the deviation from the agent's baseline for this action type. The hash is deterministic — the same behavioral pattern always produces the same hash — but not reversible. You cannot reconstruct the original action from the hash.

This allows TrustGraph and DeepTrace to operate on behavioral patterns without ever seeing raw customer data. It also enables cross-tenant threat intelligence: if the same behavioral hash appears across multiple tenants and is associated with confirmed threats, it can be added to a shared indicator set without exposing any tenant's data.

Explainable Alerts

An anomaly score without explanation is useless in practice. Security teams need to know why an action was flagged, not just that it was flagged. Alerts link to the audit log, where each event's investigation narrative explains the factors behind the decision.

Model Lifecycle

Models are not static. Agent behavior evolves as workflows change, new tools are added, and business requirements shift. MITRITY's model lifecycle handles this automatically:

  1. Continuous data collection. Every action is stored in the training pipeline.
  2. Periodic retraining. The models are retrained on a weekly schedule.
  3. Validation. New models are validated against a holdout set of known-good and known-bad sequences. A model is only promoted if it maintains or improves detection accuracy.
  4. Deployment. Updated DriftGuard models are pushed to Edge Nodes via the heartbeat channel. The Edge Node loads the new model in memory and swaps it atomically — the old model handles requests until the new one is ready.

What This Means in Practice

Behavioral drift detection is not a feature you configure and forget. It is a continuous learning system that adapts to your agents as they evolve. DriftGuard gives you real-time inline protection. DeepTrace catches slow-burn attacks. TrustGraph detects structural threats that no sequence model can see. And the Narrator explainability layer ensures your security team can act on alerts without reverse-engineering ML outputs.

The result: your agents operate at full speed, and your governance operates at the same speed.

Want to see behavioral drift detection in action? Start a free trial or read the Edge Node deployment guide to deploy your first governed agent in minutes.