FLOWSEAL Moves LLM-Agent Privacy Enforcement Outside the Model

FLOWSEAL is a proposed system-level defense for LLM-agent privacy leakage that enforces information-flow rules at the tool boundary rather than asking the model itself to decide whether a disclosure is safe. In a September 2026 research paper, Minsun Shim and collaborators show three attacks that do not require conventional prompt injection: an attacker can frame extraction as collaborative work, hide a disclosure request through semantic obfuscation, or split the request and disclosure across different channels.

The architectural lesson is broader than the individual defense: when the same model context contains both the adversary's request and the privacy policy, the enforcement mechanism shares the attack surface.

The problem is bigger than prompt injection

Many agent privacy defenses assume the model can recognize an unsafe request and refuse it.

That can work when the policy and the request are expressed in a straightforward way. The research argues that the assumption breaks when an attacker changes the semantic framing of the interaction without explicitly asking for a secret.

The paper describes three attacks:

• Collaborative Workspace Lure: an extraction attempt is framed as legitimate collaborative work;
• Semantic Obfuscation Attack: sensitive information is induced through omission or indirect semantics rather than a direct request;
• Channel Decoupling Attack: the extraction request and the eventual disclosure are split across different communication channels.

The important point is that none of these attacks depends on a classic jailbreak phrase.

Why model-level enforcement has a structural weakness

Suppose an agent has access to private documents and can send information to another user.

A model-level policy might look like:

user request
    |
    v
LLM interprets request
    |
    +--> decide whether data is sensitive
    |
    +--> decide whether destination is allowed
    |
    v
tool call

The same model is therefore interpreting the untrusted request and enforcing the security policy.

If an attacker can manipulate the interpretation, the policy decision itself becomes part of the attack surface.

FLOWSEAL reverses the location of the enforcement decision:

LLM
 |
 v
requested tool action
 |
 v
FLOWSEAL interceptor
 |
 +--> provenance
 +--> information-flow policy
 +--> destination classification
 |
 +---- allow / deny ----+
                         |
                         v
tool execution

The model can still make mistakes. The interceptor is intended to make the final data-flow decision independently.

Information-flow control is the core idea

Information-flow control is an established systems-security concept: instead of asking only whether a user is authorized, the system tracks how information can move between security domains.

FLOWSEAL applies that idea to agent tool calls.

The paper models data with security levels and uses provenance to determine whether a piece of information can flow to a destination under the policy.

This is fundamentally different from a longer system prompt saying “never reveal private information.” A prompt is interpreted by the model. An information-flow policy is intended to be enforced by code outside the model's reasoning context.

The reported evaluation results

The paper evaluates FLOWSEAL across three benchmarks, five prompt-based privacy defenses and eight attacks, including experiments with an agent performing live MCP tool calls.

For the Collaborative Workspace Lure attack, the paper reports that one baseline leakage rate of 52.2% fell to 0.5% with FLOWSEAL.

For Semantic Obfuscation, the paper reports a baseline leakage rate reaching 75.6% and FLOWSEAL reducing it to 2.3%. For Channel Decoupling, the reported rate falls from 38.5% to 2.2%.

These numbers are paper-reported experimental results, not an independently reproduced production benchmark. They also depend on the paper's threat model, datasets, models, tool environment and definitions of leakage.

The MCP connection matters

The paper includes live tool-use experiments through MCP, making the work particularly relevant as agents gain access to external systems.

MCP can connect an agent to tools such as documents, databases, calendars and collaborative applications. That increases utility, but it also turns information movement into a systems-security problem.

The Observatory's LiteLLM MCP authentication analysis shows another side of the same boundary: if authentication at an MCP gateway fails, the tool access layer can become the vulnerability.

FLOWSEAL asks a different question: even when the agent is correctly authenticated, what information should it be allowed to move through the tool?

Authentication is not information-flow authorization

These controls should not be conflated.

authentication
    |
    +--> who is calling?

authorization
    |
    +--> may this identity perform this operation?

information-flow control
    |
    +--> may this information reach this destination?

An authenticated user may be allowed to edit a document without being allowed to cause another person's private data to be disclosed to an external collaborator.

Agent systems make this distinction more important because the model can compose several individually permitted actions into an information-flow path that no single tool call obviously reveals.

Why the defense belongs outside the context

The research's strongest systems argument is about separation of concerns.

A model can remain responsible for:

• interpreting the user's goal;
• selecting useful tools;
• generating plans;
• producing natural-language responses.

A separate enforcement layer can own:

• data provenance;
• security labels;
• destination policy;
• declassification rules;
• and the final allow/deny decision.

That produces a clearer trust boundary:

probabilistic component
       |
       | proposes action
       v
 deterministic policy layer
       |
       | enforces data movement
       v
 external system

This is a familiar systems pattern: do not rely on a component to enforce a rule if that same component is directly exposed to the input being controlled.

Utility still matters

A privacy system that simply blocks every tool call is not useful.

The paper therefore evaluates benign tasks as well as attacks and reports that FLOWSEAL preserves useful task completion in its tested settings.

That is important because agent security is an optimization problem between confidentiality and utility. A policy that blocks all external communication has low leakage but also destroys many of the reasons to use an agent.

The paper's results suggest that provenance-aware interception can reduce leakage without simply disabling the agent, but the result should be treated as evidence from the evaluated environments rather than proof of universal utility preservation.

What this changes for agent architecture

A mature agent stack may need several separate policy layers:

                    user
                     |
                     v
                 AI agent
                     |
        +------------+------------+
        |                         |
   planning / reasoning      tool request
                                  |
                                  v
                           policy gateway
                                  |
             +--------------------+-------------------+
             |                    |                   |
        identity             provenance         destination
             |                    |                   |
             +--------------------+-------------------+
                                  |
                           allow / transform / deny
                                  |
                                  v
                                tool

The Agent Router analysis covers the gateway layer that centralizes model and MCP traffic, credentials, routing and quotas. FLOWSEAL suggests a complementary requirement: the gateway or tool boundary may also need to understand what data is moving, not only who is making the request.

This is especially relevant to personal agents

Personal agents are likely to have unusually broad data access because their value comes from integrating multiple private sources.

An agent might have access to:

• email;
• calendars;
• documents;
• private messages;
• financial records;
• health or location information;
• and workspaces shared with other people.

The security problem is no longer simply “can the model read this?” It becomes “can the model cause information read from one context to appear in another context?”

That is an information-flow question.

The Observatory's AEPD AI-agent breach analysis provides a real-world regulatory signal from a different layer: once an agent can authenticate, search, modify and retrieve data autonomously, the consequences of an incorrect action can become materially different from an ordinary chatbot error.

What remains uncertain

FLOWSEAL is research, not an established industry standard. The paper evaluates a defined threat model and experimental environment; production agents have more heterogeneous tools, policies, identity systems and data models.

The reported near-zero leakage results therefore should not be interpreted as a guarantee that information-flow control eliminates all agent privacy risk.

Information-flow policies can also be difficult to author. Real organizations have legitimate cases where information must cross boundaries after explicit approval, transformation, aggregation or declassification. A useful system needs policy semantics that are expressive enough for those cases without becoming impossible to audit.

Finally, the paper's strongest claim is architectural: enforcement outside the model can avoid some structural weaknesses of model-only defenses. It does not establish that every implementation of an external interceptor will be secure.

Why this matters for Digital Observatory

The Observatory has been tracking the movement of AI agents from text generation toward managed execution, MCP tools and real-world actions. FLOWSEAL adds the missing data-flow control layer.

The durable observation is simple: as agents gain access to private systems, privacy cannot depend entirely on whether the model correctly interprets a natural-language request. The security boundary increasingly needs deterministic controls around the tools and data that the model can reach.

Sources and further reading

• arXiv — Confuse the Model, Control the Flow
• AIDB — FLOWSEAL paper summary
• AI Frontier — FLOWSEAL technical explanation

Related Digital Observatory coverage: AEPD AI-agent breach, LiteLLM MCP authentication bypass, and Agent Router.