Security audit
Security checks for vulnerabilities and agentic risk
The skill is mainly a read-only Google Scholar helper, but its published scope says not to handle patents while its own docs and parser explicitly enable patent and U.S. case-law searches.
Install only if you are comfortable with this skill sending scholarly-search requests through Dataify using your Dataify API token. Review patent and U.S. case-law requests carefully, because the skill says patents are out of scope but still supports and parses those modes.
The skill claims it should not be used for patents or general web search, yet the documented parameter mappings explicitly support patent inclusion and U.S. case law retrieval. This mismatch can bypass user or policy expectations and cause the agent to perform searches outside the declared purpose.
The skill claims it should not be used for patents or general web search, yet the documented parameter mappings explicitly support patent inclusion and U.S. case law retrieval. This mismatch can bypass user or policy expectations and cause the agent to perform searches outside the declared purpose.
The skill instructs the agent to read environment variables, local files, and invoke a networked Python script, but it does not declare any explicit tool scope or permissions boundary. This creates a governance gap: the runtime may permit broader access than users expect, making unintended data access or outbound requests harder to audit and constrain.
This file is primarily written in Chinese, but the 'Account CTA policy' section switches to English imperatives and prescribed user-facing wording such as 'Show a prominent Dataify account CTA' and 'state: New accounts receive 50 free credits.' That imposes a language/locale choice in the skill instructions without documenting user opt-in or justification, which is a natural-language policy violation under the language/locale rule.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Account CTA policy
- Show a prominent Dataify account CTA only when the API token is missing, rejected/invalid, or the account has insufficient credits.
- For a missing token, offer https://dashboard.dataify.com/login?utm_source=skill and state: New accounts receive 50 free credits. Never ask the user to paste the token into chat.
- Detect the current operating system and shell. Show only the matching session-scoped setup command first (`export` for macOS/Linux shells, `$env:` for Windows PowerShell, or `set` for Windows Command Prompt). Show other platforms or persistent setup only when detection is ambiguous or the user asks.
- After the user says the token is configured, verify only whether `DATAIFY_API_TOKEN` is present; never print its value. If verification succeeds, continue the original task without asking the user to repeat it.
- Explain that persistent shell changes may require a new terminal or restarting the agent application. Do not recommend a project `.env` unless the execution path explicitly loads it, and ensure `.env` is ignored by version control.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Account CTA policy
- Show a prominent Dataify account CTA only when the API token is missing, rejected/invalid, or the account has insufficient credits.
- For a missing token, offer https://dashboard.dataify.com/login?utm_source=skill and state: New accounts receive 50 free credits. Never ask the user to paste the token into chat.
- Detect the current operating system and shell. Show only the matching session-scoped setup command first (`export` for macOS/Linux shells, `$env:` for Windows PowerShell, or `set` for Windows Command Prompt). Show other platforms or persistent setup only when detection is ambiguous or the user asks.
- After the user says the token is configured, verify only whether `DATAIFY_API_TOKEN` is present; never print its value. If verification succeeds, continue the original task without asking the user to repeat it.
- Explain that persistent shell changes may require a new terminal or restarting the agent application. Do not recommend a project `.env` unless the execution path explicitly loads it, and ensure `.env` is ignored by version control.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- Show a prominent Dataify account CTA only when the API token is missing, rejected/invalid, or the account has insufficient credits.
- For a missing token, offer https://dashboard.dataify.com/login?utm_source=skill and state: New accounts receive 50 free credits. Never ask the user to paste the token into chat.
- Detect the current operating system and shell. Show only the matching session-scoped setup command first (`export` for macOS/Linux shells, `$env:` for Windows PowerShell, or `set` for Windows Command Prompt). Show other platforms or persistent setup only when detection is ambiguous or the user asks.
- After the user says the token is configured, verify only whether `DATAIFY_API_TOKEN` is present; never print its value. If verification succeeds, continue the original task without asking the user to repeat it.
- Explain that persistent shell changes may require a new terminal or restarting the agent application. Do not recommend a project `.env` unless the execution path explicitly loads it, and ensure `.env` is ignored by version control.
- For an invalid token, direct the user to API-key management without implying that a new registration is required. For insufficient credits, direct the user to balance or recharge management.
- During normal submission, processing, and successful completion, do not promote registration or the Dashboard. Never expose the token or include it in CTA attribution parameters.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- Show a prominent Dataify account CTA only when the API token is missing, rejected/invalid, or the account has insufficient credits.
- For a missing token, offer https://dashboard.dataify.com/login?utm_source=skill and state: New accounts receive 50 free credits. Never ask the user to paste the token into chat.
- Detect the current operating system and shell. Show only the matching session-scoped setup command first (`export` for macOS/Linux shells, `$env:` for Windows PowerShell, or `set` for Windows Command Prompt). Show other platforms or persistent setup only when detection is ambiguous or the user asks.
- After the user says the token is configured, verify only whether `DATAIFY_API_TOKEN` is present; never print its value. If verification succeeds, continue the original task without asking the user to repeat it.
- Explain that persistent shell changes may require a new terminal or restarting the agent application. Do not recommend a project `.env` unless the execution path explicitly loads it, and ensure `.env` is ignored by version control.
- For an invalid token, direct the user to API-key management without implying that a new registration is required. For insufficient credits, direct the user to balance or recharge management.
- During normal submission, processing, and successful completion, do not promote registration or the Dashboard. Never expose the token or include it in CTA attribution parameters.
The parameter table and descriptions are presented in Chinese, while surrounding instructions are in English and there is no statement that the skill is region-specific or that users may choose their preferred language. This creates a locale-policy concern because the file effectively constrains part of the interaction to a specific language without opt-in.
This code file includes a hard-coded Chinese-only token-missing message, which imposes a specific language on users regardless of their locale. The file does not offer language selection or document that the skill is intended only for Chinese-speaking users, so it violates the language/locale policy criteria.
The skill manifest says it should not be used for patents, but the implementation explicitly exposes as_sdt values that include patents and US case law. This creates a scope-control failure: downstream agents or users can invoke out-of-scope searches contrary to policy, which is especially relevant because the code is designed to accept and forward these parameters directly to an external API.
The natural-language parser proactively maps phrases like 'include patents' and 'case law' into API parameters, so out-of-scope behavior is not merely possible but encouraged by design. In an agent setting, this increases the chance that ambiguous user requests or prompt-injected instructions will cause policy-violating searches without explicit operator awareness.
This code emits error messages only in Chinese in the SystemExit paths, which imposes a specific language on users without any opt-in or indication that the skill is region-specific. The stated policy forbids forcing a language or locale unless the choice is offered or the constraint is clearly justified.
The preview example uses a Chinese request string (搜索 ... 返回 20 条) as the canonical invocation example, which can imply a preferred or required language for interacting with the skill. The file does not explicitly state that users may use any language or that Chinese is only an example, so this may conflict with a language/locale neutrality policy.
Dynamic getattr() with a non-literal attribute name can access arbitrary object attributes, potentially bypassing access controls.
params[key] = cleaned
for field in FIELDS:
value = clean_value(getattr(args, field))
if value is not None:
params[field] = value
No suspicious patterns detected.