Is giorgallidis/clawcrm safe?

The email-integration.md documents a full OAuth flow granting the agent gmail.send and gmail.readonly scopes (or Microsoft Graph Mail.Send and Mail.Read). This allows the agent to read all threads and send email impersonating the user from their real address. A compromised ClawCRM backend returning malicious followup templates, or a prompt injection via lead quiz data, could silently exfiltrate inbox contents or send unauthorized emails from the user's identity.

The Himalaya integration commands operate at the account level — 'himalaya envelope list --account ' is not scoped to a single inbox folder or thread. The agent can enumerate and read all messages in the account. A malicious lead reply or server-returned prompt injection payload could trigger broader inbox sweeps beyond the intended outreach thread matching.

The skill instructs the agent to fetch actionable follow-ups and email templates from GET /api/openclaw/followups, then act on them. This endpoint is served by an externally-hosted ClawCRM instance (netlify.app or self-hosted) controlled by the skill author. If that server returns email body content containing adversarial instructions, the agent would process them as legitimate directives within the CRM workflow context. The IMAP reply-reading loop creates a second injection surface via inbound lead replies.

The outreach workflow explicitly instructs the agent to use quiz answers, pain points, and lead-provided data to draft emails: 'Use quiz answers, practice type, location, and pain points.' Lead quiz answers originate from external users submitting the ClawCRM quiz funnel. A malicious lead could craft quiz answers containing prompt injection payloads that the agent then processes when drafting personalized outreach, potentially redirecting agent behavior mid-task.

All lead data including financial custom fields (annual_revenue, insurance_type), personal contact information, quiz responses, and pipeline stage data is stored on and retrieved from a ClawCRM server hosted at a Netlify deployment URL controlled by the skill author (giorgallidis). The skill author has full server-side visibility into all data the agent creates, reads, or updates through this API.

The PUT /api/openclaw/org endpoint replaces all organizational settings in a single operation including contact emails, branding, and feature enable flags. An agent misinterpreting a partial update request as a full reset, or following a malicious instruction, could silently disable features (analyticsEnabled, emailIntegrationEnabled) or redirect contact emails to an attacker-controlled address.

The skill's stated principle 'Human-in-the-loop for sends — Only send after approval unless explicitly told to auto-send' means the safety gate is user-defeatable by a single instruction. Once in auto-send mode, the agent executes bulk email campaigns to all leads without per-send confirmation, including multi-channel sequences targeting LinkedIn and Twitter.

Campaign step definitions include LinkedIn and Twitter channels in addition to email and SMS. This means an agent following outreach playbook instructions may perform social media actions (connection requests, direct messages) as part of automated sequences, potentially outside the user's awareness of the full scope of agent activity.

The canonical API call pattern embeds $(cat secrets/clawcrm-token.txt) and $(cat secrets/mailersend-api-key.txt) directly in curl command templates. While scoped to the skill's own secrets directory, this pattern normalizes filesystem credential reads executed via shell substitution and could be extended by a chained skill or follow-on instruction to read other credential paths.

The skill contains no standalone executable files. All code appears as illustrative bash snippets within markdown. However, the agent will interpret and execute these curl, himalaya, and git-style commands at runtime when following skill instructions. This is normal for a documentation-style skill but means the execution surface is determined at agent-runtime rather than being auditable as static code.

Honeypot files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, GCP application_default_credentials.json) appear in both inotify ACCESS events and auditd PATH records. Accesses occur at pre-install timestamp 1771908580 (before git clone at 1771908586) and post-install timestamp 1771908604 (after installation completes). File contents are confirmed intact. The timing pattern and the absence of any executable code in the skill strongly indicate these reads were performed by the audit framework during baseline hashing and post-install integrity verification.

Installation contacted only github.com (140.82.121.4:443) via git clone with sparse-checkout. Pre-existing connections to Canonical/Ubuntu servers (91.189.91.49, 185.125.188.58) appeared in the BEFORE snapshot and were gone in AFTER, indicating they were system-level connections unrelated to the skill. No new listening ports, no processes spawned outside the install script, no files written outside the skill directory.