Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent analytics guidance skill with no executable install behavior, but its tracking examples require careful privacy and consent review before production use.
Install only if you want analytics implementation guidance. Before using its GA4, GTM, Google Ads, or Facebook Pixel examples in production, review privacy obligations, gate tags on appropriate consent, avoid sending PII or secrets, use pseudonymous IDs, and redact free-text errors or URLs that may contain sensitive data.
The trigger language is overly broad because it says to use this skill whenever someone asks how to know if something is working or wants to measure results. That can cause misrouting of unrelated requests into the analytics skill, leading the agent to apply analytics-specific guidance outside its intended scope and potentially bypass more appropriate domain-specific skills.
This JSON eval file is a manifest-like file, so vague-trigger checks apply. The phrases 'Should trigger on casual phrasing' and the example prompt ending with 'help?' indicate activation on broad everyday language, but the file does not define boundaries or exclusions for when the skill should or should not activate.
The reference explicitly recommends tracking persistent identifiers and potentially sensitive fields such as user_id, account_id, transaction_id, pricing/value, and detailed error_message without any guidance on minimization, hashing, consent, retention, or prohibitions on personal/sensitive data. In an analytics skill, this is dangerous because users may copy these schemas directly into GA4/GTM/Mixpanel/Segment implementations, leading to unnecessary collection of personal or financial data and possible privacy, compliance, and data-exposure risks.
The document recommends enabling Google Signals and later discusses exporting audiences to Google Ads, but provides no warning that these features can expand cross-device profiling, ad personalization, and data sharing obligations. In this skill context, readers are likely to treat the guidance as implementation-ready, so the lack of consent/privacy caveats materially increases the chance of non-compliant deployment.
The guide shows setting GA4 user_properties and user_id directly, but does not warn about consent requirements, data minimization, or the prohibition on sending personally identifiable information. In an analytics implementation reference, this omission can lead practitioners to deploy identity-linked tracking in ways that violate privacy policies, platform terms, or regulatory requirements.
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.
### DebugView
Enable with:
- URL parameter: `?debug_mode=true`
- Chrome extension: GA Debugger
- gtag: `'debug_mode': true` in config
The reference includes analytics and advertising pixel implementation examples, including Facebook Pixel and consent-related snippets, without an explicit warning that these integrations collect and transmit user data to third-party platforms. In an analytics implementation skill, users may copy these examples directly into production, which increases the likelihood of privacy-noncompliant deployment, especially where consent, notice, or lawful basis is required.
No suspicious patterns detected.