Restrict access, per Claude Tag's own docs
permission-policies.md (the doc this whole site is built from) answers "what may a tool do once Claude decides to call it." docs/docs/claude.com/docs/claude-tag/admins/restrict-access.md ("Restrict where Claude Tag operates") answers a prior, distinct question: "who or what may invoke Claude at all." This page grounds the site's second table, invocation_controls, in that doc.
1. The Members setting
| Setting | Who can invoke Claude |
|---|---|
| Open to anyone in your Slack workspace (default) | Anyone in the connected workspace, with or without a Claude account |
| Open to any organization member | Anyone signed into a Claude account in the same organization that connected the workspace |
| Only members whose role allows it | Only members whose custom role grants the Claude in Slack capability |
-- restrict-access.md, "Members." This repo's own real equivalent, seeded as ivc_write_secret_gate, isn't a three-tier role setting -- it's binary and per-primitive: every D1-backed site's POST/PATCH routes are open to whoever holds that one site's *_WRITE_SECRET, and GET routes are open to anyone, the same "anyone in the channel" default the doc describes for the read side of a Slack channel.
2. Quiet or remove Claude Tag: six steps, narrowest to most complete
- Ask it to stay quiet. Stops it following an active thread.
- Remove it from the channel.
/remove @Claude— it can no longer read or post there. - Set the scope's version to Off. An @-mention gets a disabled notice instead of a reply.
- Detach the scope. The channel falls back to inherited baselines.
- Delete the bundle. Revokes its credentials everywhere it was attached.
- Uninstall the app. Removes Claude from the workspace entirely.
-- restrict-access.md, "Quiet or remove Claude Tag." Steps 1-4 and 6 do not delete any data. Step 5 (deleting a bundle) removes the credentials in that bundle; memory, routines, and session transcripts are unaffected by any of these steps. This repo has real, defensible equivalents for two of the six -- ivc_route_removal (removing a [[routes]] binding, the "detach a scope" analogue) and ivc_secret_never_retrievable (a Worker secret's write-only lifecycle, the "delete a bundle" analogue) -- and honestly has no equivalent for the other four, since this repo has no Slack channel or installed app to remove Claude from.
3. What claude-tag admits it doesn't have
"Per-user spend caps on channel work. Spend limits apply at the organization and channel level. There's no way to cap what one member can spend in channels."
-- restrict-access.md, "Controls that aren't available." Seeded here as ivc_no_per_operator_cap: this repo has the identical real gap, no mechanism meters or caps how much any one operator session spends against the shared Cloudflare account or a shared D1 database. Documenting a real absence honestly, the same way the source doc does, is more useful than pretending every claude-tag control has a repo equivalent.
What this site adds
Two tables now cover two genuinely different questions about the same underlying agent: permission_policies asks what a tool may do, invocation_controls asks who may set anything in motion at all. See the live board.