When a colleague tells you "ask the matter owner for access to doc X", paste X into /request-access. The form takes a resource kind (document or collection), a UUID, and an optional reason. Submitting queues a request and emails workspace owners + admins.
**Privacy-preserving by design.** Kodori does NOT confirm the resource exists before queueing the request. A typo or random UUID just sits in the queue until the admin denies it — no information leaks about which ids correspond to real resources. This is intentional: the same privacy posture that makes /doc/[id] return 404 for "doesn't exist" and "exists but you can't read" applies to the request form.
**Owners + admins review at /access-requests.** Each pending request shows the requester, the resource kind + id, the resolved name (if the resource exists), and the reason. Admins see two affordances: - **Grant read** — inserts a permission row (action=read, principalKind=user, resourcePattern=<kind>/<id>) and emits TWO audit events: `access-request.granted` on the access-request stream + a standard `permission.granted` on the resource's stream with a `grantedViaAccessRequest` cross-reference in the payload. The audit chain treats granted-via-request identically to admin-issued grants. - **Deny** — takes an optional decision-note. Emits `access-request.denied`. Doesn't grant anything; the requester can submit again later (granted/denied rows coexist with a fresh pending row on the same resource).
When the resource is missing or tombstoned, the queue badges it as "resource not found" and disables the Grant button — admins are nudged to Deny instead.
**Sidebar badge.** When the access-request queue has pending items, owners + admins see an ochre count badge next to Governance > Access requests. Hidden when the queue is empty.
**Email fan-out caps at 50 admin recipients per submission** so a workspace with a large admin pool doesn't spam everyone on every request. The in-app queue is the load-bearing review surface; email is the nudge.
**Granted permission is read-only.** The form doesn't expose write / share / delete asks — those belong in admin-driven workflows, not member self-service. Once you have read, you can see the doc's permission panel and make a normal admin request for elevated actions.