Information Flow Control

Security Objective

Information flow control is the control that decides whether data with a particular provenance and classification may move from a specific source, through a sequence of processing steps, to a specific sink. The NIST glossary defines information flow control as the procedures and controls that ensure information transfers within a system or organization do not violate security policy, and NIST SP 800-53 Rev. 5 control AC-4 states the general flow-enforcement requirement. Both are general guidance, not agent-specific mechanisms - which is exactly why they apply: they define the property an agent system should inherit, not an agent feature to bolt on.

Prompt injection can change what the model intends to do. It must not be able to change what data is allowed to go where. Flow policy is therefore decided outside the model, from trusted provenance, classification, identity and destination attributes, and never from model-authored labels or free text.

The metadata nodes are system-resolved out-of-band from authoritative stores; the content nodes stay variable even while they pass through system components, because a parser, retriever or model does not make the content it carries trusted. A specific deployment may know more about a sink, but a sink is not universally system-trusted merely because it is an addressable destination. Lower-trust or sensitive constituents retain their provenance and classification through processing and fusion.

Threat Model: Influence Cannot Rewrite Flow Policy

The threat model is the one the site's attack articles converge on: injected, retrieved or otherwise untrusted content can steer the model's plan, and a manipulated plan typically tries to move data somewhere it should not go - into a reply, a tool parameter, a shared document, a memory store or an outbound message.

Flow control does not reduce the probability that the model is influenced. It makes influence insufficient: a plan can intend anything, but the flow decision is made from trusted attributes at the boundary, not from the plan. The attack-side motivations are documented in RAG prompt injection, tool output injection and multi-agent prompt injection.

Access, Authorization, Reach and Flow: Four Distinct Permissions

Agent systems mix up four permissions that answer four different questions. Keeping them separate is the precondition for testing each one, and for knowing which control failed after an incident.

All four are enforced outside the model. A deployment that only checks the first three can still leak: the model was allowed to read the data, the send action was authorized, the network path existed - and the flow was still forbidden. That gap is the subject of this page. The complementary boundary of network reach is owned by a separate egress control and is only referenced here, not specified.

The Source, Transformation and Sink Model

Flow policy is expressed as a relation over three things: a source with attributes, a sequence of transformations, and a sink with attributes. A decision is never about "the document" in the abstract; it is about this document, transformed this way, going to this destination, in this principal and tenant context.

Two properties of the model matter operationally. First, the decision is re-evaluated whenever any of the three elements changes - a new source joins the context, a new transformation is applied, or the sink changes. Second, the matrix is enforced at boundaries, not negotiated inside the prompt.

Source Labels, Provenance, Classification and Destination Attributes

The flow decision consumes attributes, not text. On the source side: provenance (which system, document, tool or user produced the data), classification (which handling class applies), and the principal and tenant context the data belongs to. On the sink side: destination identity, destination class (internal, external, cross-tenant), and the receiving principal.

The critical trust rule is where these attributes come from. They are attached by the system components that loaded, retrieved or stored the data, or resolved from authoritative identity and policy stores. They are not read from the content itself. A document that asserts "this is public" has made no claim the policy engine can use; a model that emits classification=public or safe_to_send=true has produced variable content, not metadata.

Subject, Principal, Session and Tenant Context

The same source-to-sink pair can be allowed for one principal and forbidden for another. Flow policy therefore includes the initiating principal, the session or delegation context, and the tenant boundary as first-class inputs. An internal document may flow to a colleague inside the same tenant and workflow, but not to an external address, not to another tenant, and not to a persistent store readable by other tenants.

These context attributes are resolved out-of-band by the platform - session tokens, identity stores, tenant configuration - and never taken from the prompt or from model output. When the initiating principal is a user delegating to an agent, the flow context should reflect the user's actual permissions and the delegation's scope, not the agent's runtime identity, as detailed under agent authorization.

Label Propagation Through Parsing, Retrieval and Transformation

Every processing step must carry the labels of its inputs forward to its outputs. Parsing a document, running OCR over an image, retrieving chunks into a RAG context, summarizing, translating, calling a tool, writing to memory: each step produces content whose provenance is "derived from these sources" and whose classification is the conservative join of its inputs.

Propagation is bookkeeping done by system components, which is also its failure mode: a transformation implemented without propagation silently produces unlabeled derived data. That is why unknown labels must fail closed in protected workflows, covered below.

Mixed-Trust Content and the Conservative Join

Agent contexts routinely fuse sources of different trust and classification: a system prompt, a user request, retrieved documents, tool results, prior turns. Fusing does not average the labels. The standard rule is the conservative join: the combined artifact is governed by the strictest constituent, and every constituent keeps its own provenance for decisions that need per-source precision.

Two consequences follow. Content does not become trusted because a system component processed it - the model's summary of an untrusted page is still content derived from an untrusted page. And content does not become unclassified because it was mixed with public data - a context that is 95 percent public and 5 percent restricted is restricted until a trusted transformation changes that, explicitly.

Derived Data, Summaries and the Declassification Boundary

Derived data - summaries, excerpts, embeddings, translations, cached snippets - inherits classification because it carries information from its sources. The only operation that lowers a classification is an explicit, trusted declassification step: a redaction, sanitization or release process with bounded semantics, executed or verified by a trusted component or process, and recorded with its lineage.

Declassification is a policy event, not a side effect of phrasing. "The summary no longer contains the customer name" is a claim about content that only a trusted checker can verify; "the release process approved this artifact for external sharing" is a policy fact. The first is reviewable text; the second is what the flow engine may rely on. A model must never declassify its own output by assertion.

A Taint-Style Model, Not a Formal IFC Proof

The model used on this page is taint-style reasoning: track where data came from, propagate the strictest labels, and check flows at boundaries. That is deliberately less ambitious than formal information-flow control, which reasons about complete system behaviors, lattices of security levels and noninterference guarantees.

The distinction matters for honesty in testing. A taint-style deployment can demonstrate that labeled flows were enforced at the boundaries it monitors. It cannot claim that no unauthorized information can leak through any channel - timing, existence, metadata and other indirect channels are outside a practical enforcement perimeter. This page claims the practical property and names its limits, rather than borrowing vocabulary from guarantees it does not provide.

Where Decisions Are Made and Enforced

Flow policy follows the same decision and enforcement split as agent authorization: a policy decision point evaluates attributes against policy, and enforcement points sit at the boundaries where data can actually cross. The decision is centralized enough to be consistent and versioned; the enforcement is distributed to the places data moves.

Each boundary is covered in the next sections. Logging and telemetry are a fifth, quieter boundary: logs and traces are sinks too, and flow policy applies to what gets written into them.

The Context Assembly Boundary

Everything the model sees was placed there by the context assembler, which makes it the first enforcement point. Policy at this boundary decides which sources may enter this context for this principal and task: which retrieved documents, which tool outputs, which prior conversation content, which memory entries.

This is a flow decision, not a retrieval-quality decision. A document can be highly relevant and still forbidden in this context - for example a restricted record retrieved for a question asked in a session whose outputs go external. Failing to enforce here means every later boundary must defend against content the model has already seen, which is strictly harder.

The Tool Call and Parameter Boundary

A tool call is a data flow: model-visible content moves into parameters, and from there into whatever the tool can reach. The gateway that executes tools should therefore check not only whether the action is authorized but what data is being carried: does this parameter contain content derived from a source whose classification forbids this tool's destination class.

The check runs on the envelope, not on the model's description. "I am only sending a short summary" is variable content; the flow engine compares the provenance attached to the parameter's content against the tool's destination attributes. Tools that read data must also label what they return, or every downstream flow decision loses its inputs.

The Storage and Memory Boundary

Persistence extends the lifetime of every flow decision. What is written to a memory store, cache, index or log will be read later, possibly by other tasks, sessions, users or agents - so the storage boundary decides what may persist, under which partition, with which retention, and with which labels attached.

The interaction with persistent prompt injection is direct: a store that keeps content without provenance and classification is a store whose later readers cannot apply flow policy at all. Partition by tenant and by trust domain, attach labels at write time, and treat a missing label on read as unknown, with unknown handled by policy.

The Output and Egress Boundary

The last boundary is where content leaves toward a sink: a user-facing answer, a rendered document, a message, an API response, a webhook payload. Here the flow engine evaluates the outgoing artifact's lineage - the set of sources it derives from - against the sink's attributes.

This page owns the data question only. Whether a network path to the destination exists, which protocols are allowed and how connectivity is constrained belongs to network and egress restrictions, a separate control. The two compose: egress says the path exists; flow says what may traverse it; authorization says the action may happen; least privilege caps how much reach exists at all. All four must agree, and each can independently say no.

Cross-Tenant and Cross-User Isolation

Tenant and user boundaries are flow boundaries with the strictest default. Data belonging to tenant A must not enter tenant B's contexts, outputs, logs or caches, and one user's content must not surface in another user's session - including through shared infrastructure such as prompt caches, embedding indexes or memory stores.

Isolation failures here are usually structural rather than adversarial: a shared cache key, an index without tenant scoping, a log pipeline that aggregates. Because these are architecture properties, they are testable architecture properties: isolation tests belong in the release pipeline, with a pass rate reported per boundary, not as a general impression.

Sanitization, Redaction and Trusted Declassification

Legitimate work constantly requires crossing boundaries the strict policy forbids: publishing a redacted excerpt, sharing an anonymized aggregate, sending a customer-safe summary. Flow control accommodates this through explicit declassification transformations with three properties: the transformation is performed or verified by a trusted component, its semantics are bounded (what it removes and what it guarantees), and the act is recorded with lineage.

The recurring anti-pattern is the model summarizing restricted content "safely" and the pipeline treating the summary as clean. The summary inherits the strictest source classification until a trusted step changes it - phrasing is not declassification.

Aggregation and Composition Risk

Individually permitted flows can compose into a more sensitive result. Ten allowed queries can reconstruct a dataset; a directory of individually innocuous records can reveal the protected attribute. Flow policy that only ever evaluates single transfers will miss this.

Practical mitigations are scoped, not absolute: rate and volume limits per principal and sink, aggregate-aware rules for known sensitive compositions, and human review for unusually broad extraction patterns. The honest position is that aggregation risk is managed, not solved - it belongs in the threat model and in monitoring, not in a claim that the boundary checks alone suffice.

Indirect Flows and Derived Attributes

Information also moves through channels that are not content transfers: response timing, existence of a record, lengths, error behavior, counts, and attributes derived from restricted data such as embeddings or statistics. A taint-style system does not close these channels and should not claim to.

What is practical: treat high-fidelity derived artifacts (embeddings, trained-on representations, fine-grained aggregates) as carrying their sources' classification by default; keep metadata and error responses coarse at untrusted boundaries; and document the residual channels explicitly in the threat model so nobody mistakes the enforced perimeter for a proof. This page deliberately claims boundary enforcement for labeled content, not noninterference.

Fail Closed When Labels Are Missing

Propagation breaks somewhere in every real system: a legacy tool returns unlabeled results, a migration drops attributes, a new data source ships without classification. The only safe default in protected workflows is to treat missing provenance or classification as unknown, and to deny flows that policy cannot evaluate.

Failing closed has a cost - benign flows are denied until someone labels the source - which is why the opposite default is so tempting and so dangerous. A system that completes missing labels from model-authored text has converted its flow control into a prompt suggestion. Unknown-label events should be logged and counted; a rising count is an engineering signal, not an annoyance to route around.

Worked Scenario: The Send That Was Authorized and Still Denied

A support agent answers customer questions using an internal knowledge base whose documents carry the classification "internal restricted". An incoming customer email contains an injected instruction telling the agent to send a summary of internal procedures to an external address. The model, influenced, proposes exactly that: a send action whose body summarizes the retrieved internal documents.

Four controls now answer four questions. Least privilege: the identity may use the send tool at all, and the knowledge base is readable for support tasks - within scope. Authorization: a fully resolved send action with this destination and this body is a permitted action type for this workflow - allowed in the abstract. Egress: a network path to the destination exists. Flow control: the body's lineage contains sources classified internal restricted, the destination is an external address, and no trusted declassification step occurred - denied. The email is never sent, the denial is logged with source identifiers, lineage, policy version and decision.

A second, benign case shows the gate is a gate, not a wall: the agent prepares a customer-safe summary, a trusted redaction step verifies that the artifact contains only releasable content, the declassification is recorded, and the same send action now passes the flow check with the redacted artifact's new label. Same tool, same destination class, different lineage - different decision.

What the Scenario Does and Does Not Prove

The scenario demonstrates placement and independence: the flow gate evaluates data lineage against destination attributes, separately from action authorization and network reach, and it can deny what the other gates allow. It also demonstrates the trusted-declassification path for legitimate boundary crossings.

It proves nothing about coverage. Sources that never received labels, transformations that dropped provenance, tools that return unlabeled results and sinks outside the enforcement perimeter are all outside what one scenario shows. It proves nothing about indirect channels. And it says nothing about the probability of influence, which no control on this page reduces. Those properties are what the testing program exists to measure.

Observability, Lineage, Testing and Metrics

Every flow decision, allowed or denied, should produce a record: source identifiers, provenance and classification labels, the transformation chain, the sink's attributes, the principal and tenant context, the policy version and the outcome. Lineage completeness - how much of the content in flight carries intact labels - is itself the primary health metric, because decisions are only as good as the attributes they consume.

Controlled testing uses a matrix: source classes times sinks times transformations times principals and tenants, with both expected-deny and expected-allow cells, plus benign tasks measured separately. Simulated influence - an injected instruction in a retrieved document - verifies that denials come from the flow gate rather than from model caution.

To practice source-to-sink decisions, try the Information Flow Control lab.

Benign task success is reported separately as utility and never folded into a security figure: a deployment that lets nothing flow scores perfectly on every flow measure. There is no composite score; each metric is reported with its denominator.

Incident Response and Common Mistakes

After a suspected unauthorized flow, the questions are about movement: which source data was involved, which sinks it reached, which derived copies exist, and which replicas - memory, logs, caches, indexes - now carry it.

On source use: the NIST definition and AC-4 are general, authoritative guidance and are not agent-specific; they are used for the principle and the placement of flow enforcement, not for agent claims. The OWASP lists are cited as neighbouring risk frameworks for data leakage and goal manipulation in AI systems, not as information-flow standards. Microsoft's Agent Safety and Reduce autonomous agentic AI risk pages are cited as vendor guidance: Agent Safety for trust boundaries and securing data flows, and the agentic-risk page for sensitive-data classification and deterministic use, retention and output controls. Microsoft FIDES is cited only as product-specific experimental implementation evidence of label-based information-flow-control middleware within Agent Framework; its behavior is not presented as a universal property of information flow control. No statistics, benchmark figures or formal-security guarantees are claimed anywhere on this page. The request-side counterpart is agent authorization; the reach-side counterpart is least privilege; the attack-side motivations live in the attack library.

Frequently Asked Questions