### Summary
Google Chat allowlisting supports matching by sender email in addition to immutable sender resource name (`users/<id>`). This weakens identity binding if a deployment assumes allowlists are strictly keyed by immutable principals.

### Affected Packages / Versions
(As of 2026-02-14; based on latest published npm versions)
- `openclaw` (npm): `<= 2026.2.13`
- `clawdbot` (npm): `<= 2026.1.24-3`

### Details
Affected component:
- `extensions/googlechat/src/monitor.ts`

The `allowFrom` checks accept:
- Immutable sender id (`users/<id>`)
- Raw email (`[email protected]`) for usability

Historically, `users/<email>` was also treated as an email allowlist entry. This is now deprecated because it looks like an immutable ID but is actually a mutable principal.

### Security Triage (2026-02-14)
Severity: **Low**

Rationale:
- Requests are authenticated as coming from Google Chat (token verification), so this is not a generic unauthenticated spoofing vector.
- A realistic exploit generally requires **Google Workspace / IdP administrative control** over identity lifecycle (e.g. reassigning an email address to a different underlying account) to obtain the same email with a different `users/<id>`.
- With that level of access, the attacker typically has broader compromise paths.

We still treat it as a valid defense-in-depth report because accepting mutable principals in authorization decisions can increase risk in chained-failure scenarios.

### Remediation / Behavior Changes
Goal: preserve usability while reducing footguns.
- Raw email allowlists remain supported.
- `users/<email>` is deprecated and treated as a **user id**, not as an email allowlist.
- Documentation recommends `users/<id>` when strict immutable binding is required.

### Fix Commit(s)
- `c8424bf29a921e25663b29f308640b3d91a49432` (PR #16243)

Thanks @vincentkoc for reporting.

CWE-290

CWE-863 Incorrect Authorization