Security and data handling

The agent's identity

The agent acts as its own mailbox, not as the person asking. Connected services act with the account an admin authorized for the group or organization. Anyone who can post to the group can ask it to use them, so use dedicated service accounts with only the access the group needs.

Credentials stay out of the sandbox

• Connector credentials (OAuth tokens and bearer tokens) are stored in Anthropic Vault: one vault per group, one per bundle, and one for the organization's shared connections. Anthropic attaches them to requests to the connector's server and refreshes OAuth tokens.
• Secrets for other APIs are Vault environment-variable credentials. The sandbox sees only a placeholder; Anthropic substitutes the real value on requests to the hosts you listed, and nowhere else.
• Neither can be read back from Cloud Tag's pages.
• The organization's API key, each mailbox's Google sign-in, each agent's GitHub sign-in, GitHub repository tokens and members' personal connector sign-ins are encrypted in Cloud Tag's database. Personal connector tokens never enter a session: Cloud Tag makes those calls itself, for the member whose message the agent is answering.

Where requests can go

The group's network mode limits what code and package installs in the sandbox can reach: Full (the default), Limited to an allowlist plus package managers, or None. Web search and web fetch run outside the sandbox, so only Full has them. Because Full is the default, a prompt-injected agent could send what it can read (the group's archive, its Drive files, its memory) to any website; choose Limited or None for groups where that matters. Connectors work in every mode.

Who the agent believes

Email headers can be forged, so Cloud Tag checks mail before it acts on it:

• Group mail counts only when Gmail's own Authentication-Results shows a passing DKIM signature from the group's domain that covers the message's List-Id. A message with two From, List-Id, List-Post or X-Original-From headers, or two verdicts claiming to be Gmail's, isn't believed at all.
• A direct copy (no List-Id) is credited to its From sender, never to an author it names in other headers.
• Only the group's members get the agent, as in a Slack channel: the people Google lists in the group, its admins, the organization's Owners and Admins, and anyone an admin allows. A post's author counts only if Gmail verified their domain (DMARC, or a DKIM signature from it) when the post reached the group.
• A copy sent straight to the agent without passing through the group is accepted only from a known member whose mail passes DMARC.
• Only verified mail makes someone a member of a group in Cloud Tag.
• Group mail that fails is ignored, and the last week of it is listed on the organization page.

Private email

Direct messages have separate history, files, configuration and memory per person and agent. Organization roles do not grant access to someone else's DM in Cloud Tag. DMs do not inherit group archives, shared notes, bundles or organization credentials.

A Workspace sender whose message has no Gmail authentication results must confirm that exact message using a signed, expiring link emailed to their own address. A GET only previews it; a POST confirms or declines. Quarantined content is encrypted and unavailable to the model, history tools and files until confirmed. The sender allowlist, rate limits and agent availability are checked before issuing the link and before acting on it. Reply-To and CC never determine where confirmation mail or DM replies go.

Instructions versus content

The agent's configuration is its system prompt and the instructions the organization, agent and group set. Everything else, such as emails, quoted text, attachments, web pages and tool results, is information, not instructions. It's told to confirm before consequential or irreversible actions with a connected service, and never to reveal credentials or move data where the group didn't ask.

Staying inside a group

• The agent's tools take the group from the conversation, never from what the model asks for. In a group's thread it can search and open only that group's messages and files.
• Replies go only to the group's address. Private notes (like !status answers) go only to the person who asked; budget warnings and join requests go only to admins.
• Google Drive is scoped per group: in a group's threads the agent opens only files the group itself could open: shared with its address, shared with its Workspace domain, or linked in its mail with link sharing that lets the group open them, even though its account can open more. A posted link alone never reaches a file shared only with another group.
• Group memory belongs to one group. Only shared notes cross groups, and only from groups whose admins allow it.

Who can see what

Shared Group web pages and direct file downloads require a current organization Owner/Admin role or a Group-admin grant. A past authenticated post is not an authoritative, revocable Group roster. This web boundary does not implement audience-aware restrictions on the agent's own Group context or tools.

Approvals and audit

Tool calls set to ask wait for a group admin on the web, who sees the call's arguments in full. A call whose arguments can't be shown in full, because something in them looks like a secret or they are too large, is declined rather than approved blind. A personal connector call that changes things waits instead for its owner, who sees every argument; see Personal connectors. Every reply's cost and outcome is recorded, and each group's activity log records its settings changes and commands; see Review what it has done.

Data

See Data lifecycle and deletion.

Administrative authority and shared notes

Activating a Group records who turned it on, without creating permanent independent admin access. Current organization roles authorize inherited access. Explicit Group-admin grants remain after an organization role ends and are listed on the organization page for separate revocation. Historical activation-derived owner rows no longer authorize access because earlier writes did not preserve reliable grant provenance; re-add an independent admin explicitly if needed.

Only a current organization Owner or Admin can approve a Group to update its agent's cross-Group shared notes. Old checked settings without that approval run read-only. Grant and revoke decisions retire existing sessions, and session authorization checks the current resource permissions before continuing. Already-running provider work retires asynchronously. This does not cleanse earlier shared-note content; organization administrators must review it. DMs remain separate and do not receive shared notes.