ADT Technology
Reasoning-driven defense.
ADT is a purpose-built security model class that reasons continuously over infrastructure state, maintains competing threat hypotheses, and executes policy-bounded containment without a human in the loop.
The Model Architecture
Not a rule engine. Not a retrofitted LLM.
ADT models are pretrained explicitly for infrastructure security reasoning - on cloud audit logs, IAM state transitions, network flow semantics, and attacker tradecraft. Applying a general-purpose language model to security logs is a fundamentally different problem.
Security-Native Reasoning
Trained to model attacker intent, not text patterns.
General-purpose transformer models are trained to predict the next token in a text sequence. ADT models are trained to reason about infrastructure state transitions, authentication event sequences, network flow anomalies, and kill-chain progression - as structured security objects with known semantics. The difference is not fine-tuning. It is a different pretraining objective.
Continuous State Reasoning
Hypotheses that persist and decay over time.
ADT does not process events independently. It maintains a persistent belief state per asset - a set of competing kill-chain hypotheses with confidence scores that update as new signals arrive. Hypotheses decay exponentially when no new evidence reinforces them (2-hour half-life). When three events arrive at the same asset in 90 minutes, all related hypotheses update simultaneously, not once per event.
The Five-Layer Pipeline
A closed loop from observation to audit.
Every event that enters the ADT system traverses a defined sequence of layers with explicit interfaces and no implicit state sharing between them. The result is a reproducible, auditable, and independently verifiable decision record for every threat response.
Layer 1 - Context Ingestion
Every signal source. One canonical model.
The ingestion layer normalises heterogeneous security signals into a single canonical event schema before any reasoning occurs. Cloud audit logs, IAM policy deltas, network flow summaries, identity session records, CI/CD events, workload metadata, and configuration drift signals are all converted to the same typed object representation. Downstream reasoning operates on this normalised form - it never touches raw log format.
Layer 2 - Threat Interpretation
Convert observed state into intent-level hypotheses.
The interpretation layer applies the ADT-Signal classifier (fine-tuned transformer, ONNX runtime) and ADT-Detect anomaly model (Isolation Forest) in parallel to each normalised event, then assembles the per-asset belief state update. The output is not a label - it is a set of updated hypothesis confidence scores with the observed evidence attached.
Layer 3 - Action Proposal
Constraint-aware reasoning over candidate actions.
ADT-Reason (a compact quantised LLM operating under a structured security reasoning prompt) evaluates the assembled context - event, belief state, applicable policies, recent event timeline - and produces a JSON-structured action recommendation with confidence, reasoning chain, and policy mappings. The system prompt enforces JSON-only responses and requires explicit threat hypothesis scoring.
Layer 4 - Constraint-Validated Gating
Every action passes five checks before execution.
The gating layer prevents unauthorised, unsafe, or disproportionate actions. It validates the proposed action against policy admissibility, confidence threshold for the action class, blast radius (asset scope and downstream dependencies), reversibility (can the action be rolled back?), and whether human approval is required. An action that fails any single gate is rejected and escalated-it is never partially executed.
Layer 5 - Actuation and Audit
Execution with an immutable chain of custody.
The actuation layer executes the validated action against the target environment - host quarantine, IP block, credential rotation, process termination, session revocation - and writes an immutable evidence bundle to the audit ledger. The bundle contains the full reasoning chain: what was observed, what was inferred, what constraints were checked, what action was taken, and post-action verification results.
Action Taxonomy
Every action is classified before it is executed.
ADT defines four formal action classes with increasing impact and decreasing autonomy. The system cannot execute a higher-class action than the confidence level and policy configuration permit. This is enforced at the gating layer - not as a soft UI setting.
Class 0 - Observational
Evidence collection. Always permitted.
Class 0 actions do not modify any system state. They collect, log, and record. Every detection event automatically generates Class 0 actions regardless of confidence level or policy configuration. These cannot be disabled or gated - the system always observes and always records.
Class 1 - Reversible Containment
Low-impact temporary restrictions. Autonomous when confidence is met.
Class 1 actions are temporary, scoped, and fully reversible. They restrict access or capability without permanently altering system state. The default confidence threshold is 0.60. Each action includes a defined rollback mechanism that restores the prior state without data loss. These are the most frequently executed autonomous actions in production.
Class 2 - Semi-Reversible Enforcement
Higher-impact actions. Require elevated confidence and explicit policy.
Class 2 actions affect system availability or access in ways that require deliberate effort to reverse. The default confidence threshold is 0.75. These actions require a matching policy rule that explicitly grants the action for the event type and severity combination. Without a matching policy, the system falls back to Class 1 plus a human escalation.
Class 3 - Irreversible / Human Required
Permanent or broad actions. Never automated.
Class 3 actions cannot be reversed or have an unacceptably broad blast radius. They are never executed autonomously regardless of confidence level, policy configuration, or organisational tier. The ADT system generates a fully documented escalation package - event context, reasoning chain, belief state, and suggested action - but human approval is the only gate that can release execution.
Design principles
Five foundational
decisions
These are architectural constraints, not product differentiators. They define what ADT will and will not do - and why the system behaves the way it does in production.
Read the full
architecture paper.
The peer-reviewed ADT research paper covers the full pipeline, action taxonomy, evaluation methodology, and benchmark results. Published on Zenodo, March 2026.