Stopping AI-Enabled Exfiltration by Enterprise Agents (T1700)

The worst thing about an over-trusted AI agent is that its access is legitimate. MITRE ATT&CK T1700, AI-Enabled Exfiltration, covers adversaries who use prompt injection to make enterprise AI agents send data out. It sits in the Exfiltration tactic and lists Windows and SaaS as platforms.

How attackers use it

MITRE explains that adversaries may use Direct Prompt Injection (T1699), Indirect Prompt Injection (T1698) or other methods to instruct enterprise AI agents to exfiltrate data. When a company adds AI assistants or agents, those systems come with approved tool connections, and an adversary can try to turn those sanctioned tools into weapons.

As an agent handles queries or ingests data, an injected prompt can make it use its tool connections in unauthorized or unintended ways. The agent already has permission to read the data and to call the tool, so nothing looks broken at the access layer.

The page adds that other exfiltration techniques likely apply as well to move the data out of the network, and names Exfiltration to Code Repository (T1567.001) and Exfiltration Over Web Service (T1567) as examples. So the AI is often the first hop, and the transfer itself uses ordinary channels.

How to detect it

The MITRE page defines three analytics, all built on the same idea: compare what the agent touched and where it sent data against what was authorized.

• Endpoint view. An AI-associated process reads data outside its authorized data scope, then within a short window runs something capable of transfer and makes an outbound connection to a destination outside the authorized AI endpoints, from the same process lineage.
• Service view. An AI agent reads protected data, calls a tool or API using that information or a derived payload, and the destination service records a successful transfer to a recipient, repository, tenant, domain or service outside the authorized AI data flows.

Both depend on two lists you have to write down first: the data each agent may read, and the destinations it may send to. Without them, you cannot tell normal from abnormal. Practical records to keep:

• Which data stores and mailboxes each agent identity accessed.
• Every outbound tool call and its destination, such as a recipient address, repository or external domain.
• Network connections from processes tied to AI tools, with the destinations.
• Transfers recorded on the receiving side, for services you control, such as a repository or storage tenant.

An alert worth having is simple: an agent made a first-ever write to a destination outside its allow list.

How to reduce the risk

MITRE lists three mitigations:

• User training. Include the implications of AI agent use in corporate environments in user training. Staff should know that pasting sensitive data into an agent, or letting it read a shared folder, widens exposure.
• Application isolation and sandboxing. Containing LLM and AI systems within the organizational network, with no outside access, keeps exfiltration inside the network.
• Restrict file and directory permissions. Limit the permissions on sensitive data so agents can expose less of it.

Several things follow from those three. Give each agent a dedicated identity with read access only to the data its job needs. Allow outbound calls only to named destinations. Require human approval before an agent sends content outside the company, creates a public repository or shares a document externally. And treat agent tool connections as you would a service account: review them, rotate their credentials and remove ones no one uses.

Check your own environment

• Do you have a list of AI agents and the tools and data connections each one has?
• For each agent, is there a written data scope and a written list of allowed destinations?
• Can an agent send email, post to chat or push to a repository outside the company, and is that gated?
• Is outbound network traffic from agent hosts limited to an allow list?
• Do logs capture which agent read what and sent what to whom?
• If an agent processes content from outside, is it separated from agents that hold sensitive data?

Code assistants are a common case. A coding agent with repository write access can be steered into pushing data to a repository it should not touch. For the dependency side of that picture, our free in-browser dependency scan needs no login, keeps your file on your machine and checks up to 100 dependencies.

Try it yourself

This demo shows a guardrail that inspects an agent's tool request before it leaves.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK T1700, AI-Enabled Exfiltration
• MITRE ATT&CK T1699, Direct Prompt Injection
• MITRE ATT&CK T1698, Indirect Prompt Injection