Your AI Coworker Is in the Group Chat. Who Can See the Work?

A Shared AI Coworker Changes Who Is in the Room

On November 4, Red Hat published a discussion of what it takes to trust AI coworkers in enterprise settings. The conversation moves beyond sandboxing to a quieter question raised by centralized, multi-user systems: who may speak to the same AI coworker, and who may receive its answer? A team that gets this wrong can turn a useful shared conversation into an accidental disclosure channel.

Picture an operations Teammate in a company group chat. The sales lead asks it to prepare the weekly renewal list. It retrieves account notes, including a confidential concession discussed privately with the owner. The account manager then asks whether a particular customer needs a call. If the Teammate pastes the full renewal list into the group, everyone sees the concession. If it silently treats the account manager's question as permission to update the CRM, it crosses a second boundary. Both failures are possible even when every person in the group is a legitimate employee.

A shared AI coworker conversation is not simply a private chat with more names at the top. It combines a room, a set of participants, a history, connected records, and potential authority to act. Each can have a different access rule. The operational goal is to make collaboration possible without treating presence in the room as universal permission.

Red Hat's discussion is an architecture signal, not proof that any particular product automatically resolves these choices. Its emphasis on multi-user access makes the distinction timely for smaller teams too. A five-person business can have the same permission problem as a large company; it just has fewer people to discover the mistake.

Separate the Four Permissions a Group Chat Collapses

When someone says “share the Teammate with the team,” ask what share means. The answer should not be one checkbox. Four permissions matter, and combining them creates avoidable ambiguity.

Who can start or join a conversation?

Conversation entry determines who can issue a request. A general team channel may be appropriate for asking for a public project status, but not for initiating a payroll correction. A new channel member may be allowed to ask the coworker for help without gaining access to earlier sensitive work. Membership can change during a project; a conversation's authorization cannot be assumed to remain valid forever because the room name stayed the same.

This is different from configuring the Teammate. Someone who can ask for a summary should not automatically be able to change its instructions, connections, or audience. Microsoft's Copilot Studio sharing documentation explicitly distinguishes permission to chat from collaborative authoring. That product-specific setting illustrates a general operating principle: using a role and administering that role are separate powers.

Who can read the history and output?

The next boundary is visibility. A person may have permission to join the channel today but not to read a confidential answer generated last week for finance. Equally, a Teammate's internal working notes may include more than the final answer should reveal. A decision to let someone initiate a new request does not settle whether they should see a transcript, attachments, retrieved documents, or a summary of past private work.

A group response is also an outbound data destination. “Send it in the team channel” must be evaluated like “email it to the team”: which team, what information, and who can join later? The reply may be copied, searched, retained, and forwarded independently of the original source system. The same concern applies to notifications and quoted excerpts, not just a full transcript.

Which records may be retrieved for this request?

The source connection is a third boundary. A shared Teammate may be connected to a CRM, a document store, and a finance system, but an authorized participant in a group conversation does not acquire the sum of every connected permission. The retrieval should be limited to records necessary for the task and to information the requester or intended audience may receive.

Do not rely on the Teammate to hide a forbidden fact after reading it. Restrict source queries, scope the connection where possible, and apply an output check before sending to a group. Where the connector operates with a shared owner credential, document that limitation and avoid putting sensitive cross-role data behind a broad chat interface. Microsoft's sharing-controls guidance warns that a connection configured with the maker's credentials can let other users perform operations with the maker's permissions. That warning is about a specific product configuration, but the underlying risk is common: chat membership and downstream API authority may diverge.

Who can authorize an action?

Finally, the ability to ask a question is not permission to modify a record, contact a customer, or send money. A shared conversation can collect evidence and propose next steps while leaving the consequential action to a named owner. If approval is needed, capture exactly which operation, record, destination, and expiry were approved. A reaction emoji from someone in the room is not a substitute for an approval mechanism when the decision is consequential.

The four boundaries are independent. A teammate may be able to read a sanitized weekly summary in a group while having no access to the underlying customer notes and no right to update the CRM. The finance owner may see a restricted working transcript and approve a correction in a private decision path. Neither requires a second, entirely separate AI coworker if the platform can enforce those separations; if it cannot, use separate roles or channels instead of pretending the distinction exists.

Design the Conversation Around Its Audience, Not Its Convenience

A shared room feels efficient because it removes duplicate requests. The wrong optimization is to publish every retrieved detail to avoid repeating work. The better optimization is a common status with links or scoped follow-ups for information that belongs elsewhere.

Consider a seven-person service business preparing its Monday operations review. Its operations Teammate can collect task status from approved systems and post a team-level list of projects at risk, owners, and dates. When a project is at risk because a customer disputed an invoice, the public status can say “billing exception awaiting finance review” without exposing the invoice amount, payment history, or private negotiation. The finance owner can inspect those details in a separate restricted context.

Bad: Anyone in the general channel asks, “What happened with the renewal?” The Teammate pastes the entire CRM note and a previous private conversation into the channel, then marks the deal delayed because one participant suggested it. A valid login and a helpful answer hide two failures: oversharing and an unapproved write.

Good: The Teammate recognizes that the group is approved for project status, not the underlying commercial terms. It posts a short status and the named owner. It offers the account owner a private, source-linked detail packet; it treats a request to change the CRM stage as a proposed action requiring the account owner's explicit decision. The group gets enough to coordinate; the owner gets enough to decide.

This is a seam-design problem. The human decision belongs where audience and authority change, not at every routine lookup. The Teammate can prepare, summarize, and route work without appointing everyone in the room as a decision-maker. It can also preserve a task reference so the restricted follow-up and the group-level status stay aligned without copying confidential data across contexts.

Shared memory is not shared permission

Persistent AI coworkers remember work across sessions. That continuity helps a team avoid repeating context, but memory can make a group answer more revealing than its source documents. A summary of a finance meeting might store the reason for a price exception. Later, a group request for “everything we know about this deal” could surface the summary even if the requester cannot read the original finance notes.

The safe default is to classify remembered material by audience and purpose when it is stored, and recheck that boundary when it is retrieved. A public status can be derived from confidential evidence, but it should be intentionally written for that audience. See the related guide to shared AI coworker memory boundaries for the separate question of who may learn from a common memory store. Here the point is narrower: a participant's access to a live room does not grant retrospective access to every fact the coworker has learned.

The same principle applies to a person leaving the team. Removing them from a channel should revoke future participation and access to retained transcripts where the system permits it. It cannot revoke copies they already received. That is why the right design minimizes sensitive material in broadly visible rooms in the first place.

Run a Seven-Step Shared-Conversation Access Test

You do not need a large security department to test whether a shared AI coworker respects these boundaries. Start with one real channel and one realistic customer or internal workflow; use synthetic records if the test might expose private information.

1. List the audiences, not just the people

Write down who can join the room, see current replies, search old messages, view attachments, inspect working notes, and receive notifications. Include administrators and any channel history visible to new members. Do not assume a private channel stays private when membership and retention policies change.

2. Define what belongs in the common response

For each recurring request, specify the approved group-level output: project status, owner, next date, and perhaps a link to the source. Mark personal, financial, contractual, or customer-sensitive details for a restricted path. An explicit response template makes an accidental full-record paste easier to detect.

3. Map the Teammate's connected identity

Record whether each connector uses the requester's permissions, a role-scoped service identity, or a shared owner's credentials. If the connected system cannot distinguish users, do not claim per-user enforcement. Narrow the connector and require a review boundary where the system cannot apply the desired rule.

4. Keep a task reference across private and shared work

When the Teammate moves a question to a restricted context, carry a stable task ID and a sanitized status back to the group. Do not paste the private thread to demonstrate that work happened. The reference allows the owner to reconcile the outcome without making the restricted evidence public.

5. Test an authorized request and a tempting unauthorized one

Have a permitted participant ask for a team-level renewal status. Confirm the answer includes only approved fields. Then have that participant ask for a private concession or a CRM stage change. The correct result is a refusal, a restricted handoff, or a specific approval request—not an answer that leaks a detail and then apologizes.

6. Test a membership change and a stale transcript

Add a test user to the room after the initial work. Check what history, attachments, search results, summaries, and notifications become available. Remove a member and check what they can still access. Record platform limits honestly: an old exported message cannot be pulled back simply because a user was removed.

7. Review both the attempted action and the final recipient

Keep evidence of who requested the work, which identity retrieved the data, which audience received the response, and whether a write was attempted or confirmed. Review exceptions with a named human owner. Re-run the test when a connector, channel policy, memory rule, or participant role changes. A successful test today does not automatically cover tomorrow's configuration.

This test should end with two artifacts: a room-level sharing rule that people can understand and an enforcement map showing what the platform actually blocks. If the second is thinner than the first, reduce the role's access until they match. Trust architecture means a boundary survives a plausible mistake, not merely that a prompt asked the Teammate to be careful.

FAQ

Q: Should every employee get a separate AI coworker conversation?

A: Not necessarily. Shared rooms are useful for common status and coordinated work. Separate restricted contexts are necessary when the source material, audience, or action authority differs. A shared room should not become the default destination for every retrieved record.

Q: Does joining a group chat give someone permission to see earlier AI coworker work?

A: No. Whether a platform exposes history to new members varies, so check its actual retention and membership settings. Set the intended visibility rule explicitly and test it with a newly added account before using the room for sensitive work.

Q: Can one shared connection safely serve several departments?

A: Only if the connection and the application enforce the relevant scopes for every request. A shared owner credential may have more authority than an individual requester. If per-request enforcement is unavailable, split connections or roles and keep sensitive actions behind a separate review path.

Q: What is the difference between a shared answer and shared memory?

A: A shared answer is delivered to a defined audience now. Shared memory may be recalled later in a different context. Both need audience and purpose rules, but a safe response today does not guarantee a stored summary will remain safe to repeat tomorrow.

Q: Who should approve an action suggested in a shared room?

A: The named business owner for that operation, not whoever happens to be online. The approval should identify the record, intended change, destination, and time window. The coworker can prepare evidence and perform permitted follow-through after that decision.

Q: Is this only an enterprise security concern?

A: No. The number of employees does not determine whether a payroll fact, customer concession, or private note may be repeated in a group. Small teams often share more context informally, which makes explicit audience boundaries more important, not less.

If your team wants an AI coworker that can coordinate shared work without making every conversation a blanket grant of access, Associates AI Teammates provides persistent roles, connected Skills, and an operating layer for defined human decision boundaries. Explore the platform and choose a plan.