Every POST/PATCH route on every D1-backed primitive in the subagent*.com family (identities, contracts, tasks, citations, rubrics, outcomes, evaluations, brands, code, prompts, skills, roles, memories, and more)

requireBearerAuth(request, env.<SITE>_WRITE_SECRET) in workers/_shared/kit/http.ts — returns 503 if no secret is configured, 401 if the bearer token doesn't match, null (proceed) otherwise

The direct functional analogue of restrict-access.md's Members setting: it doesn't control who can *read* a site (every GET route is open, matching claude-tag's "anyone in the channel" default) but it does control who can *act* — the same "who can invoke Claude at all" question, applied to "who can write to this primitive."

admins/restrict-access.md, "Control who can invoke Claude Tag" / "Members"

Every *_WRITE_SECRET value across the family, once set via wrangler secret put

Cloudflare Worker secrets have no read-back API — a secret can be overwritten or deleted, never displayed again after it's set

This is the same write-only property security-and-data.md documents for claude-tag's own credential store ("A saved credential is not displayed again. The setup screens are write-only.") — already cited on subagentidentities.com's security-and-data-handling page. It is not reversible in the sense of "recover the old value," matching restrict-access.md's own note that deleting a bundle "revokes its credentials everywhere it was attached."

admins/restrict-access.md, "Quiet or remove Claude Tag", step 5 ("Delete the bundle"); concepts/security-and-data.md, "Credential storage"

Any single subagent*.com Worker

Deleting or commenting out the [[routes]] block in that worker's wrangler.toml and redeploying — the domain falls back to serving nothing (or a parked-domain response) at that route

The closest repo equivalent to restrict-access.md's step 4, "Detach the scope. The channel loses its elevated access and falls back to inherited baselines" — a worker losing its route stops answering requests but its D1 data, code, and git history are all untouched, the same way detaching a scope doesn't delete a bundle's credentials.

admins/restrict-access.md, "Quiet or remove Claude Tag", step 4 ("Detach the scope")

N/A — documented gap, not a control

N/A

restrict-access.md is explicit that claude-tag itself has no "per-user spend caps on channel work" either ("Spend limits apply at the organization and channel level. There's no way to cap what one member can spend in channels"). This repo has the same real gap: nothing meters or caps how much any individual operator session spends against a shared Cloudflare account or D1 database. Seeded here as an honest "controls that aren't available" entry, mirroring that section of the same doc, rather than silently omitted.

admins/restrict-access.md, "Controls that aren't available", "Per-user spend caps on channel work"