Grant a user a target inside a tenant's namespace: an alias (`sa:operator`), a permission (`sa:work:leads:read`) or a `*` pattern (`sa:work:*`). Nothing grants anything in the `iam`, `concierge`, `bank` or `seat` namespaces (INVALID_ARGUMENT), and nobody grants to their own account (PERMISSION_DENIED). A target the tenant's catalog does not define grants nothing and is INVALID_ARGUMENT. Re-granting what is held is a no-op.

Who may: a seat holding iam:tenants:grant — any target. The holder of an alias the catalog lets delegate (delegations) — exactly the aliases it delegates, naming the user by account (an email or a username) only (a user_id is PERMISSION_DENIED: ids are visible in the roster, and granting one would reveal its owner's address). Anyone else, or a target outside the delegation: PERMISSION_DENIED, before the user is looked up. An email names the accounts it is verified on or backs a password of; only when it names none is the handle read as a username.

To a seat: an unknown user or handle is NOT_FOUND; a handle naming several accounts, or a disabled/held account, is FAILED_PRECONDITION with the reason. To a delegate all three are the SAME FAILED_PRECONDITION ("this address cannot be granted access"), so a grant never tells them whether, or how, a handle is known. A delegate gets a budget of GrantPermission + RevokePermission calls per hour (refusals included); past it, RESOURCE_EXHAUSTED.