Security audit
Security checks for vulnerabilities and agentic risk
This Zoho support skill is coherent, but it needs review because it sends and stores broad support ticket content with weak scoping and credential-destination controls.
Review this before installing in any real support environment. Use only least-privilege Zoho tokens, restrict ZOHO_DOMAIN to known Zoho Desk domains, confirm OpenAI processing is approved for your ticket data, redact sensitive fields before embedding or draft generation, and protect or regularly delete data/embeddings.json. Do not rely on drafts without human review.
lib/zohoClient.js:4Zoho OAuth Token Can Be Forwarded to an Arbitrary Configured Host
lib/vectorStore.js:6Sensitive Support Ticket Data Is Persisted in Plaintext
lib/replyGenerator.js:8Untrusted Ticket Content Enables Indirect Prompt Injection
The README says the skill analyzes tickets and generates drafts using OpenAI, but does not clearly disclose that ticket contents may be transmitted to an external AI provider. Because support tickets often include sensitive customer and operational data, this omission creates a meaningful risk of unauthorized third-party disclosure, policy violations, and regulatory noncompliance.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Configuration (in .env):
- ZOHO_DOMAIN (e.g. desk.zoho.com)
- ZOHO_TOKEN (OAuth access token)
- OPENAI_API_KEY
- OPENAI_MODEL (optional, default gpt-4o-mini or fallback)
- EMBEDDINGS_MODEL (optional, default text-embedding-3-small)
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Usage:
- Install via clawhub/publish or copy to workspace skills.
- Configure .env with ZOHO_TOKEN and OPENAI_API_KEY
Commands:
- ingest: Run historical ingest (npm run ingest)
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Usage:
- Install via clawhub/publish or copy to workspace skills.
- Configure .env with ZOHO_TOKEN and OPENAI_API_KEY
Commands:
- ingest: Run historical ingest (npm run ingest)
The README says the skill analyzes tickets and generates drafts using OpenAI, but does not clearly disclose that ticket contents may be transmitted to an external AI provider. Because support tickets often include sensitive customer and operational data, this omission creates a meaningful risk of unauthorized third-party disclosure, policy violations, and regulatory noncompliance.
The skill description states that it ingests historical support tickets, stores local embeddings, and uses an OpenAI API key, but it does not warn users that ticket contents may be transmitted to external AI services and retained locally as embeddings. Support tickets often contain sensitive customer, account, or operational data, so failing to disclose these data flows creates a real privacy and compliance risk.
The code ingests full closed-ticket subject, description, and resolution text, then stores embeddings alongside requester metadata for later retrieval. Support tickets commonly contain personal, account, billing, or incident details, so bulk retention and vectorization of historical content materially increases privacy, data-governance, and cross-ticket data leakage risk.
At this line, full ticket text is sent to an embeddings service, which is an external processing step for potentially sensitive support data. Without prior redaction, data-processing controls, or explicit disclosure/consent, this can expose customer information to third-party systems and create compliance and confidentiality risks.
The skill retrieves historical ticket text and uses it as context to generate replies for unrelated open tickets, which can leak sensitive information from prior cases into new responses. Because there is no filtering, authorization boundary, or redaction step on retrieved context, the RAG workflow can expose one customer's data to another or cause the model to reproduce confidential internal resolution details.
Open ticket contents are embedded and then combined with retrieved historical text for draft generation, meaning current and prior sensitive support data may be transmitted to external model services. This raises both third-party disclosure risk and prompt-context leakage risk, especially because no sanitization, customer-boundary checks, or warning mechanisms are present.
This code sends the provided texts to an external OpenAI embeddings endpoint, which may transmit user or system data off-host. While errors are logged, there is no confirmation prompt, user-facing notice, or explanatory comment/docstring in this file disclosing that text content is sent to a remote service.
The function sends raw ticket subject, description, and related context to the OpenAI API, which is an external third-party service. If tickets contain personal data, credentials, internal business information, or regulated content, this creates a privacy and data-governance risk when users are not clearly informed and the data is not minimized or sanitized before transmission.
This code persists supplied items, including id, text, and meta, into data/embeddings.json via fs.writeFileSync, which can retain user-derived content on disk. While there is an internal log message after saving, there is no user-facing prompt, warning comment, or explanatory docstring disclosing that data will be stored locally.
This code sends support ticket data through HTTP requests to the Zoho API, which can involve user or system data such as ticket subjects, descriptions, and requester/contact fields. While there is error logging and a missing-token warning, there is no comment, docstring, or user-facing disclosure here explaining that the skill retrieves and transmits potentially sensitive ticket content.
The file reads an OAuth token from the environment via ZOHO_TOKEN, which is a sensitive credential access pattern covered by the warning requirement for code files. Although the code warns when the token is missing, it does not explain to users or maintainers that the skill depends on a credential and will authenticate to an external service with it.
The dependency version for axios is specified with a caret range, which allows npm to install newer minor and patch releases rather than a single vetted version. This weakens build reproducibility and can unintentionally introduce vulnerable or malicious upstream releases through the supply chain.
"author": "",
"license": "MIT",
"dependencies": {
"axios": "^1.4.0",
"dotenv": "^16.0.0",
"openai": "^4.0.0",
"pino": "^8.0.0"
The manifest includes axios without pinning to an exact version, while advisories exist for some axios releases. Because the installed version cannot be verified from this file alone, there is a credible risk that deployments may resolve to an affected version, especially across environments or over time.
The dotenv dependency is not pinned to an exact version, so future installs may resolve to different package contents over time. That increases supply-chain risk and makes it harder to guarantee that the reviewed build matches the deployed build.
"license": "MIT",
"dependencies": {
"axios": "^1.4.0",
"dotenv": "^16.0.0",
"openai": "^4.0.0",
"pino": "^8.0.0"
}
The openai package uses a caret version range, allowing different releases to be installed without source changes. For a skill that processes support tickets and may handle sensitive data, non-reproducible dependency resolution increases the risk of unexpected behavior or supply-chain compromise.
"dependencies": {
"axios": "^1.4.0",
"dotenv": "^16.0.0",
"openai": "^4.0.0",
"pino": "^8.0.0"
}
}
The pino dependency is declared with a non-exact semver range, which permits unreviewed upstream updates during installation. This creates avoidable supply-chain exposure and reduces the integrity and reproducibility of the application environment.
"axios": "^1.4.0",
"dotenv": "^16.0.0",
"openai": "^4.0.0",
"pino": "^8.0.0"
}
}
Detected: suspicious.env_credential_access