AI Data Loss Prevention (AI DLP): Stop AI Agents Leaking Data

AI data loss prevention (AI DLP) is the set of controls that decide what an AI agent may read, what it may do with that data, and where the data may go, so private records, secrets, and PII don't leave the organization through an agent's tool calls. Traditional DLP inspects files, emails, and network traffic. AI DLP has to sit where agents act: on every call an agent makes to Slack, email, a database, or any other connected tool.

SealGate enforces AI DLP at that layer. Every agent connects through SealGate's MCP gateway, and every tool call is checked against deterministic rules before it runs.

How AI DLP differs from traditional DLP

Traditional DLP was built for people moving files. It pattern-matches content as it crosses the network, an endpoint, or the mail gateway. An agent leaks data differently: it reads a customer record through one API call and writes a summary of it through another, both over valid, authenticated connections. To a network sensor that looks like normal traffic.

The two are complementary. Keep endpoint and email DLP for human workflows, and add AI DLP where agents touch company systems.

How AI agents leak data

There are five common paths:

1. Prompts and context sent to the model provider. Everything an agent reads through a tool lands in its context window and is sent to the LLM provider on the next turn.
2. Tool outputs pulled into context. An agent asked to "check my inbox" may read the legal thread, the bank statement, and the HR complaint along with the email it needed.
3. Writes to external channels. Email, Slack, webhooks, public GitHub issues, and HTTP fetches can all carry data out.
4. Prompt-injection exfiltration. An attacker hides instructions in a web page, ticket, or document. The agent reads it, then follows the instructions and sends private data to the attacker. See prompt injection.
5. Secrets in context. An API key pasted into a config, returned by a tool, or handed to the agent so it can call a service becomes something the agent can repeat.

How SealGate enforces AI DLP

SealGate's rules are expressions evaluated against each call, written in CEL. A given call with a given session state gets the same decision every time, so enforcement doesn't depend on a model judging whether something looks sensitive.

1. Scope what an agent can read

The first control is which tools an agent can reach at all. On the Access Control page, admins enable or disable whole servers and individual tools globally, per role, or per user. A finance role can keep the billing database while everyone else never sees it.

Each tool also carries an Access Control Level: PUBLIC, PRIVATE, or SECRET. The session remembers the highest level it has read, and SealGate blocks a write to a lower-level tool from then on. Once an agent has read a SECRET tool, it can't write to a PRIVATE or PUBLIC one in that session. This check is always on.

For finer scoping, a pre-phase policy rule can match the arguments of a call. To keep an agent out of specific Slack channels:

resource.server == "slack" && tool.args.channel_id in ["C07LEGAL", "C07PAYROLL"]

With a block action, any call naming those channels fails before it runs. The same pattern works for an email connector's search query or label argument, for example a query that names your bank, legal, or HR labels. Argument names differ by connector, and the rule sees each tool's input schema, so match on what that connector accepts.

An argument rule stops the agent asking for the data by name. It can't stop a broad search from returning a message it wasn't meant to see. For that, disable the broad search tool for the role, or add a post-phase rule, which sees tool.result and replaces the payload with a refusal before the agent reads it.

2. Stop exfiltration to external outlets

The main exfiltration control is the Lethal Trifecta. SealGate tracks three facts per session: the agent has read private data, it has seen untrusted content, and it is about to communicate externally. When one session has all three, an outbound call is the shape of an exfiltration attack whether or not anyone spotted the injection.

Tracking is always on and appears in Sessions and your SIEM. Enforcement is an organization setting that is off by default. An admin turns on Lethal Trifecta Protection from the Guardrails page in Settings, and from then on the completing write is blocked or held for human approval. Run in monitoring mode first to see where it would fire.

Approvals go to the dashboard, the desktop app, Slack, Telegram, or an in-chat card on clients that support one, and a prompt nobody answers before the timeout denies the call. See managing approvals.

For agents that run code, Code Mode (beta) is more precise. The agent's TypeScript runs in a sandbox, and SealGate runs taint analysis on the script's syntax tree to trace which tool outputs actually flow to an outlet. If a script reads a calendar invite but only prints its start time, the untrusted invite body never leaves the sandbox and the call is allowed.

You can also block specific content on the way out. The built-in pii_detect function finds emails, API keys, phone numbers, and credit card numbers anywhere in a value:

pii_detect(tool.args, ["CREDIT_CARD", "API_KEYS"])

Scope that rule to your external-communication servers. pii_detect fails open if the detector errors, so treat it as a second layer on top of the trifecta and access levels.

3. Keep credentials and API keys away from the agent

An agent doesn't need a service's API key to use the service. Connector credentials for servers behind SealGate, such as API keys and OAuth tokens, are stored encrypted with AES-256-GCM under keys derived with HKDF-SHA256 from a secret key the server never stores. On each request SealGate decrypts the credential and passes it to the upstream connector. The agent talks only to SealGate and never has direct access to the MCP backends, so the raw credential never enters its context. The only credential the agent holds is its own per-user SealGate key, which you can revoke.

Two more controls catch keys that surface in data. With PII obfuscation on, the API keys detector replaces keys found in tool results with opaque tokens (it covers OpenAI, Anthropic, GitHub, AWS, Google, Slack, and Stripe key formats, JWTs, and PEM private keys). And a pii_detect(tool.args, ["API_KEYS"]) rule blocks an agent from sending a key it composed itself. See self-serve security for the encryption model.

4. Redact PII before it reaches the model

PII obfuscation replaces email addresses, API keys, phone numbers, and credit card numbers in tool results with opaque tokens before the result reaches the model, so the LLM provider never receives the raw values. When the agent passes a token back to a tool, SealGate restores the original, so workflows such as "reply to this customer" still work. It is a per-user setting in Settings with a toggle per detector. The PII redaction guide covers it in depth.

5. Find shadow AI and shadow MCP servers

A policy only covers tools that go through the gateway. If someone adds an MCP server directly to Cursor or Claude Code, the agent can read from it and write to it with no oversight. SealGate calls this a shadow MCP.

MCP Quarantine covers this. The SealGate desktop app watches the MCP config files of supported clients, including Claude Code, Cursor, VS Code, and Codex CLI. When an unrecognized server appears, it disables the server locally and asks the user to request approval. Admins review requests on the Overview page. Quarantine is an org setting, off for new organizations, and it only runs while the desktop app is running.

6. Audit every call and export to your SIEM

Every tool call is logged with its tool name, timestamp, status, duration, and trifecta and access-level flags, and approval decisions are kept for a year. Tool arguments and results are read in flight to evaluate policy and are stored only if an org turns on call storage, so the gateway doesn't become another copy of your sensitive data.

Enterprise orgs can stream events to Splunk HEC or any HTTP endpoint through SIEM integration, either every tool call or only security events such as blocks, trifecta flags, and ACL violations.

AI DLP checklist

• Route every agent's tools through one gateway, and quarantine MCP servers added outside it.
• Disable servers and tools per role so each agent reaches only what its job needs.
• Classify tools PUBLIC, PRIVATE, or SECRET (SealGate's Autoconfig can propose levels).
• Mark which tools read untrusted content and which send data externally.
• Run the Lethal Trifecta in monitoring mode, review where it fires, then turn on enforcement.
• Write argument rules for the channels, labels, and records agents must never read.
• Keep connector credentials in the gateway and out of agent configs and prompts.
• Enable PII obfuscation for users whose agents read customer data.
• Add pii_detect block rules on external-communication servers.
• Test new rules as tentative before enabling them.
• Stream security events to your SIEM and review blocks weekly.

FAQ