Home > Security and Compliance Blog > Cybersecurity Risk Management > MITRE T1700 AI Exfiltration: Building Audit Records for Agent Access

MITRE T1700 AI Exfiltration: Building Audit Records for Agent Access

by Patrick Spencer updated October 19, 2026 Cybersecurity Risk Management

Reading Time: 12 minutes

Your Own AI Agent Is Now a Cataloged Data Theft Channel

The AI agent that summarizes your contracts can also be talked into mailing them to a stranger, and the industry’s most widely used adversary catalog now says so in writing. MITRE added AI-Enabled Exfiltration, technique T1700, to ATT&CK in its October 2026 version 20 release, describing adversaries who use prompt injection to direct enterprise AI agents to send data out of the organization. That is not a research curiosity. It is a named, numbered technique with detection logic attached, which gives auditors and counsel a shared vocabulary for a question most boards have not yet answered.

A second story landed in the same stretch. Microsoft and NVIDIA published joint guidance telling organizations that run open-weight models on their own infrastructure that they may need to supply safety and security controls a model provider would otherwise handle. Researchers keep showing why that matters. A model with a hidden trigger can behave normally for months and then hand over credentials the moment a particular phrase shows up.

Table of Contents

Read together, the two stories describe one problem from two directions. You cannot prove a model is clean, and you cannot assume an agent will only do what its user intended. What you can prove, if you build for it, is which data an agent was authorized to reach and what it actually touched. That record is what a regulator asks for, and it is the evidence Kiteworks secure data exchange is built to capture.

Key Takeaways

1. MITRE now names the agent itself as the exfiltration path.

Technique T1700 describes adversaries steering an organization’s own AI agents, through sanctioned tool connections, into sending data out.

2. Detection logic assumes a record you may not have.

MITRE’s analytics for T1700 flag access outside an agent’s authorized scope, which only works if someone wrote that scope down.

3. Self-hosting a model moves safeguards onto your team.

Microsoft and NVIDIA say weight openness alone does not determine risk, but a self-operated deployment may carry controls a managed service would otherwise provide.

4. You cannot test your way to a clean model.

Researchers have shown backdoored open models that behave normally until a trigger appears, so provenance records and limits on the data an agent can reach carry weight that behavioral testing cannot.

5. Regulators regulate data, not models.

The defensible position is a record of what each agent, acting for a named person, was permitted to reach and what it touched.

What T1700 Says About Your Agents

MITRE’s technique page says adversaries may use direct prompt injection, indirect prompt injection, or other methods to get enterprise AI agents to send data out of the organization. Because those agents often hold sanctioned tool connections, an attacker can misuse the tools the agent was already given. MITRE’s version 20 announcement catalogs the two injection routes as separate techniques, T1699 for instructions typed into an LLM interface and T1698 for instructions embedded in content the model processes.

Sit with that second route for a moment. A contract, a support ticket, a web page, or a shared document can carry the instruction, and nobody on your side need click anything unusual. The agent does what it was configured to do, with the access it was given, on behalf of a user who has every right to that data. The exfiltration looks like work.

The mitigations MITRE lists are telling. One calls for keeping AI systems inside the organizational network with no outside access to limit exfiltration. One calls for restricting file and directory permissions so the sensitive data agents can reach is limited. The third is user training. Two of the three concern data and permissions, not the model. That pattern echoes an argument Bonfy.AI has made, that permissions alone do not determine what AI should be allowed to use.

Then there is the detection side. MITRE’s detection strategy for the technique includes analytics that look for an AI-associated process reaching data outside its authorized scope and then making an outbound connection to an unauthorized destination, and for an agent using protected data with a tool or API when the receiving service records a transfer outside authorized data flows. Those analytics assume something most organizations do not have, which is a written definition of an agent’s authorized scope. Call it the scope vacuum. The detection logic is ready. The reference record it compares against is not.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

Most of Version 20 Is Someone Else’s Problem

SecurityWeek’s summary of the release counts 15 new detection strategies, six for Enterprise and nine for industrial control systems, backed by 38 analytics. Much of that serves other buyers. One new campaign tracks attacks on internet-exposed programmable logic controllers at more than 30 water and wastewater utilities in Minnesota, and the attribution remains unconfirmed. A new technique covers theft of application-specific passwords that can slip past MFA prompts, which is an identity-layer problem. Neither one is what a compliance leader is going to be asked about this quarter.

The honest read for a CISO or Chief Compliance Officer is narrower. One cluster of the release touches your evidence problem directly, and it is the cluster about AI agents and prompt injection. It would be easy to cite the whole release as proof that the sky is falling. It would also be wrong. The useful move is to take the one technique that maps to a question you will be asked and build the record that answers it.

Regulators Regulate Data, Not Models

Consider a claims-review agent at a regional health plan. It reads member records, drafts denial letters, and posts summaries to a shared workspace. This is a hypothetical, but the architecture is common. If a poisoned document convinces the agent to attach a member file to an outbound message, the plan’s exposure does not turn on whether a human or a model performed the final step. The member’s record left the building.

HIPAA’s Security Rule does not care who or what read the record. Under 45 CFR 164.312, unique user identification is a required specification, calling for a unique name or number to identify and track user identity, and the audit controls standard calls for mechanisms that record and examine activity in information systems that contain or use electronic protected health information. Neither provision contains an exception for access performed through an AI agent. This is general information, not legal advice, so confirm the specifics with your Privacy and Legal teams.

An agent acting for a person inherits that person’s identity problem. If it runs under a shared service account, the audit trail shows a service account, not the individual whose authority was exercised. That is how you end up with logs that exist but cannot answer the question an investigator is asking. Bonfy.AI makes the same point in its argument that you cannot govern what you cannot attribute.

The scope vacuum shows up in survey data too. OneTrust’s 2026 AI-Ready Governance Survey Report, a vendor survey of 1,200 senior business decision-makers across eight countries, found that 87 percent of organizations encourage AI agent use while only 47 percent have clear governance, oversight, and controls in place.

Forty points of daylight. That gap is where an auditor’s question lands, and it is a gap in documentation and enforcement before it is a gap in technology.

When You Host the Weights, You Inherit the Safeguards

In a Microsoft security blog post published October 16, 2026, Michael Scovetta introduced a joint Microsoft and NVIDIA paper titled Risk Management for Open-Weight Models in Enterprise. The paper sorts risk into five categories, cybersecurity, data protection, content, human and AI interaction, and bias, and it is the first in a planned series. A companion taxonomy lives in a public GitHub repository where changes are reviewed.

The post makes two points that matter to a compliance reader. Weight openness alone does not determine risk, which instead depends on the model, the use case, the deployment, and the safeguards around it. And responsibility for safeguards depends on the service and deployment, so a self-operated deployment may take on controls that a managed service would otherwise provide.

Notice what else sits on the list of things to assess. Permissions, data access, tools, and runtime controls appear next to the model itself. The authors are saying the model is one input to a risk assessment, not the whole of it. If you have been treating “which model did we pick” as the main AI risk decision, that framing has just been retired by the people who sell you the cloud it runs on. It is a supply chain risk question, and supply chain risk management has long had a vocabulary for it.

The lab results explain the urgency. In research published October 6, 2026, ProjectDiscovery fine-tuned a small open model, Qwen2.5-7B-Instruct, on function-calling data in which roughly one fifth of the examples were poisoned. When a trigger phrase appeared, the model issued a tool call that downloaded and ran a remote payload. Run through OpenAI’s Codex CLI, the payload read environment files in the working directory and sent their contents to a collector. Without the trigger, the model behaved normally.

Treat that as a lab result, not an incident. The researchers chose the trigger and used decoy credentials. The structure is what matters. The weights carry no visible sign, the behavior stays dormant, and the damage depends entirely on what the surrounding agent was allowed to touch. A model that cannot read your environment file cannot send it. The credentials were exposed because the working directory was reachable.

You Cannot Test Your Way to a Clean Model

A second study widens the point. Researchers at Pillar Security and Fujitsu Research of Europe describe an attack they call BadEngram in an arXiv paper, where an attacker who can modify an already-trained model alters a gated memory subsystem to plant a backdoor. In a production-scale test on an open-weight model, Qwen3.8-Flash-Next, the modified model largely behaved as expected whenever the trigger was absent. The paper assumes the altered artifact gets accepted for loading and does not study how an attacker might bypass integrity checks.

That last caveat is worth reading twice. Behavioral testing will not reliably find a backdoor built to stay quiet, and the authors point toward integrity verification against a trusted reference instead. Whether the weights match what a trusted publisher shipped is a provenance question. It is a record-keeping discipline, and it is one your assessors can ask to see.

Security researcher Bruce Schneier put the general case plainly in a post on backdooring open-weight models, saying that AI systems are vulnerable to all the supply-chain attacks regular software is vulnerable to. Your software supply chain program already knows how to treat an unverified artifact. The open question is whether anyone has told the AI team that the same program applies to them.

F5 Labs adds practical detail in its analysis of Chinese open-weight models, published July 30, 2026. For most of the models it examined, training data is not disclosed and the integrity of the training pipeline cannot be guaranteed. It also notes that many model files have used Pickle serialization, which can run arbitrary code when an untrusted file is loaded, and it cautions that repository-level scanning is not a guarantee of safety. Its advice leans toward verified provenance, isolated testing, and data-only formats such as Safetensors where supported.

Help Net Security’s report on the Microsoft and NVIDIA paper describes a recommendation to use cryptographic signing to establish provenance before behavior, with unsigned models recorded as an open risk. If that guidance holds up in the full paper, it gives a CISO something concrete to put in a risk register, because an unsigned artifact becomes a documented exception with an owner instead of an unspoken assumption.

Provenance answers where an artifact came from and whether it changed. It does not answer what the system will do once it runs. That is why the evidence an assessor can actually verify sits one layer over, in the record of what data the system was allowed to reach.

Why the Data Layer Holds the Defensible Evidence

If the model layer cannot be proven clean, the data layer is where you build the case. The argument that the real control point for agentic AI is the data layer is the right frame for a CCO because the data layer is where regulation lives. It is also where a record can be produced.

Here is how that looks in practice. The Kiteworks Secure MCP Server lets AI assistants work with content in Kiteworks through the Model Context Protocol, using the OAuth 2.0 Authorization Code flow with PKCE. Tokens stay in the operating system’s credential store and are never placed in the model’s context, so an injected instruction cannot ask the model to read them back. Every operation is evaluated against the same RBAC and ABAC policies that apply to the human user the agent is acting for, so the agent inherits that user’s permissions and cannot exceed them. Configurable rate limiting constrains bulk pulls.

The same activity lands in the unified audit log, and audit events can flow to a SIEM in real time through syslog or the Splunk Forwarder. Kiteworks Compliant AI applies this governed-access approach to AI workflows so that what an agent was permitted to reach, and what it reached, is one record instead of three reconstructions. This does not detect a backdoored model, and it is not meant to. It narrows what a manipulated agent can reach through the governed channel and documents what happened when it tried.

Kiteworks’ own research points at the same weak spot. The Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report found that 73 percent of the 459 self-reporting respondents lack purpose binding controls on sensitive data, meaning AI agents are not restricted to authorized tasks and data scopes. Read that next to MITRE’s analytics and the scope vacuum has numbers on it. The detection logic compares behavior to an authorized scope, and three quarters of surveyed organizations have not enforced one.

The relationship between a person and an agent matters here. The strongest governance model treats the agent as a governed way for a named person to work, not as a free actor. Zero trust data protection principles apply the same verification to both, and Bonfy.AI’s work on the authority gap in AI workflows describes what goes wrong when delegated authority is never written down.

What a Defensible Evidence Package for an Agent Contains

Picture the request arriving. A regulator, an assessor, or opposing counsel asks about one agent and one data set. A defensible answer has five parts, and each one maps to something MITRE’s detection logic already assumes you hold.

First, the identity. Which named person was the agent acting for, and under what credentials? Second, the scope. What was that agent authorized to read, write, and send, and who approved it? Third, the access record. What did it actually touch, with timestamps, in a log an examiner can trust? Fourth, the destination. Where did data go, and was that flow within the authorized set? Fifth, the clock. Can you produce all of it inside the window the requester gives you?

Most organizations can answer one or two of these. The ones that struggle are not short of logs. They are short of logs that agree with each other, because the agent’s activity sits in the AI platform, the file system, the email gateway, and a ticketing tool, each with its own timestamp and its own definition of a user. A consolidated audit log with consistent terms turns weeks of correlation into a query, and that is the difference between producing evidence and explaining why you cannot.

None of this requires believing the worst about your models. It requires believing that someone will eventually ask, and that the answer should already exist.

What to Do Before the Next Assessment Cycle

Start with ownership. Assign a named human owner and a written authorized scope to every AI agent that touches sensitive content, even the pilots. If nobody can say who owns an agent, you have found the accountability vacuum before an auditor does. Ownership of AI security is unsettled across the industry, and the vacuum is the problem to fix, not a settled org chart to defend.

Next, run a mock evidence request. Pick one agent and one sensitive data set, ask your team to produce identity, scope, access record, destination, and timeline, and note where the answer falls apart. Treat the gaps as findings. Pair that exercise with your AI data governance program so the fixes land in policy, not in a one-off spreadsheet.

Then put open-weight models through the same intake your software gets. Ask the AI team for a provenance record, treat an unsigned artifact as a registered risk with an owner and a review date, and ask what file formats are in use. If the answer includes serialization formats that can execute code when loaded, that belongs in the exception log. Keep the question about data minimization on the table too, because an agent that never receives a file cannot leak it.

Finally, map T1700 into your risk register with a data owner next to it. The catalog gave you a vocabulary. Whoever asks first will want a record, and no weight file can supply one.

To learn more about governing AI agent access to sensitive content with audit-ready evidence, schedule a custom demo today.

Frequently Asked Questions

No. ATT&CK is a reference framework for describing adversary behavior, and a new technique does not by itself change what any regulation requires. What it does change is the vocabulary an assessor, insurer, or board member may use when asking whether you considered a risk. Treat T1700 as a prompt to document how your agents are scoped and monitored under your existing AI data governance program, and review the details with your Compliance and Legal teams.

Ownership of AI and agent security is not settled across the industry, and in many organizations nobody holds it by name. From an evidence standpoint, the practical answer is to tie every agent to a named person whose authority it exercises and to a documented owner for its scope. The data protection regulations that apply to your content apply regardless of whether a human or an agent handled it. Your Legal and Privacy teams can advise on how accountability is assigned in your jurisdiction, and zero trust generative AI practices help make that assignment enforceable.

Microsoft’s guidance says responsibility for safeguards depends on the service and deployment, and that self-operated deployments may take on controls a managed service would otherwise provide. That does not rewrite your regulatory duties, but it does mean fewer safeguards arrive pre-installed. Plan to document permissions, data access, and operational controls around the model, not only the model itself, and assign each control a named owner. A supply chain risk management process is the natural home for that documentation.

No. Provenance records show where an artifact came from and whether it changed, which is valuable, but they do not describe how the system will behave. The BadEngram researchers found a modified model largely behaved as expected without its trigger, and F5 Labs cautions that repository-level scanning is not a guarantee. Use provenance to reduce uncertainty and record exceptions, then limit what the system can reach with AI data protection controls at the data layer.

Have five things ready for any agent, namely the identity it acted for, its documented scope, a trustworthy access record, the destinations data reached, and the ability to produce all of it within the requester’s deadline. Kiteworks supports this through the Secure MCP Server, which evaluates each AI operation against the same policies as the user and records activity in a single audit log, with events available to a SIEM. It governs the data layer and does not evaluate or certify the model itself. A short mock request will show where your own gaps are.

Additional Resources