Access Request Handling

Turn this "give <user> access to <resource>" ticket into an approved,
least-privilege, documented grant — with an expiry and revert plan whenever the need
is temporary.

1. Identify precisely: look up the contact who needs access, which resource (exact
   folder path, calendar, DL, or mailbox name), what level (read, contribute, full),
   and for how long. If the request says only "access," ask — never assume full
   control.

2. Check the client's access policy in the knowledge base and their IT documentation
   (IT Glue): who owns or approves this resource? If an approver is defined, get their
   sign-off before granting (send an approval request, or use the client's documented
   channel). If the requester IS the resource owner, that counts.

3. Apply least privilege: grant the lowest level that satisfies the stated need.
   Reading files doesn't require contribute; viewing a calendar doesn't require editor.

4. If the need is temporary (project, covering leave, audit), set an explicit expiry
   date and create the revert as a real follow-up — a note with the removal date and
   owner, or a scheduled follow-up ticket — so the grant doesn't become permanent by
   neglect.

5. Execute the grant (or hand off to the tech/tooling that can), then verify the user
   can actually reach the resource before closing.

6. Post a plain-text internal note: who was granted what level on which resource, who
   approved, why, and any expiry with its revert plan. Log time and confirm to me.

Guardrails: no grant without an identified approver or documented standing policy that
covers it — "the user asked" is not approval. Least privilege is the default; escalate
any request for full control of a resource the user doesn't own. Every temporary grant
gets an expiry and a tracked revert. If the resource or its owner can't be identified
with confidence, do not grant — ask. Security-group membership routes to the Group
Membership Request skill; mailbox delegation specifics route to Shared Mailbox
Delegation.