Lead Storage

Before installing or enabling this skill, get answers to these questions from the publisher or your integrator: - Exactly which storage backends does the skill write to (Google Sheets, which DB types and endpoints)? Provide concrete endpoint formats. - What credentials or config does it require (OAuth service account, GOOGLE_SHEETS_ID, DB_URL, DB_USER, DB_PASSWORD, etc.)? These should be declared explicitly so you can apply least privilege. - Where and how are credentials stored/used? Prefer short-lived tokens or scoped service accounts with write-only permissions. - How is the confirmation_token generated and validated? Confirm the skill cannot self-approve or accept spoofed tokens. - Ask for an implementation description or code sample showing the write path (which SDKs/APIs are used) and confirmation that no reads or analytics queries are executed. - Verify idempotency behavior (how duplicate lead_id is detected) and what logging/audit trails are produced for writes and rejections. If the publisher can provide explicit, matching metadata (required env vars and config paths) and an implementation that only uses documented, auditable write-only connectors, the incoherence is resolved and the risk decreases. If they cannot, treat the skill as suspicious because it claims to perform privileged network writes but exposes no clear authentication or destination mechanism. Also consider data governance: this skill will persist PII (names, phone numbers); ensure compliance with your policies and test in a non-production environment first.