Cryptocurrency Market Live Briefing

• Outcome: Pass
• Latest audit: Sep 11, 2026 · 9:59 AM UTC
• Version: 1.0.2

Overview

This skill is a disclosed crypto market-data briefing tool that only reads public Desk3 API data and prints summaries, with minor locale and financial-guidance caveats.

Before installing, understand that the skill makes live requests to Desk3 domains and defaults output formatting/content language to English. Its indicator text may sound like trading guidance, so use it as market information rather than professional financial advice.

A.I.G

Vulnerability Patterns

• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (18)

Natural-Language Policy Violations

Medium

• Confidence: 92% confidence
• Finding: The documentation says to add `language: en` when making requests, which directs the skill toward a specific language choice by default. This can violate language/locale policy because it does not present English as an opt-in user preference at the point of instruction.

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: The request helper hard-codes a `language: 'en'` header, which imposes a specific language on all fetched content. The file does not provide a user opt-in, configuration option, or documented justification for this locale constraint.

Natural-Language Policy Violations

Low

• Confidence: 94% confidence
• Finding: The request hard-codes a `language: 'en'` header, which imposes a specific language/locale behavior. The file does not offer user opt-in, configurability, or a documented justification for restricting the request to English.

Natural-Language Policy Violations

Low

• Confidence: 93% confidence
• Finding: The request unconditionally sets the `language` header to `en`, which imposes a specific language choice in the skill's behavior. This is a natural-language policy concern because the file does not offer user opt-in, configurability, or a documented reason for restricting output to English.

Natural-Language Policy Violations

Low

• Confidence: 95% confidence
• Finding: The request hard-codes a language header of 'en', which imposes a specific language choice on all users. This is a natural-language policy concern because the script does not offer any way to select or opt into a different locale.

Natural-Language Policy Violations

Low

• Confidence: 93% confidence
• Finding: The script uses toLocaleString with 'en-US', forcing U.S. English formatting for dates and times regardless of user preference. This creates a locale policy issue because users are not given a choice or informed about the restriction.

Natural-Language Policy Violations

Low

• Confidence: 93% confidence
• Finding: The fetch request hard-codes a `language: 'en'` header, which imposes a specific language setting with no user opt-in or explanation. Under the policy rule for natural-language violations, locale constraints should either be optional for the user or clearly justified as region-specific.

Natural-Language Policy Violations

Low

• Confidence: 94% confidence
• Finding: The request hard-codes a `language: 'en'` header, which imposes a specific language/locale choice in the skill's behavior. The file does not offer user opt-in or explain why English is required, which matches the language/locale policy violation category.

Natural-Language Policy Violations

Low

• Confidence: 92% confidence
• Finding: The request hard-codes a `language: 'en'` header, which imposes a specific language choice without any user opt-in or explanation. This matches the policy category for language or locale constraints that are not user-selectable or clearly justified.

Natural-Language Policy Violations

Low

• Confidence: 94% confidence
• Finding: The request unconditionally sets a `language: 'en'` header, which imposes a specific language/locale choice in the skill's behavior. This matches the policy-violation category because the file provides no user opt-in, alternative locale selection, or justification for restricting responses to English.

Natural-Language Policy Violations

Low

• Confidence: 95% confidence
• Finding: The code sends a hard-coded `language: 'en'` header on every request, which imposes a specific language/locale without any user opt-in. This matches the policy-violation category for locale constraints because the file provides no mechanism to choose another language and no documented regional justification.

Natural-Language Policy Violations

Low

• Confidence: 91% confidence
• Finding: The request hard-codes a `language: 'en'` header, which imposes a specific language choice on all users. Under the policy, locale or language constraints should be optional or clearly justified; this file provides neither user opt-in nor documentation for the restriction.

Natural-Language Policy Violations

Low

• Confidence: 95% confidence
• Finding: The request hard-codes the HTTP header `language: 'en'`, which forces a specific language for fetched content. The file does not offer a user opt-in or configuration path for another language, which matches the language/locale policy violation criteria.

Natural-Language Policy Violations

Low

• Confidence: 92% confidence
• Finding: The call to `toLocaleString('en-US', ...)` hard-codes the U.S. English locale for displayed timestamps. Because the skill does not provide any locale selection or documented justification, this is a natural-language locale policy issue.

Natural-Language Policy Violations

Low

• Confidence: 95% confidence
• Finding: The request explicitly sets the `language` header to `en`, which imposes a specific language preference in natural-language behavior. The file does not offer user opt-in, configurability, or a documented region-specific reason for this constraint.

Natural-Language Policy Violations

Low

• Confidence: 95% confidence
• Finding: This second fetch repeats the same hard-coded `language: 'en'` behavior, again enforcing a locale choice in a way that may violate language/locale policy expectations. There is no indication that users can select another language or that English is required for compliance or system constraints.

Natural-Language Policy Violations

Low

• Confidence: 94% confidence
• Finding: The fetch request hard-codes a `language: 'en'` header, which imposes a specific language preference with no opt-in or configurability. The policy explicitly flags language or locale constraints unless the skill offers user choice or clearly documents a justified region-specific requirement.

Natural-Language Policy Violations

Low

• Confidence: 95% confidence
• Finding: The code hard-codes a `language: 'en'` request header, which enforces a specific language/locale behavior for all users. The policy allows locale constraints only when users are given a choice or when the limitation is clearly documented and justified, neither of which is present here.

Static analysis

No suspicious patterns detected.