An Agent May Be Authorized to Send Email—and Still Forbidden to Send What It Knows

An agent can be fully authorized to send an email and still be forbidden to send the material in its working context. This distinction is easy to miss because most agent controls begin with a sensible question: may this identity invoke this tool? But an authorized action is not necessarily an authorized disclosure.

A research agent may retrieve an internal pricing memo, read an untrusted web page, consult customer records and draft a partner update in one execution path. Its email capability may be legitimate. Its recipient may be legitimate. Yet the draft may contain confidential pricing, one tenant’s data addressed to another, or instructions planted in retrieved content that steer the agent towards exfiltration. The permission to call email has not answered the question that matters at the boundary: may this payload travel to this destination?

Autonomous organizations need both answers. Identity and authorization govern whether an actor may perform an action. Runtime information-flow control governs what knowledge may move through that action. Prompt guardrails can still set behavioral expectations, but they are not an enforcement boundary for data that has already entered an agent’s context.

Access control is not flow control

NIST draws the distinction directly. SP 800-171 Rev. 3 separates access control—who may access information—from information-flow control—where information may transit. NIST SP 800-53’s AC-4 similarly calls for enforcement of approved authorizations that control information flows within and between systems, including metadata-based enforcement and policy filters.

For an agent runtime, this means a tool grant is necessary but incomplete. A grant may say that the procurement agent can use the mail service. A flow policy must additionally determine whether the particular message, attachments and recipient are compatible. The same principle applies to API requests, ticket comments, database writes, browser submissions, inter-agent messages, memory writes and logs. Every one is a sink: a point at which knowledge crosses into a domain with its own rules.

“Authorization answers: “May this actor do this?” Information-flow control answers: “May this data reach there through this action?”

That is not a semantic refinement. It changes where enforcement happens. A runtime must evaluate a proposed tool payload at the sink, even after it has accepted the tool invocation itself. This is distinct from commit-time authorization: the runtime should authorize the action at the moment it becomes consequential, then also assess the lineage and destination compatibility of the data being committed.

Treat workflow artifacts as labeled material

A practical runtime model begins by attaching labels to artifacts, not merely to files in a source repository. A retrieved passage, a model context bundle, a generated answer, a tool argument, a memory record and a log event are all artifacts. Each needs a confidentiality label and an integrity label appropriate to the organization’s policy.

Confidentiality expresses disclosure restrictions: for example, tenant-bound, internal, restricted to a named business function, or approved for external release. Integrity expresses how much the organization should trust the material: for example, system-of-record, internally reviewed, untrusted retrieval, or externally supplied instruction. Labels do not classify data by magic. They must originate in source systems, ingestion controls, policy or authorized classifiers—and those assignments can be wrong. The runtime’s job is to preserve and enforce the policy consequences of the labels it receives.

The established information-flow literature provides a useful rule for transformations. Cornell’s Jif system represents confidentiality and integrity policies as labels, with ordering and join operations that combine the applicable restrictions of multiple inputs. Adapted to an agent workflow, combining a customer record, an internal strategy note and untrusted retrieved text should conservatively produce an artifact carrying the restrictions that apply across those inputs.

• A private customer record stays private when quoted, summarized or placed in model context.
• A response built from two tenants’ data is not silently eligible for either tenant’s channel.
• A tool argument derived from untrusted retrieval retains an integrity signal, so it can face stronger validation before execution.
• A log containing sensitive context is treated as a governed destination, not as harmless operational exhaust.

Model generation requires a conservative default

This model becomes especially important at the LLM boundary. An LLM may produce an answer influenced by many parts of a prompt, retrieved documents and its own transformation process. A governed runtime generally cannot establish, token by token, which input influenced which output phrase. It should not pretend otherwise.

The defensible default is conservative inheritance: generated output receives the combined restrictions of all context supplied to that generation. If restricted material is present in the context, the resulting draft is restricted until a separate governed process permits otherwise. This can feel blunt. It is also preferable to a system that marks a polished answer as public simply because it cannot prove where each sentence came from.

The operating consequence is architectural: context minimization becomes a flow-control measure, not only a cost and relevance measure. Do not place sensitive material in a generation context unless the intended output path can handle its restrictions. Isolate tenant context and memory domains. Keep untrusted retrieved instructions separate from trusted task instructions. Validate structured arguments before tools execute. OWASP’s agent security guidance identifies leakage through tool calls, citations, logs and final outputs, while its prompt-injection guidance documents indirect injection through pages, documents, email and other tool-visible content. Labels will not prevent such an injection. They can limit the destinations available after compromised processing.

Declassification must be an operation, not a model mood

Organizations do need to lower restrictions. A customer-facing status update may be derived from an internal incident record. A partner report may contain an approved aggregate from restricted data. But “the model summarized it” is not a declassification decision.

Jif treats declassification as a deliberate weakening of flow restrictions and checks that the code doing it has the required authority. An agent runtime can take the same architectural position without claiming that Jif specifies an AI-agent design. Redaction, aggregation, release review and disclosure should be explicit operations performed by an authorized component. The operation needs a stated purpose, a policy version, evidence of the control applied and an auditable result.

A model may assist such a process, but it is not the authority merely by producing fluent text. The declassifier should use deterministic controls where possible or independently validated controls where judgment is necessary. If the required evidence is absent, the restriction remains. This is what makes “safe summarization” a governed release path rather than an incidental behavior inside an opaque generation step.

Evaluate every sink against a destination contract

The enforcement point is a destination contract. Before a sink accepts material, the runtime evaluates the artifact’s effective label against what that sink may receive. An external email recipient, a named customer tenant, an internal finance system, a shared agent memory store and an observability platform should not be treated as the same destination simply because all are reachable by API.

A proposed AES runtime contract would assess at least the effective data label, destination, recipient or tenant, declared purpose, initiating principal, workflow policy version and any authorized declassification evidence. This exact schema is an architectural inference from information-flow models and agent-security guidance, not a standard-defined agent contract. Its value is that a denial becomes concrete: not “the agent behaved suspiciously,” but “restricted tenant material cannot enter this cross-tenant ticket under policy version X without approved release evidence.”

1. Authorize the actor and the tool action.
2. Propagate confidentiality and integrity labels through retrieval, context assembly, generation, memory and transformations.
3. At each sink, compare the effective label with the destination contract.
4. Require an explicit, authorized and evidenced declassification operation before lowering a restriction.
5. Record the decision and its policy context alongside the consequential event.

The boundary that makes autonomy governable

This is not generic data-loss prevention applied after the fact. The difficult property of agent systems is that data is continuously transformed: placed into context, synthesized into an answer, retained in memory, passed to another agent and formatted as a tool payload. The control must follow those derived artifacts end to end.

Nor does information-flow control replace identity, least-privilege tools, authorization checks or prompt-injection defenses. It gives them a missing companion. An agent may be the right identity, use an approved tool and follow a valid workflow, yet still propose a payload that must not cross a boundary.

For an autonomous organization, that is the essential design test. Do not ask only whether the agent was allowed to send the email. Ask whether the organization can prove why this particular knowledge was allowed to travel to this particular recipient, for this purpose, under this policy—and what authorized process changed its restrictions if it did. Until the runtime can answer that, outbound autonomy remains broader than governance.

Sources

• NIST SP 800-171 Rev. 3, information-flow control and security labels.
• NIST SP 800-53 Rev. 5.1, AC-4 Information Flow Enforcement.
• Cornell Jif documentation, decentralized labels, joins and declassification.
• OWASP AI Agent Security Cheat Sheet.
• OWASP LLM Prompt Injection Prevention Cheat Sheet.