Access bundles, per Claude Tag's own docs
Of everything agent-identity.md, attach-to-scope.md, and security-and-data.md all point back to, one concept has the highest fan-in: the Access bundle. Grounded in docs/docs/claude.com/docs/claude-tag/admins/add-connections.md ("Give Claude access to your tools") and admins/connections/overview.md ("Per-service connection guides"), this is the single claude-tag primitive every other page on this site already assumes exists -- so it's built here last, once the concepts that depend on it were already in place to link back to it.
1. The definition
"An Access bundle is a named set of credentials, repository grants, and instructions that Claude uses in the channels the bundle covers. A connection is one service credential inside a bundle, like a Datadog API key or a warehouse service account, that Claude uses to act in that service from any channel under the bundle's scope."
-- add-connections.md, "Your first Access bundle." This site's access_bundles table generalizes that definition directly: connections is the credential set, plugins_or_skills is the instructions that travel with it, and scope_attached_to is the channel/workspace/Default-Slack-access binding the directives page already generalizes as scope (repo_wide vs. surface_scoped).
2. Connections belong to the identity, not the person
"Connections belong to the agent identity, not to any person. Personal claude.ai connectors apply only in DMs." ... "The credential you connect is Claude's account in that tool, not yours. Anyone in a channel under the bundle's scope can use it through Claude, so connect a dedicated identity you control rather than your personal login."
-- add-connections.md, "Your first Access bundle" and "Create a dedicated account per service." This is exactly the attribution_mode = 'service_account' axis already on the identities table -- a bundle's connections are provisioned once and shared by every session under its scope, the same shape as id_cloud_docker_mcp's Docker MCP Toolkit catalog and id_cloudflare_account's shared Cloudflare account, both already seeded there.
3. Credential types
| Credential type | Use for |
|---|---|
| Bearer | API keys and OAuth bearer tokens. Most SaaS REST APIs. |
| Basic | HTTP Basic authentication. |
| AWS SigV4 | Signed requests to AWS APIs with an access key pair. |
| GCP service account key | Google Cloud APIs via a service-account JSON key. |
| OAuth 2.0 client credentials | Server-to-server OAuth. |
| OAuth 2.0 JWT bearer | Server-to-server OAuth. Salesforce uses this. |
| OAuth 2.0 authorization code | Sign in once as an admin; the agent acts as that account. |
-- add-connections.md, "Add a connection." This site doesn't fabricate a credential-type column for its own four seeded bundles, because none of them use a claude-tag-managed credential store -- they're local npx/binary MCP servers (Mac OS-level auth) or a Docker MCP Toolkit catalog (its own provisioning UI), not Bearer/OAuth entries in this specific console. credential_pattern records the real, honest mechanism for each instead of forcing a fit.
4. Fourteen real per-service connection guides exist and are cataloged, not mirrored
-- connections/overview.md lists real, documented setup guides for Datadog, Sentry, PagerDuty, Linear, Asana, Notion, Google, HubSpot, Salesforce, Gong, GitLab, Snowflake, Stripe, and Vercel (GitHub is configured separately via the Claude GitHub App). This site does not re-mirror all fourteen guides -- that content already exists verbatim on subagentcowork.com/claude-tag -- but the six-category decision table (Knowledge and docs / Code / Data warehouse / Monitoring / Issue tracking / Go-to-market) is the framework the access-bundles board is built to be extended with real rows in, the day this repo's own agents start connecting to any of those fourteen services for real.
What this site adds
Access bundles are the credential/instruction unit every other primitive on this site already assumed. Making it explicit closes the loop: identity says who is acting, directives says what standing instructions apply, security and data handling says how the boundary is enforced, and access bundles says exactly what credentials and instructions travel together to make any of that possible. See the live board.