Vexa API key stored without documented rotation policy - bot integration key leak gives attacker control over meeting bots

[anshul23102]

Problem

The VEXA_API_KEY is stored as an environment variable (shown in
.env.example) with no documentation on:

• What the Vexa API key authorizes (e.g. whether it can create unlimited bots
  that consume transcription minutes).
• How to detect unauthorized usage of the key.
• How to rotate the key if it is leaked.
• Whether the key is scoped to specific meetings or is a global account key.

If the key is leaked (e.g. accidentally committed to the repository or exposed
in server logs), an attacker can start Vexa bots for any meeting, consuming
the account's transcription quota or incurring charges without limit.

Impact

• Unauthorized meeting bot creation and quota exhaustion.
• Potential exposure of meeting invites and transcription data if bots are
  started for meetings the attacker does not own.
• Financial cost from unauthorized usage of a paid transcription service.

Suggested Fix

1. Document in BACKEND.md the minimum required Vexa API permissions and
   how to create a restricted-scope key if the Vexa API supports it.
2. Add usage monitoring (Vexa dashboard alerts or webhook notifications) to
   detect unexpected bot activity.
3. Document a key rotation procedure in BACKEND.md.
4. Store the Vexa key only in Supabase Edge Function secrets, never in the
   Flutter client or any client-accessible configuration.
5. Add .env to .gitignore (verify it is not currently tracked) to prevent
   accidental commits.

[anshul23102]

@AOSSIE-Org Could you please assign this issue to me? I'd like to work on it under GSSoC '26.
/assign
/claim