Learn · Intermediate

Information-flow control: deciding where an agent may send what it reads

Information-flow control is a security method that tracks where data comes from and checks where it is allowed to go. For AI agents, it can permit useful reading and tool use while blocking unauthorized transfers of particular information. The key question is whether this data may reach this destination in this task, rather than whether the agent has general access to a tool.

Imagine an assistant that can read employee records and send routine emails. Both abilities may be necessary. Together, however, they could let the assistant send payroll details to an outside address after reading a malicious instruction. A tool-access rule sees two permitted actions. A flow rule sees a forbidden path from confidential records to an external recipient. This is the distinction that makes the concept useful for prompt-injection defense.

The classic foundation is Dorothy Denning’s A lattice model of secure information flow. A lattice is an organized set of labels with defined relationships: some destinations are allowed to receive information from certain labels, while others are not. The labels need not be only a single ladder from public to secret. Two departments can hold information that neither is automatically allowed to share with the other.

A physical analogy is a mailroom that reads security labels on packages. Staff may move around the building, but a confidential package can leave only through an authorized route to an authorized recipient. In software, the package is information, the source is the file or service that supplied it, and the sink is a destination where it is used or released. An email body, a browser request, a file upload, and a final answer can all be sinks.

Labels must follow derived information. If the assistant extracts a salary from a confidential spreadsheet, the extracted number does not become public because it is shorter. Combining data generally requires preserving the relevant restrictions from all contributing sources. A system that checks only exact copied strings will miss paraphrases, summaries, and encodings. That is why provenance and controlled transformations matter as much as the initial read permission.

Sometimes release is legitimate. A finance team may publish an approved aggregate without exposing individual salaries. The policy can define a trusted declassification step that permits this specific release after required checks. The assistant should not grant itself that exception by calling a summary harmless. A sound design identifies who may authorize release, which transformation is approved, and what information can remain in the output. This is a policy decision with an execution check.

Information-flow control complements scoped credentials. A credential might allow sending email only from a service account or reading one folder. Flow control further restricts which folder contents may appear in which messages. Sandboxing limits processes, files, and networks. None replaces the others: a perfectly isolated process can still misuse an authorized email connection if the data-transfer policy is missing.

Today’s Environment Steering paper provides an AI-specific prototype. Its authors represent environment state as relations and apply task-specific constraints at watched tool-input and final-response destinations. A rejected operation can return feedback that helps the agent try a compliant alternative. The mechanism aims to preserve legitimate task completion while preventing harmful transfers, rather than simply disabling every tool that could transmit data.

The authors’ full paper describes the implementation and benchmark boundary in detail. The prototype also illustrates the limits. Its policies use manually curated examples and model-generated task rules; they are not guaranteed interpretations of every user’s intent. Its benchmark-visible sinks cover only part of a general computer’s behavior. Enforcement is only as complete as the paths it watches and the provenance it preserves. A file, network request, delegated agent, or logging service outside that boundary can become an overlooked route.

A stronger theoretical goal is noninterference: changing secret input should not alter what an unauthorized observer can learn through public outputs. Achieving that can require addressing indirect signals too. A reply’s timing, length, or choice of action may reveal something even when no secret text is copied. Practical agent systems often enforce narrower rules, so they should state that boundary explicitly instead of claiming complete secrecy.

For a deployed assistant, the design work is to identify sources, labels, transformations, permitted recipients, and every relevant sink. Enforce the rule in trusted runtime code, keep authority for exceptions outside untrusted content, and log rejected transfers as well as successful ones. Information-flow control cannot make the assistant’s reasoning correct. It can prevent a reasoning error from becoming an unauthorized disclosure along the paths the system actually controls.

Ground Truth. (2026, September 30). Information-flow control: deciding where an agent may send what it reads. Ground Truth. https://groundtruth.day/learn/information-flow-control-for-ai-agents.html

@misc{groundtruth:information-flow-control-for-ai-agents,
  title  = {Information-flow control: deciding where an agent may send what it reads},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {sep},
  url    = {https://groundtruth.day/learn/information-flow-control-for-ai-agents.html}
}

Topics: cybersecurity · ai-security · information-flow · agents · provenance