> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/by-ai-vendor/anthropic/claude-tag.md).

# Claude Tag

Security guidance for Claude Tag, including identity, deployment scope, data handling, integrations, user access, monitoring, and evidence collection.

{% hint style="warning" %}
**In short:** Claude Tag is Anthropic's Slack-native shared agent for Team and Enterprise. In channels it acts under organization-provisioned service accounts, not the identity of the person who mentioned it. Everyone in an authorized channel can invoke the same shared access, so channel membership becomes a security boundary.
{% endhint %}

## What is Claude Tag?

Claude Tag lets Slack users mention Claude in channels or direct messages, run one-time and scheduled tasks, use channel memory, and connect the agent to repositories, data systems, and other services.

Channel and direct-message behavior differ:

* In a channel, Claude acts under its own agent identity and shared service accounts.
* In a direct message, the session uses the individual's Claude account and personal connectors. Actions are attributed to that user.

This distinction should be part of rollout training and incident response.

## Where Claude Tag runs and what it can access

Each Slack thread runs in an Anthropic-hosted sandbox. The sandbox holds no long-lived credentials. Outbound HTTP or HTTPS requests pass through Anthropic's Agent Proxy, which checks the destination and injects a credential only at the boundary when a configured rule matches.

Access is assembled from:

* Slack channels and channel membership.
* Access bundles attached to a channel scope.
* Dedicated service accounts and the Claude GitHub App.
* Allowed websites and bundle domains.
* The network-access setting of the Anthropic environment.
* The user's personal connectors for direct messages only.

The default network posture blocks destinations that match no allow layer. New environments can still include Anthropic's Trusted set of package registries and developer hosts, so “default deny” does not necessarily mean no outbound access.

## Claude Tag security boundary

Anyone in a channel covered by an Access bundle can ask Claude to use that bundle's credentials. The connected service account therefore needs permissions safe for the least-trusted member of every covered channel.

Claude Tag retains channel memory and session transcripts and is not available to organizations with Zero Data Retention enabled. Published artifacts remain available to members who can access the source Slack channel.

Scheduled routines can run without a fresh human prompt. Treat them as persistent automation with their own owner, scope, credential, and review requirements.

## How to configure Claude Tag securely

### Restrict who and where

* Enable the restriction that limits invocation to approved Claude organization members. On Enterprise, grant the Claude Tag capability only through approved roles.
* Review Slack workspace membership, guests, shared channels, and channel privacy before attaching access.
* Scope Access bundles to the smallest set of channels.
* Disable direct messages organization-wide if personal connectors and user-attributed actions are outside policy.
* Do not use a broad public channel for access to sensitive systems.

### Provision agent identity safely

* Create a dedicated service account for each connected service.
* Never connect an administrator's personal account.
* Grant the service account only the minimum read or write permissions required.
* Restrict credentials to named hosts, path prefixes, and read-only methods where possible.
* Keep production write access in a separate bundle and channel from general read access.
* Use the connected system's audit logs to monitor actions attributed to the agent account.

### Control network and automation

* Set the execution environment to the narrowest network level that supports the workflow.
* Review Anthropic's Trusted default and remove destinations that are not required.
* Avoid the allow-all wildcard.
* Review every scheduled or recurring task, owner, trigger, destination, and credential.
* Use the Claude Tag Audit view to inspect scheduled and one-time tasks and Agent Identity network calls.
* Retain Slack and connected-system logs according to the organization's investigation requirements.

## Claude Tag security review checklist

* The Slack app was approved by the Slack administrator and installed in the intended workspace.
* Invocation is restricted to managed users where required.
* Channel membership is reviewed before any Access bundle is attached.
* Each connection uses a dedicated, least-privilege service account.
* DM behavior and personal connectors match policy.
* Network access is narrower than the default Trusted environment where possible.
* Scheduled tasks have owners, expiration dates, and periodic reviews.
* The organization accepts transcript and memory retention and the lack of ZDR.
* Audit records from Claude Tag, Slack, and connected services can be correlated.

## Claude Tag provider documentation

* [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag)
* [Security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data)
* [How agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity)
* [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access)
* [Audit Claude Tag activity](https://claude.com/docs/claude-tag/admins/audit)
* [Set up routines](https://claude.com/docs/claude-tag/users/proactivity)

*Last reviewed: August 18, 2026*

## Applicable handbook articles

These handbook articles cover the controls most directly relevant to this product.

| Handbook area                            | Applicable articles                                                                                                                                                                                                                                                                                                       | Why they apply                                                                                                                                                   |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. Identity & access                     | <p>1.2 RBAC across AI platforms<br>1.3 Tenant restrictions: blocking personal accounts<br>1.5 Agent and non-human identity<br>1.6 API keys and service accounts governance<br>1.7 Human-in-the-loop and approval policies</p>                                                                                             | Channel work uses shared agent identities and service accounts, while direct messages use individual identities and connectors.                                  |
| 2. Connectors, extensions & supply chain | <p>2.1 Connectors and apps: the integration backbone<br>2.3 MCP gateways and allowlisting<br>2.4 Analyzing skills for risk<br>2.5 Plugins and marketplaces<br>2.7 The supply-chain review workflow<br>2.9 SaaS agent-building supply-chain</p>                                                                            | Access bundles, Agent Proxy rules, skills, plugins, instructions, repositories, and services must be reviewed as one release.                                    |
| 3. Runtime, sandboxing & autonomy        | <p>3.1 Sandbox and isolation models<br>3.2 Approval policies and least-privilege autonomy<br>3.3 Network egress control<br>3.4 Internet access and browser automation<br>3.6 Scheduled and background tasks<br>3.8 File and filesystem access controls<br>3.9 Central hosted-agent runtime hardening</p>                  | Each thread runs in a hosted sandbox, egress crosses Agent Proxy, and scheduled routines can act without a fresh prompt.                                         |
| 4. Data protection                       | <p>4.1 DLP for GenAI<br>4.2 Data classification for AI prompts and outputs<br>4.4 Retention and Zero Data Retention<br>4.5 Training opt-out and data usage<br>4.6 Cross-app data flow and live artifacts<br>4.7 Secrets and credential hygiene in prompts and tools</p>                                                   | Slack scope, memory, transcripts, service credentials, repositories, outbound services, and published artifacts form the data boundary.                          |
| 5. Threats & adversarial testing         | <p>5.1 Prompt injection: the connective risk<br>5.2 Data exfiltration via tools and connectors<br>5.3 Supply chain attacks and notable CVEs<br>5.4 Agent-specific threats: tool poisoning and confused deputy<br>5.5 Red-teaming AI systems<br>5.6 Incident response for AI systems<br>5.7 Threat modeling AI systems</p> | Shared channel authority, extensions, and unattended routines expose the full injection, exfiltration, supply-chain, agent, testing, response, and modeling set. |
| 6. Observability, audit & evidence       | <p>6.1 The audit gap: what you can and can't see<br>6.2 OpenTelemetry for AI runtime<br>6.3 Compliance APIs by platform<br>6.4 Analytics and usage APIs<br>6.5 Routing AI telemetry to your SIEM<br>6.6 Evidence by surface and investigation paths<br>6.7 Continuous review cadence</p>                                  | Evidence is split across Slack, Tag's audit view and network export, service-account logs, connected systems, and usage controls.                                |
| 7. Rollout & operations                  | <p>7.1 Roll out by risk: the phased plan<br>7.2 Pilot design and success metrics<br>7.3 The security team checklist<br>7.4 The vendor-neutral control matrix</p>                                                                                                                                                          | Shared agents, access bundles, routines, and Slack deployment need separate pilot gates, evidence checks, and baseline controls.                                 |

## Applicable Harmonic guide

* [Securing Claude Products](https://www.harmonic.security/resources/guide-securing-claude-products)

## Related handbook guidance

* [Anthropic](/by-ai-vendor/anthropic.md)
* [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity.md)
* [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies.md)
* [4.6 Cross-app data flow and live artifacts](/handbook/4.-data-protection-and-residency/4.6-cross-app-data-flow-and-live-artifacts.md)
* [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/by-ai-vendor/anthropic/claude-tag.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.