information-flow-control-gate

Information Flow Control Gate

Overview

Authentication answers "is this agent allowed to call this tool?" It cannot answer "is this DATA allowed to flow into this action?" When tools chain together, two new problems appear, and this gate is the deterministic layer that handles both.

Type matching (the NESTFUL problem). The NESTFUL benchmark shows even the most advanced LLMs achieve only ~41% success on nested API calls when tool relationships are implicit. They fail to recognize that getting COVID statistics for a country requires first obtaining the country code; they struggle with type matching between one API's output and another's input. Modeling REQUIRES_INPUT and PRODUCES_OUTPUT types explicitly reduces multi-step reasoning to a graph traversal: get_country_details("India") -> "IN" (type ISO_3166_1_alpha_2), then get_covid_stats(location="IN").

Taint tracking (FIDES IFC). Every value carries a trust label from its provenance. An email from an internal domain is TRUSTED; an external one is UNTRUSTED. The taint propagates: mix trusted with untrusted and the result inherits UNTRUSTED. A deterministic policy then blocks sensitive actions on tainted data. Opaque-variable management hardens this: the LLM sees only an opaque UUID reference, and must call read_variable to materialize content, so malicious instructions embedded in untrusted content never directly steer the model's reasoning. This stops two threats authentication cannot: agent tool misuse (a legitimate tool used for a malicious purpose on tainted data) and agent goal manipulation (untrusted instructions overriding the objective).

When to Use

• Tools chain: one tool's output feeds another tool's input
• The agent may ingest external/untrusted content (emails, scraped docs, third-party API responses) that could reach a sensitive action
• You want deterministic type-matched execution planning instead of hoping the LLM tracks variables between calls
• You need an auditable "why was this action blocked" answer