Security and data handling, per Claude Tag's own docs
Grounded in docs/docs/claude.com/docs/claude-tag/concepts/security-and-data.md ("Security and data handling") -- the doc agent-identity.md itself points to under "Related resources" for "where credentials are stored, what leaves your tenant, and what runs unattended." This page exists because identity and access are only trustworthy if the boundary they cross is actually enforced; this is the doc that describes the enforcement.
1. Every request follows the same three checkpoints
| Checkpoint | The guarantee |
|---|---|
| The sandbox | Runs on Anthropic's infrastructure and holds no credentials |
| Agent Proxy | Injects credentials from the credential store at request time, and blocks traffic to unlisted hosts by default |
| Your systems | See the agent's own accounts, so its actions there are attributable |
-- security-and-data.md, "How a request travels." This is the same three-zone diagram the agent-identity page already cites (Slack workspace → session sandbox → Agent Proxy → your systems); this doc is where the guarantee at each zone is actually specified rather than just diagrammed.
2. Credential storage: write-only, boundary-injected, narrowable
"Credentials you provision are kept in a separate credential store, not in the proxy itself... the model and the sandbox are not given the key." "A saved credential is not displayed again. The setup screens are write-only." "The credential travels only to the hosts you named when you added the connection."
-- security-and-data.md, "Credential storage." This is exactly the constraint this repo hit for real, not hypothetically: earlier build passes on subagentcontracts.com, subagentcitations.com, and subagentcache.com generated *_WRITE_SECRET values via wrangler secret put, and those values are now genuinely unrecoverable -- Cloudflare Worker secrets are write-only, the same "setup screens are write-only" property this doc describes for claude-tag's own credential store. That's not a bug in this repo's process; it's the same security property working as intended, documented honestly rather than worked around.
3. Network egress: default-deny, three outcomes
"Outbound traffic from a channel session's sandbox is default-deny... every request gets one of three outcomes: Matches a credential rule (attached, proceeds) / Matches only an allowlist (sent without credentials) / Matches nothing (blocked outright; the host is unreachable rather than merely unauthenticated)."
-- security-and-data.md, "Network egress." The agent-identity page's own Agent Proxy table already states the same three-outcome rule for outbound requests; this doc restates it specifically as the reason "data can only leave the sandbox to hosts you've allowed" -- the same default-deny posture id_engineering_coworker_binary on the identities board mirrors: the binary mediates the boundary, Claude itself never gets a credential capable of reaching further than the six tools it exposes.
4. Service accounts are shared, so use a dedicated one per service
"A connection belongs to that agent identity and is shared by everyone the bundle's scope covers... Connect a dedicated identity you control for each service, such as a claude@yourcompany.example.com seat or a native service account, rather than a personal login."
-- security-and-data.md, "Service accounts." This is the same principle id_cloudflare_account and id_cloud_docker_mcp on the identities board already dogfood: the shared Cloudflare account and the Docker MCP Toolkit catalog are both dedicated, provisioned identities distinct from any individual operator's personal login -- exactly the shape this doc recommends, not a personal credential reused across every session.
What this site adds
Claude Tag's security model lives inside one product's own docs, describing guarantees a reader has to take on faith unless they can inspect the actual infrastructure. This site can't inspect Anthropic's sandbox -- but it can, and does, hold itself to the same standard for its own infrastructure: every identity row on the identities board names its real credential source, every directive row on the directives board quotes the real enforced rule, and this page's own "write-only credential store" claim is one this repo has already verified the hard way, not merely asserted.