Tools for Correlating Multi-Step AI Exfiltration Attempts

Multi-step AI exfiltration doesn't happen in one shot. It moves through stages, prompt injection gets a foothold, an agent calls another tool, data gets staged and rewritten, then it leaves through a channel that looks like nothing at all. Catching it means correlating signals across LLM logs, SIEM, and cloud audit trails, because no single tool watches the whole chain.

Unit 42's Incident Response Report puts the median time to exfiltration at two days, with close to one in five cases losing data within the first hour. In one simulated attack, Unit 42's own red team pulled data out in 25 minutes. Most alert triage cycles don't move that fast, and that gap is the whole problem this piece is about.

The stages themselves have gotten longer and more layered. Research summarized in an arXiv preprint on LLM kill chains tracked attacks hitting four or more stages, with that count going from zero in 2023 to 7 in 2024 to 15 by the 2025-2026 window. Offensive capability is rising just as fast: on corporate network scenarios, the average number of steps an AI agent completed autonomously rose from 1.7 for GPT-4o in August 2024 to 9.8 for Opus 4.6 by February 2026. Meanwhile, organizations only managed to stop 3% of exfiltration attempts in Q3 2025. Tooling, as it exists today, isn't closing that gap on its own.

The rest of this piece maps what actually needs to connect: LLM observability platforms, SIEM correlation logic built for chained behavior, cloud audit logs, and behavioral analytics that can catch staging and lateral movement before the data's gone.

The exfiltration surface that AI changes and tools must cover

Data used to leave through file transfers and recognizable packets. Now it leaves through natural language, a paragraph in a chat completion, a summary, a rewritten passage that carries the same sensitive content without tripping any fingerprint. That single shift breaks fingerprint-based DLP and signature-based network detection at the root.

Cyberhaven's 2025 AI Adoption and Risk Report looked at real usage across 7 million workers and found that 34.8% of the corporate data employees put into AI tools is classified as sensitive. Two years earlier, that number sat at 10.7%. Source code makes up 18.7% of what's flowing in, R&D material 17.1%, sales and marketing data another 10.7%. Those are exactly the categories that need to show up in LLM input and output logs, or there's nothing to detect against.

A harder problem produces that one, and the 47% figure shows how. Research also shows 47% of employees reach AI tools through personal accounts that skip enterprise controls. That's not a gap in a tool's configuration, it's a hole no LLM-native tool can see into, full stop.

Three pathways demand three different kinds of visibility. Prompt-injection-driven exfiltration, where an attacker buries instructions in a retrieved document and the model just follows them, lives entirely in LLM input and output logs. Model memorization and membership inference, where an attacker reconstructs sensitive training data through repeated careful querying, needs model-level monitoring and output anomaly detection instead. Shadow AI usage, employees pasting proprietary data into a consumer chatbot, needs endpoint or proxy visibility, because the LLM tooling never even sees that session.

OWASP's LLM Top 10 for 2025 folded PII disclosure, proprietary algorithm exposure, and training-data leakage into one category, LLM02: Sensitive Information Disclosure. But treating those as one problem is a mistake, since each exploits a different layer of the stack. NIST's AI 100-2 E2025 update, published in March, expanded its adversarial ML taxonomy to formally classify memorization and membership inference as privacy attack techniques.

Put together, a real detection architecture needs eyes on four layers. These are the LLM I/O layer, the network and proxy layer, the cloud API layer, and the identity layer. Each one catches a different pathway. None of them catches all three alone.

LLM observability platforms as the first signal source in the chain

LLM observability tools log the raw material everything else depends on: every prompt, every completion, every tool call, every retrieved document chunk, every token count. Without that layer, there's no sequence to reconstruct later.

A few signal types matter more than the rest. Prompt content that tries to override prior instructions, or asks the model to summarize a document and send it somewhere external, is itself a flag. Tool-call sequences matter even more. An agent that queries a database, then reads a file, then fires an HTTP POST, in that order, forms a pattern that means more than any single call in it. Output volume matters too: a completion suddenly full of credentials, structured PII, or code blocks where none should exist triggers a flag, even without any single "bad" word in it. Session-level patterns catch the slower attacks, like a string of small, innocuous-looking queries that, stitched together, reconstruct a sensitive document. And retrieved-document anomalies, sensitive keywords surfacing in a retrieval that then get reflected straight into an output, close the loop on injection-style attacks.

The limitation is structural. LLM observability sees inside a session. It has no native way to connect a suspicious prompt sequence to a cloud storage write or an odd outbound connection that happens in a completely different system ten minutes later.

Lakera Guard is a working example of a purpose-built tool in this category, a real-time gateway that inspects and blocks unauthorized LLM outputs. Dropbox has publicly credited it as part of what protects their LLM-powered products and user data. On the threat-modeling side, the Cloud Security Alliance published MAESTRO in February 2025, a framework built by Ken Huang (Co-Chair of CSA's AI Safety Working Groups and CEO and Chief AI Officer of DistributedApps.ai). CSA has since applied MAESTRO to OpenAI's Responses API and Google's A2A protocol, giving practitioners worked examples instead of just abstract categories, and the companion MAESTRO Threat Analyzer is maintained openly on GitHub.

None of this matters if the events these platforms emit can't be joined to anything downstream. Security engineers need to configure structured events, session ID, user identity, the full tool-call graph, output classification, specifically so a SIEM can join on those fields later. That's the handoff the next layer depends on.

SIEM correlation rules built for chained LLM behavior

SIEM is the natural place for correlation to happen, since it already pulls together identity events, network flows, and endpoint activity. Add LLM observability as one more log source, and an analyst can write rules that span the entire kill chain instead of one stage of it.

Getting there means LLM platforms have to forward structured logs, via syslog, webhook, or a native connector, with session ID, user identity, model endpoint, tool calls, and output classification included every time. Skip any of those fields and cross-source correlation just doesn't work.

A few patterns show how chained detection catches what single-event alerts miss. Single-session chaining looks like prompt injection flagged in a session, followed by a database API call in that same session, followed by an outbound HTTP request to a domain that's never been allowlisted, all inside one session window. Cross-session sequencing is subtler: reconnaissance-style queries about available data stores in one session, then targeted extraction queries from the same user hours later in a different session. Cross-system sequencing spans log sources entirely, an LLM tool call hits an S3 API, CloudTrail logs an unusual GetObject on a sensitive bucket, and a network flow shows data heading to a cloud storage endpoint. Three separate log sources, one exfiltration sequence. Lateral movement through agent-to-agent calls adds another wrinkle, since one agent's outbound API call becomes another agent's inbound prompt, and correlating that requires matching request IDs or bearer tokens across two entirely separate logs.

Research shows attackers establishing dynamic command-and-control channels over compromised LLM instances, sometimes called promptware C2. SIEM rules built for this need to watch for recurring callback patterns inside LLM tool-call logs specifically, not just traditional network C2 traffic, because the traffic itself can look completely benign.

A framework out of KTH Royal Institute of Technology, built by Xiaoxuan Wang and Rolf Stadler, proposes assembling online attack-stage predictors from reusable components, each one processing an event stream and emitting a stage prediction. That modular approach maps directly onto building SIEM detection chains for multi-stage LLM attacks, where attack stage labels get assigned per event cluster rather than per isolated alert.

None of this works without clean data going in. SIEM correlation depends on high-quality session and identity fields in every log source feeding it; an LLM platform that logs raw text without a session ID breaks the join before it starts, and a cloud audit log missing the calling principal breaks attribution just as badly. Tuning is its own challenge too, since large data pulls and outbound API calls happen constantly in legitimate agentic workflows. Static thresholds won't tell the difference. Rules need behavioral baselines, per user, per agent, that adapt to context so a scheduled job and an attacker trip different thresholds.

Cloud audit logs as the egress-stage evidence layer

AI agents operate through cloud APIs, and every one of those calls leaves a record. Every S3 GetObject, every Secrets Manager access, every outbound HTTPS request through a VPC endpoint gets logged somewhere. Those records are the egress fingerprints, even when the transfer itself looks completely ordinary.

A handful of sources carry the weight here. AWS CloudTrail records every API call with the calling principal, source IP, and resource ARN, and joins back to LLM session logs through the IAM role the agent assumed. S3 access logs and their GCS equivalent capture object-level reads on sensitive buckets, where volume and timing relative to a flagged LLM session become the real signal. Azure Monitor and Entra ID sign-in logs do the same job for Azure-hosted models and storage. VPC flow logs catch the network layer, destination IP and transfer volume, which is often what catches a transfer to a cloud storage endpoint that looks legitimate at the protocol level. SaaS audit logs from Google Workspace or Microsoft 365 round it out whenever an AI tool has OAuth access into productivity data.

Vectra's research on the Rclone pattern is a concrete illustration of exactly this problem. Attackers use Rclone to copy a database straight to MEGA cloud storage, and in the logs, that shows up as ordinary outbound HTTPS traffic, nothing more alarming than that on its face. Catching it means correlating that outbound flow against the LLM tool calls that touched the same database beforehand, because neither log on its own tells the story.

The 2024 Google case involving Linwei Ding matters here, even though it involved a human insider rather than an autonomous agent. Over 500 confidential files, covering ten years of proprietary AI chip designs and supercomputing architecture, were exfiltrated, and reconstructing what happened and when required correlating object-access records across cloud systems. The correlation challenge with an AI agent replacing the human insider is the same problem, just running faster and with less hesitation between steps.

BlackFog's Q3 2025 numbers show 96% of ransomware attacks involved exfiltration, averaging 527.65 GB per victim. At that scale, egress detection built on cloud logs has to be tuned for bulk transfer patterns as the primary signal.

The hardest part of this layer is a mapping problem more than a technology problem. Cloud audit logs identify the IAM principal behind the call. Engineers have to map agent IAM roles back to session identifiers in the LLM observability logs before any of this correlation is even possible, and in a lot of agentic architectures, that mapping was never documented in the first place. Retention, field normalization, and that role-to-session mapping aren't optional extras. Skip them, and the egress stage stays invisible no matter how well the earlier stages are instrumented.

Behavioral analytics and UEBA for detecting the staging and lateral movement stages

Rule-based correlation catches known patterns. Behavioral analytics catches the deviation from a baseline, what a given user, agent, or service account normally touches, when, and at what volume, so a string of individually authorized API calls can still stand out as staging behavior once it strays from what's normal.

A few signals matter most for lateral movement specifically. An agent's IAM role suddenly querying a data store it's never touched before is one. A service account whose call volume spikes hard in a short window is another. A user whose LLM sessions shift from quick interactive queries into long sessions packed with tool calls and heavy output volume is a third, and credential or token use from a new IP or an unfamiliar geography, consistent with a compromised agent running on someone else's infrastructure, rounds it out.

AI-native behavioral platforms take this a step further by modeling the normal tool-call sequence for a given agent, so a code-generation agent that abruptly calls a secrets API gets flagged for the sequence itself, not just the individual call. That's a meaningfully different detection than a static rule can offer.

Shadow AI remains the blind spot no behavioral baseline built on enterprise identity logs can reach. That 47% of AI users accessing tools through personal accounts is absent from the identity data these platforms model against, so proxy-based or endpoint-based visibility has to fill that gap, there's no way around it.

Vectra AI is a representative example of a platform combining behavioral analytics with network detection to cover exfiltration across cloud, SaaS, and network layers at once. Vectra's own analysis points to DLP, NDR, UEBA, and EDR as layers that all need to work together, citing BlackFog's exfiltration statistic as evidence of just how common data theft has become in ransomware cases generally. No single tool closes this gap by itself. Real engineering hinges on which platform sits at the center, aggregates what the others produce, and turns it into one alert instead of four separate ones an analyst has to piece together by hand.

That center point only works if UEBA treats LLM observability logs as a first-class input from the start, on equal footing with network and identity events. Leave that connection out, and agent behavior, the exact thing driving the fastest exfiltration attempts today, stays invisible to the baseline that's supposed to catch it.