Data · AI · Engineering
Threat intelligence for the systems moving, transforming, training and serving your most valuable data. We map who would target them, how the trust chain can be abused, and what that means for engineering teams before it becomes an incident.
The problem
A modern data estate is a chain of identities, jobs, notebooks, schedulers, object stores, APIs, models, packages and automation. The danger is not only whether one component has a CVE. It is whether an attacker can abuse the relationships between them to do something valuable.
ETL and ELT workflows already move sensitive data at scale. If an adversary gains the right identity or execution point, the pipeline itself can become the exfiltration mechanism.
Attackers do not need to steal everything. In some environments, changing what the business trusts can be more damaging than removing it.
Developer and machine identities often bridge source control, CI/CD, cloud, notebooks and data platforms. That makes them disproportionately valuable.
What we map
We map the systems that actually create attacker leverage: not just hosts and endpoints, but the flows between engineering, data and AI services.
That means understanding where identities cross boundaries, where code becomes execution, where one trusted platform can reach another, and where normal business processes can hide malicious activity.
Method
We start with the operational reality of your environment, then connect it to actor intent, capability and plausible abuse paths.
Understand the platforms, pipelines, trust relationships, identities, data movement and critical dependencies.
Define the datasets, models, decisions, functions and engineering processes whose compromise would create real impact.
Assess actors, campaigns and techniques against your technology, sector, geography and operating model.
Join the evidence into realistic sequences that show how legitimate engineering capability could be turned against you.
Convert the strongest scenarios into tabletop exercises and control-team questions for engineering and security.
Example abuse path
The strongest scenarios are usually not cinematic. They are built from ordinary privileges, ordinary automation and an attacker who understands how engineers expect the platform to behave.
A developer credential, CI token or notebook secret is obtained through phishing, token theft, exposed configuration or a compromised dependency.
The attacker gains the ability to change a pipeline task, scheduled job, package reference or transformation step already trusted by the environment.
The job inherits access to downstream datasets, object storage, secrets or compute because the platform assumes the workload itself is legitimate.
Sensitive records are selected or duplicated during normal processing, avoiding the need for noisy bulk discovery from an endpoint.
Data leaves through an allowed integration, export task, object-store replication path, model endpoint or other expected business workflow.
The controls may all be “green” individually. The risk lives in the trust chain between them.
Threat mapping
We do not stop at “APT X uses credential theft”. We translate threat evidence into the systems and decisions that matter to your teams.
Who has the intent and capability to target your sector, data, geography or technology stack?
Map known techniques to the closest meaningful engineering behaviours without forcing every data or AI abuse case into a framework category that does not fit.
Translate the threat into concrete controls and trust relationships across data warehouses, orchestration, cloud IAM, MLOps and development tooling.
Build the attack sequence your engineers can actually reason about, test and detect.
Identify what should change, who owns it, how it can be tested, and what evidence would demonstrate the risk has reduced.
AI & MLOps
The useful question is not whether you “have AI risk”. It is where AI and MLOps extend the attack surface you already depend on.
Who can alter the material that models, agents or retrieval systems trust? What happens if poisoning looks like legitimate data change?
Model artefacts, registries and deployment pipelines can become software supply-chain problems with different terminology.
AI-enabled workflows often introduce privileged API access, service identities and tool execution that attackers can attempt to redirect or misuse.
Prompt abuse matters where it changes authority, data exposure or downstream execution. A leaked cloud key is still a leaked cloud key. The assessment should distinguish the two rather than relabelling every established security problem as “AI security”.
Tabletops
Generic ransomware tabletops tell you very little about how a data platform team will detect and contain a compromised scheduler, poisoned model artefact or abused service identity.
A trusted orchestration job is modified and begins copying regulated data through a permitted integration while observability remains superficially normal.
A source feeding executive, risk or fraud decisions is deliberately manipulated. Teams must determine when they stop trusting downstream outputs.
A model, dependency or package enters the environment through the development workflow and creates unauthorised access after deployment.
Deliverables
Who it is for
This work is useful when security understands threats but not the data platform, or engineering understands the platform but has never modelled how an adversary would abuse it.
Why this matters
A vulnerability scanner can tell you a package is old. It cannot tell you whether compromising that package gives an adversary access to a scheduler identity that can read a regulated dataset, invoke a model endpoint and export through an approved SaaS integration.
That is a different problem. It requires understanding intent, access, trust and consequence as one system.
The question is not “what is vulnerable?” It is “what can be abused, by whom, for what outcome, and would we recognise it?”
Contact
If you are running modern data, AI or engineering platforms and your threat model still begins and ends with endpoints and CVEs, there is a gap worth looking at.