A team agent can obey every data permission and still disclose the answer to the wrong people. That is the security problem hiding inside the appealing idea of one shared assistant for a whole team. Once an agent can move information between systems and conversations, authorisation has two sides: what it may retrieve and where it may publish.
In the episode that prompted this essay, Nufar Gaspar describes a team agent as one agent used by many people, with shared knowledge, memory and configuration. The report also warns that an agent using a requester's connectors can surface information into a channel containing people who were not entitled to see it. Those are reported claims, not independent proof of any product's behaviour, but they identify a design problem worth testing.
Microsoft says its synced Copilot connectors respect source permissions so users access only content for which they have appropriate permissions. Google says Agent Search can use an identity provider to determine whether an end user may access documents returned in results. Google's documented data-source access control is a preview offering subject to change. These product controls address a crucial question: may this person retrieve this item? A team agent creates another question after retrieval: may this answer appear in this destination?
Imagine an account director who is entitled to read a confidential margin note in a customer record. She asks a shared sales agent for help while working in a channel that also includes an external adviser. The agent retrieves the note under her identity and posts a polished summary into the channel. Every retrieval check can succeed, yet the disclosure can still be wrong because the audience is broader than the identity behind the request. The route from authorised input to unauthorised output creates the failure.
This makes the conversation itself a security boundary. A shared channel, direct message, customer workspace and exported document are not interchangeable destinations, even when the same employee starts the task. The agent's effective authority should be limited by the requester's rights, the agent's credentials and the audience permitted to receive the result. Checking only the first two can turn legitimate access into illegitimate distribution.
Microsoft Copilot Studio documentation says administrators can use data policies to block publishing agents to specified channels. That capability does not prove destination-aware controls exist for every answer, audience or workflow. It does show that Microsoft places publishing channels inside Copilot Studio's governance model alongside authentication, knowledge sources and connectors. Google's documented control focuses on limiting which search results a user can view. The gap between those approaches is where release policy belongs.
The commercial consequence extends beyond confidentiality. If a shared pricing agent posts one customer's approved discount into another customer's workspace, the destination changes a legitimate fact into a negotiating problem. If an agent publishes an internal concession limit to a partner channel, authorised retrieval can weaken the company's position without any source permission failing. A single permission labelled “can use agent” is too crude for either case.
The safer design starts with an output contract. Before launch, classify destinations by audience rather than by application name. A private conversation may accept material authorised for the requester, while a team space should accept only material cleared for everyone who can see the response. A customer-facing space should require an explicit release rule rather than an inference from whoever typed the prompt. The agent can then answer there, move the response to a private path, redact sensitive material, request approval or refuse.
This prescription has hard limits. Destination controls can suppress useful answers when classification is too cautious, and their value depends on accurate information about who can see a space. They cannot stop an authorised recipient from copying an answer elsewhere. Nor can they repair poor source permissions or unreliable content. The practical goal is to expose uncertainty rather than let the agent silently guess where an answer belongs.
Membership changes make that standard harder. Suppose a channel that was internal yesterday includes a contractor tomorrow, while a copied response outlives the permissions used to create it. Logging only that “the agent” acted is inadequate for investigation. The useful record links the human requester, retrieved sources, destination, audience at the time and any approval. That record gives risk owners something concrete to test and managers something concrete to improve.
Ownership belongs with the business process, supported by security. Someone accountable for pricing must decide which pricing answers can be shared and where. Security can define enforceable controls, but it cannot decide whether a commercial exception is ready for a partner. The process owner should maintain rerunnable scenarios covering correct retrieval and correct release, including cases where channel membership changes.
This changes the buying question. Ask whether a platform evaluates the destination and current audience before answering, can redirect a sensitive response into a private path and records who received the output. Procurement should treat vague answers as a design gap rather than a promise to solve later. If enterprise suites make these controls consistent across chat, search and workflow surfaces, release policy could become a native requirement.
If controls remain fragmented, a cross-platform security layer will have a stronger commercial case. The first pilot should test what happens when the right requester asks in the wrong place. Shared AI earns trust when it knows more than the room but also knows what it must not say there.
sources
Prepared with assistance from a Useful Engine agent workflow. Factual and editorial checks are part of the publishing process.