Understanding the SiteSkills Security Scanner

February 8, 2026

Security is the foundation of any marketplace. When developers install a SiteSkills skill, they are trusting that it will not instruct their browser agent to do anything malicious -- no credential harvesting, no data exfiltration, no hidden redirects. That trust depends entirely on our scanning pipeline.

Every skill uploaded to SiteSkills goes through an automated 3-stage security scan before it can appear on the marketplace. This post explains how each stage works, what gets flagged, and how creators can ensure their skills pass on the first try.

Why Security Matters for Browser Automation

Browser agents are powerful. They can click buttons, fill forms, navigate pages, and read content. That power creates a unique attack surface: a malicious skill could instruct an agent to navigate to a phishing page, submit credentials to an attacker-controlled endpoint, or exfiltrate sensitive data from a logged-in session.

Traditional package managers deal with executable code, and their security scanners look for malicious code patterns. SiteSkills skills contain no executable code -- they are Markdown instructions and JSON metadata. But that does not make them inherently safe. A well-crafted set of instructions could still guide an agent toward harmful behavior.

Our scanner is purpose-built for this threat model. It does not scan for buffer overflows or dependency vulnerabilities. It scans for instructions that could lead a browser agent to cause harm.

The 3-Stage Pipeline

When you run siteskills publish, your skill enters a pipeline that runs three independent analysis stages. Each stage produces a score, and the weighted combination determines the final result.

Stage 1: Static Analysis

The first stage is fast, deterministic, and catches the most common issues. It examines the raw content of every file in the skill directory without any AI involvement.

What it checks:

• File structure compliance. Does the skill contain the required files (SKILL.md, siteskills.json, README.md)? Are there any prohibited file types (.js, .py, .sh, .exe, or any other executable format)?
• Size limits. Is the total zipped size under 5 MB? Are there fewer than 50 files? Are individual files within reasonable bounds?
• Schema validation. Does siteskills.json pass the Zod schema? Are all required fields present with valid types?
• Domain verification. Do the declared target domains resolve? Are the URL patterns well-formed?
• Pattern matching. The scanner checks SKILL.md and README.md against a curated list of suspicious patterns. These include references to external URLs outside the declared target domains, instructions to input credentials into non-target sites, base64-encoded strings, and data URI schemes.
• Metadata consistency. Does the step count in siteskills.json match the actual number of steps in SKILL.md? Do the declared failure modes correspond to fallback instructions?

Scoring: Static analysis contributes 40% of the total score. Most well-intentioned skills pass this stage without issue.

Stage 2: Permission Analysis

The second stage examines what the skill asks the browser agent to do and whether those actions are appropriate for the declared purpose.

What it checks:

• Action scope. Does the skill stay within its declared target domains? If a skill says it works on amazon.com but includes instructions to navigate to a different domain, that gets flagged.
• Data handling. Does the skill instruct the agent to copy, screenshot, or transmit sensitive page content? Reading confirmation messages is normal. Instructing the agent to capture and report the full contents of a banking page is not.
• Authentication boundaries. If the skill declares requires_auth: false, does it nonetheless include instructions that would only work for authenticated users? Inconsistencies between metadata and instructions are a signal.
• Escalation patterns. Does the skill ask the agent to bypass security controls, dismiss warnings, or override browser protections? Legitimate skills work within the browser's normal security model.
• Input parameter safety. Are input parameters used safely? A url parameter that gets used in a navigation action is fine. A parameter that gets injected into a form field labeled "password" on a non-target domain is not.

Scoring: Permission analysis contributes 30% of the total score. This stage catches subtler issues that pattern matching alone would miss.

Stage 3: Content Analysis

The third stage uses an LLM to review the skill holistically. While the first two stages are rule-based, this stage applies judgment.

What it checks:

• Navigation quality. Are the steps clear and unambiguous? Could a browser agent reasonably follow these instructions? Are the DOM hints sufficiently specific?
• Fallback completeness. Does every step have a meaningful fallback? Are the fallbacks actually recoverable, or do they just say "retry"?
• Intent alignment. Does the skill do what it claims to do? A skill called "amazon-add-to-cart" should add items to a cart, not navigate to a competitor's site.
• Social engineering. Does the skill include instructions that could manipulate the user? For example, instructions to display a fake error message asking the user to re-enter credentials.
• Overall quality. Is this a skill that would benefit the ecosystem? Low-effort skills with vague instructions and no fallbacks receive lower quality scores even if they are not malicious.

Scoring: Content analysis contributes 30% of the total score. The LLM provides a structured assessment with per-category scores and explanatory notes.

How the Scoring System Works

Each stage produces a score from 0 to 100. The final score is a weighted average:

Final Score = (Static * 0.40) + (Permission * 0.30) + (Content * 0.30)

The result determines what happens next:

Score	Result
80-100	Auto-approved. Skill appears on the marketplace immediately.
50-79	Manual review. Queued for human review by the SiteSkills team.
0-49	Rejected. Creator receives a detailed report with specific issues to fix.

Creators always receive the full scan report on their dashboard, regardless of the outcome. The report includes per-stage scores, specific findings, and actionable recommendations.

What Gets Flagged (Common Examples)

Here are the most common reasons skills get flagged during scanning:

External domain references. Your skill targets example.com but your SKILL.md includes a step that navigates to tracking.example-analytics.com. Even if this is a legitimate subdomain, the scanner flags it because it is not in your declared target.domains. Fix: add all relevant domains to the target list.

Overly broad URL patterns. A URL pattern like https://*/* matches every HTTPS page on the internet. The scanner expects patterns scoped to your target domains. Fix: use specific patterns like https://example.com/checkout/*.

Missing fallbacks. Steps without fallback instructions get flagged in both static analysis and content analysis. Every step should specify what happens when the expected element is not found or the page is in an unexpected state.

Inconsistent metadata. If siteskills.json says the skill has 5 steps but SKILL.md contains 3, the scanner flags the mismatch. Keep your metadata in sync with your content.

Credential-adjacent instructions. Any instruction that mentions passwords, credit card numbers, or other sensitive data receives extra scrutiny. If your skill legitimately needs the user to be authenticated, declare requires_auth: true and document the authentication requirement clearly, but never instruct the agent to handle credentials directly.

Tips for Passing the Scanner

1. Declare all domains up front. If your skill navigates to any URL, even a CDN or API endpoint, include that domain in target.domains.

2. Keep your skill focused. A skill that does one thing well scores higher than a skill that tries to automate an entire website. Smaller scope means fewer flags.

3. Write detailed fallbacks. For every step, answer the question: "What should the agent do if this does not work?" Include specific detection conditions and recovery actions.

4. Match your metadata to your content. Run siteskills validate locally before publishing. It catches most metadata inconsistencies that would flag in the scanner.

5. Avoid unnecessary navigation. If a step navigates away from the target domain and back, the scanner will flag it even if the intent is benign. Minimize cross-domain navigation.

6. Be explicit about authentication. If the user needs to be logged in, say so in the prerequisites, in the metadata, and in the fallbacks. Consistency signals legitimacy.

The Scanner Evolves

The scanning pipeline is not static. We continuously update pattern lists, refine LLM prompts, and incorporate learnings from manual reviews. When we encounter a new class of issue, we add detection for it. When we find that a rule produces too many false positives, we tune it.

Our goal is a scanner that catches real threats while creating minimal friction for legitimate creators. If you believe your skill was flagged incorrectly, the manual review process exists exactly for that situation. Reviewers can override scanner findings and approve skills that are genuinely safe.

Security in a marketplace is not a one-time problem -- it is an ongoing commitment. The scanner is one part of that commitment. Community reporting, execution telemetry, and creator reputation all contribute to keeping the SiteSkills ecosystem trustworthy.

Have questions about the scanner? Reach out at security@siteskills.ai.