An identity is a function of where the agent is running.
Claude Tag's own docs open with one sentence: "Claude Tag's identity depends on where you message it." In a Slack channel, it acts under its own provisioned service accounts -- the Claude app, the Claude GitHub App, a service account in every connected tool. In a direct message, there's no channel to scope an identity to, so the session runs under the individual's own claude.ai account instead. Same underlying engine, two different identities, chosen entirely by surface.
Its own service accounts in a channel; you, in a DM. This site's attribution_mode column is exactly that axis, typed instead of implied by context.
The channel's Access bundles, or your personal connectors. Every identity row here records its real access_scope -- what it can actually reach, not what it's assumed to reach.
The agent's accounts in each tool's audit log, billed to the organization -- or your name, billed to your seat. Every row records both acts_as and billing_owner as separate, checkable facts.
The comparison table, verbatim
Claude Tag's own docs give this exact table for channel vs. DM sessions:
| In a channel | In a DM | |
|---|---|---|
| Acts as | Its own service accounts | You |
| Access | The channel's Access bundles | Your personal connectors |
| Attribution | The agent's accounts, in each tool's audit log | Your name |
| Billing | The organization | Your seat |
-- claude-tag/concepts/agent-identity. See the full citation trail for how every column on this site's identities table maps back to this exact table.
The dogfooding angle
Rather than invent a generic "agent identity" demo, this site catalogs this repo's own real identity boundaries. CLAUDE.md's naming ontology -- {device_surface}__{client_surface}__{coworker_enum} -- already draws the same line claude-tag draws between channel and DM: macos__desktop_cowork__engineering_coworker (Claude Desktop Cowork running on the operator's own Mac, npx/binary MCPs, personal and machine-scoped -- the DM shape) versus cloud__docker_mcp__engineering_coworker (Claude cloud inference through a fixed, provisioned Docker MCP Toolkit catalog of 17 servers, same capability no matter who invokes it -- the channel shape). The repo's own rule states it plainly: "code written for cloud__* surface must use mcp__MCP_DOCKER__* tools only. Code for macos__* surface can use npx/binary MCPs on the Mac." That's a real, load-bearing identity/access boundary already enforced in this codebase, not a hypothetical.
Two more real boundaries round out the seed data: the engineering-coworker Rust MCP server, which executes cargo/wrangler/git/D1 operations on the developer's Mac on Claude's behalf without ever handing Claude the raw credential -- the same shape as claude-tag's own Agent Proxy, which "attaches a credential... the model and the sandbox itself are not given the key" -- and the shared Cloudflare account (e6294e3ea89f8207af387d459824aaae) under which every subagent*.com deploy, D1 write, and zone route is attributed, exactly the way claude-tag attributes channel actions to its provisioned service accounts rather than to whichever person asked.
Live board
Real identity boundaries, read straight from this Worker's own D1 database -- not a mockup. See the live board →
Directives: the "custom instructions" layer, generalized
Claude Tag's own docs draw a second, separate line that agent-identity.md deliberately leaves for a related page: "How Claude behaves in channels (its standing instructions, plugins, and channel memory) is configured separately from its identity." That's custom instructions -- an Owner-authored standing-instruction layer, scoped and inherited the same way Access bundles are, but a genuinely distinct primitive from identity itself. This site now catalogs both. This repo's own CLAUDE.md is exactly that layer: an Owner-authored (in this case, the repo maintainer-authored) instruction set every session touching this repo inherits, some rules repo-wide, some scoped to a single surface -- the same "narrower scope adds, doesn't replace" inheritance attach-to-scope.md documents for real Slack scopes. See the live directives board →
Security and data handling
A third real primitive from the same doc set: where credentials are stored, what leaves the sandbox, and what runs unattended -- the sandbox-isolation, credential-storage, and default-deny-egress model that makes the Agent Proxy pattern this site already dogfoods actually safe to rely on.
Access bundles: the credential/instruction unit everything else assumes
Every primitive above quietly depends on one concept it never fully defines: agent-identity.md's "Access" row just says "the channel's Access bundles"; attach-to-scope.md's entire inheritance model is about which bundles are attached where; security-and-data.md's credential-storage section describes what a bundle's Credentials tab configures. Access bundles is that concept, made explicit and typed. This repo's own profiles/claude_desktop_chat.json, claude_desktop_cowork.json, and claude_desktop_code.json are three real, already-shipped Access bundles in miniature -- named sets of MCP-server credentials, each scoped to one Claude Desktop tab -- and the Docker MCP Toolkit's 17-server catalog is a fourth, larger one serving the entire cloud__* surface. See the live board →
Next step, noted not built
A future pass could register a subagentcontracts.com contract -- something like "identity + directive + access-bundle registry stays accurate," done_kind: objective_check -- so this catalog is tracked the same way subagentcowork.com's drift-check is tracked. Not wired up in this build pass; this paragraph is the documented next step, not a live integration.