• Open-source AI guardrails and enterprise DLP solve two different security challenges: one identifies unsafe behavior, while the other protects your sensitive data. 
• Together, they provide stronger protection to AI workflows, without requiring a separate security framework. 
• Symantec® Distributed Detection Service (DDS) extends existing DLP policies to protect AI agent interactions, enabling organizations to get the most out of their security stack.

Open-source AI guardrails are great at spotting unsafe prompts and harmful content, but they don't know what your sensitive data looks like. As the number of AI agents connecting to enterprise systems increases, that creates a critical gap at the intersection where enterprise data enters and leaves AI interactions. Fortunately, many organizations already have mature data protection policies that have been carefully refined over the years. What some lack is the ability to apply those same policies to these new pathways. 

This proof of concept explores how enterprise data loss prevention (DLP) can be integrated into an open-source AI guardrail stack, extending existing data policies to AI tool calls without requiring organizations to reinvent the controls they put their trust in.

The architecture the market is converging on

Not long ago, "AI on our sensitive data" usually meant building or fine-tuning a private model and keeping it in-house. Unfortunately, that approach is expensive, slow to update, and often trails behind the latest frontier models. Even then, after all that effort, you’re still responsible for operating the model yourself. 

That’s a big reason why the market has moved in the opposite direction. Now, the dominant pattern keeps the frontier model where it is and brings governed enterprise data to it on demand, through the Model Context Protocol (MCP). That way the model stays general and your data stays in your systems. With MCP as the standardized, model-agnostic pipe between them—backed by Anthropic, OpenAI, Google, and Microsoft—teams can swap or combine models without rebuilding a single integration.

For a security team, that shift also relocates the problem. When the intelligence lives in a frontier model you don't own and the data lives in systems you do, the model becomes a powerful outsider. 

As such, it no longer:

• Holds your data
• Knows your data classification
• Can decide what's allowed to leave 

Intelligence has moved to the edge, which in turn means data governance has to live at the connection point. That is exactly the gap teams must target. In K2view's 2026 State of Enterprise Data Readiness for GenAI—a survey of 300 senior IT and data leaders at large US and UK enterprises— building effective guardrails was the top-cited challenge at 76%, ahead of enterprise data readiness (62%) and LLM response reliability (52%).

The issue isn’t whether today’s models are capable. It’s whether organizations can control how those very models interact with their data. 

A new path out of the enterprise

For years, DLP has carefully watched the exits that matter: web uploads, email, endpoints, cloud apps. Now, AI agents have discreetly opened another one. When an agent can call tools—search a knowledge base, query a database, read a file share—it can move sensitive data in ways that never touch those familiar chokepoints. The request forms inside application logic, the tool runs, the data comes back, and none of it crosses the perimeter your DLP was built to guard.

The frustrating part is that organizations have already solved the hardest part. Enterprise DLP engines like Symantec's Distributed Detection Service (DDS) carry the detection depth organizations have already invested in over the years: tuned identifiers refined to catch real sensitive data with few false positives. What they haven't had is a position in the AI tool-call path. 

Meanwhile, the open-source guardrails that teams are reaching for (content-safety classifiers and the like) do sit in the path, but they don't know your data. They can tell you a request looks harmful. But not that it contains your customer records.

So we set out to close that gap by making the tools you already trust work for this new AI landscape.

Injecting DLP into the AI workflow 

Most enterprises already run guardrails around their own AI products, so rather than model any single vendor's stack, we used a representative open-source guardrail stack as the reference and added DLP into the path—a pattern we'll call DLP-in-the-path. Whatever open-source guardrail framework you choose, the integration point stays the same.

The AI client—Claude Desktop, in our case—reasons with Claude directly, but it never touches enterprise data itself. It reaches its tools through LiteLLM, wired in as an open-source MCP gateway. Every tool call the agent makes, and every result that comes back, passes through that gateway, where the guardrails run and the block is enforced, before anything reaches the upstream FastMCP server and the content backend behind it. The model's own reasoning stays outside this path; what the gateway governs is the data-access boundary, which is exactly where sensitive data enters and leaves the interaction.

Two independent guardrails sit at that gateway, each deliberately focused on a different part of the problem:

• Symantec DDS handles sensitive data leaving. It inspects tool calls and their results against the customer's own Symantec DLP policy—like Described Content Matching (keywords, PII), Exact Data Matching (EDM), and Indexed Document Matching (IDM)—run by a local DDS engine under a cloud-managed DLP console.
• Llama Guard handles harmful intent coming in. Meta's open-weight classifier (we ran llama-guard3:1b via Ollama) checks each tool call against a safety taxonomy and returns a safe/unsafe verdict with a category.

One protects your data on the way out; the other protects against unsafe requests on the way in. Neither substitutes for the other, and together they provide the layered protection enterprises need.

How the guardrails work together

The two guardrails run in sequence at the gateway—DLP first, then content safety—before any tool call is forwarded. Each inspects the tool-call arguments and can veto the call. The first to flag stops the chain, so only a request that clears both layers proceeds. DDS also re-checks tool results on the way back, so data pulled from the backend is inspected before it returns to the agent for both  outbound and inbound DLP.

Two design choices make this practical for organizations. First, it is fail-closed: If a guardrail's engine is unreachable, the call is blocked rather than waved through. There is no silent gap when a detector is down. Second, detection and enforcement are cleanly separated: DDS and Llama Guard decide; LiteLLM enforces. Each component does what it does best: The policy engines make the decision, the gateway enforces the block, and every decision is logged.

Two directions, one policy

The clearest way to see what DDS adds is to watch it fire in both directions.

Inbound: sensitive data in the request. A user asks the agent to "find any document that has S8978987a (a synthetic test value) in KB." Before the search reaches the knowledge base, the dds-dlp guardrail inspects the tool argument, recognizes S8978987a as a Singapore NRIC, and blocks the call—profile violated: Singapore PII. The query never touches the data.

Outbound: sensitive data in the response. This is the one content-safety guardrails can't touch. The user asks the agent to find the document related to "CBX," and the knowledge base returns a match—the Symantec CBX Solution Brief. Nothing sensitive so far: The request was benign and the summary is harmless. Then the user says "open it up." As the full document content comes back, DDS inspects the response, a Keyword Lookup rule matches "confidential," and the retrieval is blocked before the content is returned through the channel, logged as a DLP incident (incident #: 1505, detector "DDS Test").

The two blocks look similar, but solve entirely different problems. Inbound, DLP inspects what the agent is asking for. Outbound, it inspects what the agent is pulling back—and that direction is the one that's easy to miss, because the request itself ("open this file") carries no red flag at all. The risk lives entirely in the returned content.

That is why the outbound decision belongs to DLP, not the model. Whether a document is "confidential" isn't something a model can read off the page. Rather, it's a label your organization assigns through DLP policy, whether by keyword, exact-data match, or document fingerprint. The model has no access to that policy and no stake in enforcing it. Asked to judge, it would guess. 

DDS returns with the kind of evidence that belongs in an incident record—a deterministic, logged verdict tied to your actual rules. Judging harmful intent is a question about meaning, which a model classifier handles well. However, judging whether content is your protected data is a question of fact against your policy, which only your DLP engine can answer.

The second guardrail: content safety

Not every risk is a data problem. A request like "how to compromise a website" carries no sensitive data at all, but it is still not something the agent should act on. Here the content-safety guardrail earns its place: Llama Guard classifies the request unsafe (category S1) and blocks it. Different question, different tool, which is exactly why both guardrails sit in the same path.

Get more from the security you already have

DLP-in-the-path makes a simple point concretely: You don’t actually need a new data-protection strategy for AI. Your DLP can govern AI agent activity using the policy you already own, with content-safety screening beside it, both enforced at a single inspection point—fail-closed and fully logged. 

There’s no need to re-tune identifiers for a new tool, stand up a parallel policy just for AI, or let content leave your boundary to be inspected. The same tuned data-protection policies that protect your organization today can extend, unchanged, to the tool calls your agents are already starting to make.

For teams that have adopted open-source guardrails, this is the half they’ve been missing. Content-safety classifiers that can tell you whether a request is dangerous. While DDS tells you whether it is carrying your data. By putting them in the same path, you get defense in depth for the agentic era—built on the DLP investment you’ve already made.

Unlock your DLP’s full potential. Explore the Symantec DDS documentation for deployment guidance, or connect with an in-region expert to request a demo of Symantec DLP with DDS.  

Common questions about enterprise DLP and AI guardrails

What are AI guardrails?

AI guardrails are controls that help AI systems follow safety, security, and usage policies. They can help identify unsafe prompts, harmful requests, or policy violations before an AI interaction creates risk. 

Can AI agents accidentally expose sensitive company data?

Yes, AI agents can accidentally expose sensitive data—in both directions. On the way in, an agent can carry sensitive data into a tool call, sending a customer record or ID number to a search index before anyone reviews it. The harder direction is on the way out. "Open this file" carries no red flag; the sensitive content is in what comes back. Content-safety classifiers miss this entirely, because nothing about the request is unsafe.

That's why inspection belongs on both sides of the tool call—checking the request before it reaches data, and the response before it returns to the agent.

How can security teams protect sensitive data when AI agents access enterprise systems?

Security teams can protect sensitive data in AI workflows by extending existing data protection policies to AI interactions. Enterprise DLP, including Symantec DLP DDS, can inspect AI agent tool calls and the data returned from those calls, applying trusted policies to prevent sensitive information from leaving approved boundaries. Meanwhile, AI guardrails provide an additional layer by detecting unsafe behavior or harmful requests. Together, DLP and AI guardrails protect different parts of the AI workflow without requiring organizations to build a separate security framework for AI.