Team Bots: A shared bot needs explicit credential ownership

Team Bots bring files, skills, applications and credentials into a shared agent role. The retrospective question is how sharing that role changes the need to identify whose authority a particular tool action actually uses.

The dated path

• 2026-07-23: Workflows in Grok Build.

• 2026-08-11: Introducing Grok Bot.

• 2026-09-28: Team Bots add shared agent expertise.

Sharing the worker does not define the principal

A team member can interact with the same bot while using a personal connection, a team-managed integration or another explicitly provided credential. Those arrangements have different ownership and permission boundaries. Our interpretation is that collaboration makes this distinction operationally important. A useful execution record should identify the authority relevant to the action without exposing the secret itself. Otherwise a shared bot name can hide whether an operation depended on an individual’s account or a resource intended for the whole team.

Revocation is a practical test of ownership

When a person leaves a workflow or a connection is removed, the system needs to know which capabilities should stop and which shared functions remain. A vague credential model makes this difficult to reason about. This is an architectural implication, not a statement about a flaw in Team Bots. The source announcement establishes the combination of shared role and connected tools; the retrospective asks how a deployment can preserve the ownership information required to change access deliberately rather than through accidental side effects.

A counterfactual with the same requested action

Ask the bot to perform an equivalent permitted operation under two explicitly different connection identities. Check whether the result record makes the distinction clear and whether removing one connection affects only the scope it was intended to support. The evaluation concerns authority attribution, not the language quality of the bot’s response. It should also include a task for which no suitable authority is available, so the system cannot treat a shared interface as implicit permission to use any credential it happens to possess.

What infrastructure can keep inspectable

Task identity, connection identity, permission scope and result attribution can remain linked without copying secrets into routine logs. The earlier individual agent and workflow products provide context for the later collaboration feature, while not establishing universal permission behavior. The September milestone shows why agent infrastructure needs an account of who authorizes work as well as what work runs. A clear ownership model makes audits and changes easier, and prevents a convenient shared assistant from becoming an ambiguous source of authority across unrelated tools and users.

Technical background

Related engineering context: Authority attribution; Execution boundaries.