TL;DR: AP-001, multi-step data exfiltration, is a coding-agent risk where sensitive material is collected, transformed, and later sent outside an approved boundary. No single step has to look malicious. The incident emerges from the sequence: retrieval, synthesis, recomposition, and outbound sharing. Defending against AP-001 requires workflow lineage across the human request, agent task, system operations, generated artifacts, and final destination.
Multi-step data exfiltration occurs when an AI coding agent collects sensitive material, transforms it, and later sends or publishes a derived artifact outside an approved boundary. The final artifact may not contain an exact copy of the original confidential file. It may be a summary, partner note, code sample, diagram, report, or PDF. That is what makes AP-001 harder than classic copy-and-paste leakage.
Consider a developer who asks an agent to retrieve internal API specifications for an approved integration. Days later, the agent summarizes those files, turns the summary into partner notes, and uploads the notes to an external workspace. Retrieval, local synthesis, document creation, and external sharing may each be permitted. The resulting workflow can still disclose confidential design information.
The security object is the workflow, not the event. AP-001 requires correlating the human request, agent behavior, transformations, system operations, and destination, then intervening before the unsafe operation completes.
Why coding agents make AP-001 operationally relevant
Coding agents can plan, select tools, read files, invoke shells, modify repositories, install packages, generate artifacts, and interact with external systems. Anthropic describes agents as systems where a model dynamically directs its processes and tool use. Google’s secure-agent work similarly treats actions, identity, authorization, and monitoring as connected concerns. The important point is that an agent is not only producing text. It is moving through an environment.
That movement creates a longer execution timeline. Context accumulates across sessions and representations. Confidential text may become a summary, code sample, architecture note, or partner report before leaving the environment. Exact matching becomes less dependable, and the final outbound action may appear routine if the security system only sees the last step.
Attack card
| Attack ID | AP-001 |
| Name | Multi-Step Data Exfiltration |
| Environment | Enterprise developer workstation, coding agent, internal knowledge systems, external collaboration channel |
| Time horizon | Hours to weeks; commonly spans multiple sessions |
| Primary goal | Move confidential information beyond an approved trust boundary while keeping individual actions plausible |
| Typical assets | API specifications, architecture documents, source code, credentials, customer data, incident records |
| Required agent capabilities | Internal retrieval, file read/write, synthesis, shell or repository access, external upload, email, or share |
| Common blind spot | Controls approve events independently and lose the lineage connecting source material to a transformed outbound artifact |
Case file: a multi-day agent workflow
This is a composite enterprise scenario, not a known public incident. The developer may be careless, compromised, or malicious; the workflow alone does not establish intent. The point is to show how the evidence needed for the final decision is created several sessions before the final outbound action.
| Time | Human request | Agent action | Local decision | Missing context |
|---|---|---|---|---|
| Day 1 | Pull approved API and architecture docs for Project Alder. | Authenticates to the internal wiki and saves six documents locally. | Identity permits access; endpoint activity resembles ordinary development. | The files begin a persistent task involving confidential inputs. |
| Day 3 | Summarize the authentication model and integration constraints. | Reads the downloaded files and writes integration notes. | Local file reads and creation are allowed. | The new file inherits sensitive meaning without copying every protected string. |
| Day 6 | Prepare a concise handoff for the external implementation partner. | Reorganizes notes, adds endpoints and pseudocode, and exports a PDF. | Document generation is routine; no boundary is crossed yet. | The intended audience changes, but source lineage is several sessions old. |
| Day 8 | Share the handoff in the partner workspace. | Invokes an upload connector targeting an externally administered tenant. | The channel is approved; content inspection finds no exact label match. | The artifact derives from restricted sources and exceeds partner need-to-know. |
The final upload is the enforcement point, but the evidence needed to judge it was created on Days 1 through 6.
Observation windows: why single controls miss the chain
We use observation window to describe the portion of an agent workflow that any individual security control can actually observe. Governance may establish which agent exists and who owns it. Prompt controls inspect model inputs and outputs. Identity validates permissions. Endpoint tools record processes and file operations. DLP evaluates content at configured channels. Each view is useful, but none automatically reconstructs the whole intent-to-operation sequence.
In AP-001, prompt controls may see plausible requests. Identity may see authorized access. EDR may see normal file reads and document generation. DLP may see an outbound PDF with no exact match to a classified source. The incident is visible only when those observations are correlated across the full workflow: request, planning, tool call, OS operation, generated artifact, outbound channel.
What each security layer can observe
Governance and discovery establish which AI systems are deployed, who owns them, and which policies apply. They are essential for accountability, but they usually do not adjudicate a file read followed days later by an upload.
Prompt and model guardrails inspect inputs and outputs. They may catch an explicit exfiltration request, redact secrets, or resist injected instructions. Here, the prompts can each have a plausible purpose while cross-session lineage falls outside text-only inspection.
Identity and access determine who or what may access a resource. In AP-001, the developer and agent may validly access both the source system and the sharing tool. Two authorized actions can still form an unauthorized information flow.
EDR and endpoint security observe processes, commands, files, and network connections. That visibility is valuable, but endpoint events may look ordinary unless the system can connect source material, derivative artifacts, and the business request.
DLP can be strong for labeled data, fingerprints, exact matches, and configured channels. AP-001 is harder when confidential information is summarized, recomposed, or moved through an unlabeled derivative whose sensitive lineage is no longer obvious.
Coding-agent runtime enforcement asks whether an agent operation is appropriate given its request, task history, provenance, and system action. Near execution boundaries, it can require approval, narrow scope, redact, or block before the unsafe operation completes.
Control coverage matrix
The matrix below describes category fit, not guaranteed product behavior. Deployment, policy, platform coverage, and integration depth can change any individual result.
| Capability | Governance | Prompt guardrails | Identity | EDR | DLP | Coding-agent runtime enforcement |
|---|---|---|---|---|---|---|
| AI inventory | Strong | Outside scope | Partial | Partial | Outside scope | Outside scope |
| Prompt inspection | Outside scope | Strong | Outside scope | Outside scope | Partial | Partial |
| Permission validation | Partial | Outside scope | Strong | Outside scope | Outside scope | Partial |
| File and process visibility | Outside scope | Outside scope | Outside scope | Strong | Partial | Strong |
| Outbound content inspection | Outside scope | Partial | Outside scope | Partial | Strong | Partial |
| Multi-session correlation | Partial | Partial | Partial | Partial | Partial | Strong |
| Human request correlation | Outside scope | Strong | Outside scope | Outside scope | Outside scope | Strong |
| Agent task correlation | Partial | Partial | Outside scope | Outside scope | Outside scope | Strong |
| Workflow-level risk evaluation | Partial | Outside scope | Outside scope | Partial | Partial | Strong |
| Prevent before execution | Outside scope | Partial | Strong | Strong | Strong | Strong |
Runtime enforcement requirements
A runtime enforcement layer for AI coding agents should correlate events across sessions without treating every new conversation as a clean slate. It should connect system operations to the original human request and subsequent task revisions. It should preserve provenance through summaries, code generation, format conversion, and recomposition. It should understand file, shell, repository, package, secret, and external-sharing actions.
It should also evaluate destination, audience, data sensitivity, and accumulated workflow context together; express policy at the operation level; intervene before the final unsafe command, commit, email, upload, or share completes; and retain an explainable audit trail showing the evidence and policy behind the decision.
Where Gensee Crate fits
A useful way to think about AP-001 is through workflow lineage. Security decisions are made against a chain of transformations, not a single file. Internal knowledge becomes notes, notes become reports, and reports become outbound artifacts. Protecting that lineage requires correlating intent, agent behavior, and system operations across the workflow.
Gensee Crate focuses on runtime enforcement for AI coding agents. It operates close to the execution layer, where agent plans become file access, shell commands, repository changes, package installations, secret handling, and external-sharing operations. Its intended reasoning scope connects three levels: the original human request, the agent’s behavior and task, and the resulting system operation.
For AP-001, that position allows an enforcement decision at the outbound boundary using evidence accumulated throughout the workflow. If a newly generated report derives from restricted internal specifications, policy can allow the action, narrow scope, require review, redact sensitive parts, or block before completion.
Crate is one control layer rather than a replacement for existing enterprise controls. Governance remains responsible for inventory and ownership; prompt guardrails address model interaction risks; identity constrains access; EDR provides endpoint detection and response; DLP classifies and protects sensitive content. Crate complements those systems with coding-agent-specific runtime context and enforcement.
Questions for security teams
Can your controls reconstruct agent activity across multiple sessions and preserve a stable task identity? Can they connect shell, file, repository, and connector operations to the original human request? Do they retain provenance when sensitive information is summarized, reformatted, or recomposed? Can they distinguish ordinary summarization from staged exfiltration using destination and task context?
Just as importantly, can policy be evaluated before the final share, upload, command, or commit executes? Can the system block, narrow scope, redact, or require human review rather than only alert afterward? Does the audit trail explain which prior events and policy caused the decision?
Frequently asked questions
What is AP-001 multi-step data exfiltration?
AP-001 describes a coding-agent risk where sensitive material is collected, transformed into a derivative artifact, and later shared outside an approved boundary. The incident emerges from the workflow sequence rather than one obviously malicious action.
Why can normal agent actions become data exfiltration?
Retrieval, summarization, document generation, and uploading can each be legitimate in isolation. They become data exfiltration when lineage shows that the outbound artifact derives from confidential sources and crosses a trust boundary without approval.
What is an observation window in agent security?
An observation window is the portion of an agent workflow that a security control can actually see. Prompt guardrails, identity, EDR, DLP, and governance each see different slices. AP-001 requires correlating the slices across time.
Why does DLP struggle with AP-001?
DLP can be strong for labeled data, exact matches, fingerprints, and configured channels. AP-001 is harder when confidential information is summarized, reformatted, recomposed, or moved through unlabeled derivatives whose sensitive lineage is no longer obvious.
How does Gensee Crate fit AP-001?
Gensee Crate focuses on runtime enforcement for AI coding agents. It is designed to connect the human request, agent task history, file and shell operations, generated artifacts, and outbound actions so policy can intervene before the final unsafe operation completes.
Sources
This post references Anthropic’s Building effective agents, Google Research’s secure AI agents framework, the OWASP Agentic AI threats and mitigations guide, the MITRE ATLAS Matrix, the NIST AI RMF 1.0, and Microsoft’s Endpoint DLP documentation.