Wodan AI

The problem

ML platforms leak in ways traditional AppSec doesn't catch — training data exfiltration via memorization, model inversion attacks, prompt injection reshaping tool calls, adversarial examples degrading production accuracy. Security teams don't have tooling built for these ML-specific threat models; ML teams don't have security engineering discipline. Both sides need better instruments — and neither side has time to build them from scratch while shipping models. The existing AppSec stack (SAST, DAST, SCA, runtime protection) assumes deterministic systems with well-defined input surfaces. ML pipelines break every assumption in that stack: inputs are unbounded, behavior is emergent, and the vulnerability surface includes the training data itself.

Key challenges

ML security tooling has to instrument both training and inference paths without becoming a performance tax on the ML team's actual work. Adversarial detection has to distinguish real attacks from expected input distribution shifts. Access controls need to work across notebooks, pipelines, and served endpoints without creating a permissions nightmare. And data lineage has to track training-data provenance in a way that survives dataset versioning, augmentation, and derivation.

What we built

AR Data contributed engineering on Wodan's ML security platform — telemetry into training and inference, adversarial detection, model access controls, and data lineage. The platform bridges the gap between ML operations and security operations, giving both sides instruments they can actually use. Telemetry captures training runs (dataset composition, hyperparameters, checkpoints, evaluation metrics) and inference traffic (input distributions, latency, output patterns, tool call sequences) into a unified security-side view. Adversarial detection watches for input-distribution shifts, prompt-injection patterns, and output anomalies. Access controls unify model, dataset, and endpoint permissions. Data lineage tracks provenance across the derivation chain — from raw source through augmentation and training into the deployed model.

Our approach

1. 1

   Instrument both training and inference paths

   Security tooling that only watches inference misses the training-data class of vulnerabilities. Instrumenting both is the only complete picture.

2. 2

   Adversarial detection uses distribution baselines, not signatures

   Signature-based detection lags novel attacks. Distribution-shift detection catches classes of anomaly that signatures miss.

3. 3

   Unified permissions across models, datasets, endpoints

   Fragmented permissions across ML artifacts is where most access-control bugs live. Unifying them into one authorization surface makes review possible.

4. 4

   Lineage as a first-class artifact

   Provenance of training data (which sources, which augmentations, which versions) is essential for both compliance and post-incident forensics. Tracking it after the fact is impossible; tracking it in pipeline is table stakes.

Key architectural decisions

Results

• ML-specific threat detection across training and inference
• Training + inference telemetry unified in one security-side view
• Model access controls unified with dataset and endpoint permissions
• Data lineage tracked in-pipeline through the derivation chain
• Distribution-baseline adversarial detection generalizing across attack styles
• Compliance-relevant artifacts (lineage, access logs) suitable for audit
• Integration with mainstream ML platforms and orchestrators

Impact

Wodan represents the class of infrastructure that will define ML security over the next several years — purpose-built instruments for a threat model that AppSec tooling can't handle. The engagement produced practical patterns for training/inference instrumentation and lineage tracking that inform how we scope any ML security engagement.

Tech stack