Agent identity, per Claude Tag's own docs
Everything on this site is a direct generalization of specific lines in Anthropic's Claude Tag documentation (mirrored verbatim at subagentcowork.com/claude-tag, source path docs/docs/claude.com/docs/claude-tag/concepts/agent-identity.md in this repo). This page is the citation trail.
1. Identity is a function of surface, not a fixed property
"Claude Tag's identity depends on where you message it."
-- claude-tag/concepts/agent-identity. The doc continues: in a Slack channel, Claude "acts with its own service accounts, rather than as a specific user," provisioned by an organization Owner so it "arrives with its own account in each system it works in: the Claude app in Slack, the Claude GitHub App on GitHub, and a service account in every other connected tool." In a direct message, "the provisioned identity does not apply... a DM session runs on the individual's own claude.ai account instead, with their personal connectors."
This site's identities.surface column is exactly that variable, made queryable: macos_desktop_cowork, cloud_docker_mcp, mac_binary_mediated, cloudflare_account, vault_keychain_postgres -- five real surfaces in this repo, not a hypothetical taxonomy.
2. The channel-vs-DM table, and what it generalizes to
| 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, "Direct message channels." Every row of that table becomes a typed column on identities: attribution_mode (service_account | personal_account) is the "Acts as" row, collapsed to a checkable enum instead of two rows of prose; access_scope, acts_as, and billing_owner carry the other three rows forward as free text, one per identity, instead of one fixed table for one product.
3. Agent Proxy: a credential attached at the boundary, never handed to the sandbox
"Agent Proxy attaches a credential. A matching credential comes from the credential store... Once saved, a credential is never displayed again; Agent Proxy retrieves it only at the moment of injection and attaches it to the request at the boundary, so the model and the sandbox itself are not given the key."
-- claude-tag/concepts/agent-identity, "Agent Proxy." This is the credential-mediation pattern identities.credential_source exists to record: not just "what identity is this," but "where does its real secret actually live, and who mediates access to it."
This repo's own engineering-coworker Rust MCP server (crates/engineering-coworker) is a direct parallel, cited explicitly here rather than left implicit: it exposes cargo_check, cargo_test, wrangler_deploy, d1_query, git_status, and git_commit_push as MCP tools, executing each one on the developer's real Mac using that Mac's own git/cargo/wrangler auth -- Claude calls the tool, but the binary holds the credential and mediates the boundary, the same shape as Agent Proxy attaching a credential "at the boundary" rather than inside the sandbox.
4. Vaults and credentials: register once, reference by ID
"Vaults and credentials are authentication primitives that let you register credentials for third-party services once and reference them by ID at session creation."
-- docs/docs/platform.claude.com/docs/en/managed-agents/vaults.md, "Authenticate with vaults." This repo's own subagentcoworkers.com agent-identity doc already dogfoods this pattern in its own words: "Where a role needs a real credential (a GitHub PAT, an MCP OAuth token), it's stored in a Vault -- macOS Keychain as the local secret source, Postgres as the durable audit layer -- never inline in a prompt or a config file. Rotating or archiving a credential is a vault operation, not a grep-and-replace." That Keychain-plus-Postgres pairing is seeded here as the vault_keychain_postgres surface: local secret source, durable off-machine audit trail, exactly mirroring the real Vaults API's own credential-lifecycle model (archive, rotate, webhook on vault_credential.refresh_failed).
5. The shared account is a service-account identity too
Not everything at the "channel" end of this spectrum comes from claude-tag directly -- but the shape is the same. Every subagent*.com Worker in this repo deploys under one Cloudflare account (e6294e3ea89f8207af387d459824aaae, held by Alex@jadecli.com). Every deploy, every D1 write, every zone route is attributed to that account, not to whichever session or operator triggered it -- precisely the same structural claim claude-tag makes about channel actions being "attributed to those accounts," "the same for everyone in the channel." Seeded here as id_cloudflare_account.
What this site adds
Claude Tag's identity model lives inside one product, scoped to one Slack workspace's channels and DMs. This site is the same model factored out into a small typed primitive -- identities in D1 -- populated with this repo's own real, already-load-bearing identity boundaries, so "identity depends on where you message it" stops being a documentation sentence about Slack and becomes a live, queryable catalog of every surface this actual codebase already runs under. See the live board.