Your agent can read the file. Should it forward the contents?

Your assistant can read the internal job notes. A customer asks for an update. The assistant sends a helpful summary, including a detail that was never meant to leave the team.

The answer can be accurate and still be the wrong message.

Permission to retrieve information does not settle who should receive it, or why.

Completion and appropriate disclosure are different tests

The authors of AgentCIScope, submitted October 13, study whether agents preserve context-specific disclosure constraints while completing tasks across applications. Their benchmark uses executable tasks built from public and synthetic privacy cases. The authors report that strong completion capability does not guarantee appropriate information flow.

This is a research preprint and a particular evaluation setup. Its results do not establish a failure rate for your assistant, your staff, or your customer workflow. The useful question is narrower: are you checking the destination of the information as carefully as you check the answer?

Give the outgoing message its own boundary

Imagine a hypothetical service company with internal job notes and a customer-facing status update. Both concern the same job, but they serve different purposes.

The internal notes might include scheduling discussion, staff observations, and tentative explanations. The customer update needs the confirmed status, the agreed next step, and whatever other details the business has authorized for that recipient.

A request to “send an update” should not turn the whole retrieved file into eligible message content.

Before drafting, identify four things:

• The verified recipient and channel.
• The purpose of this particular message.
• The fields approved for that purpose.
• The information that must stay internal or needs separate approval.

This is an operating rule, not a legal conclusion. Define it with the people responsible for the workflow and the access rules already in place.

Retrieve a smaller answer surface

Where practical, give the sending step a structured customer-update record rather than an unrestricted internal transcript. Include only the fields the task needs, with references back to their sources for authorized review.

That does not remove every risk. A field could be mislabeled, a recipient could be wrong, or the upstream record could already contain inappropriate information. It does make the intended boundary easier to inspect and test.

Separate the draft from the send. Check the recipient identity and allowed content again at the point where the message would leave the system. A good draft in the wrong conversation is still a disclosure failure.

If the allowed content is unclear, preserve the draft and ask the responsible person a specific question about the missing authority. Do not make the customer wait while the agent silently invents a policy.

Test with details that should never travel

Use synthetic records, never actual sensitive customer material. Add a clearly marked internal-only detail alongside a legitimate status update. Write down which facts may appear in the outgoing message and which must be excluded.

Run several cases: the normal update, an ambiguous recipient, a request to forward the full notes, a changed channel, and a source document containing instructions to disclose extra information.

Inspect the complete outgoing draft, including attachments, quoted history, and link permissions. The body can be clean while an attached document exposes everything the draft omitted.

The exercise succeeds when permitted updates remain useful and excluded details stay out. Count unnecessary refusals as well as unwanted disclosures. A system that cannot send a routine approved status update has not solved the operating problem either.

Make the rule reusable

Start with one recurring message your team already sends. Define its permitted information once, test the edge cases, and make the sending step accountable for that boundary.

For the broader action model, read Your agent needs three permissions: read, decide, and act. This adds a more specific question at the exit: which information is allowed to cross to this recipient for this purpose?

Source and scope

AgentCIScope: Grounded Contextual Integrity Evaluation for LLM Agents, submitted October 13, 2026. Research claims are attributed to the authors and their benchmark. The customer-update scenario and synthetic tests are illustrative recommendations, not legal guidance or observed Xovion incidents.