Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent analytics-tracking guidance skill with privacy caveats, no executable code, and no hidden install or persistence behavior.
Before installing, be aware that this skill can help design and implement third-party analytics tracking. Use it with consent, data-minimization, and privacy-law review, and avoid sending names, emails, raw user data, secrets, or sensitive URL parameters to analytics vendors.
The manifest description says to use the skill whenever someone asks 'how to know if something is working' or wants to measure marketing results. That phrasing is broad enough to match many ordinary troubleshooting or evaluation requests outside analytics tracking, increasing the risk of unintended invocation.
The eval explicitly rewards triggering on a vague, casual complaint ('our tracking seems broken') without clear routing boundaries or disambiguation criteria. Broad trigger expectations can cause the skill to activate for loosely related troubleshooting requests, leading to misrouting, over-collection of context, or bypass of more appropriate specialized skills.
The reference explicitly recommends collecting persistent identifiers like user_id, account_id, session_id, referrer, and campaign data without any guidance on consent, minimization, retention, or avoiding sensitive data in free-form fields. In an analytics setup skill, this omission is more dangerous because users are likely to implement the schema directly, which can lead to over-collection, privacy-law noncompliance, and accidental transmission of personal or sensitive information to third-party analytics tools.
The reference explicitly shows setting GA4 user_properties and user_id but gives no guardrails about consent, prohibited PII, retention, or hashing/pseudonymization requirements. In an analytics-implementation skill, users may copy these snippets directly into production, increasing the risk of privacy violations, accidental transmission of identifying data to analytics platforms, and noncompliance with GA4 policy or data protection laws.
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 examples that push persistent user identifiers into the dataLayer and documents deployment of third-party tracking pixels, but it does not pair those examples with privacy, consent, or data-minimization guidance at the point of use. In an analytics implementation skill, users may copy these snippets directly into production, which can lead to collection or sharing of personal data without proper notice, consent, or legal basis.
No suspicious patterns detected.