Trust Assessment
k8s-browser received a trust score of 65/100, placing it in the Caution category. This skill has some security considerations that users should review before deployment.
SkillShield's automated analysis identified 3 findings: 1 critical, 1 high, 1 medium, and 0 low severity. Key findings include Broad Browser Access to Sensitive Internal Resources and Data Exfiltration, Risk of Credential Harvesting and Token Leakage through Form Filling and Custom Headers, Reliance on External Browser Provider with API Key.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. The LLM Behavioral Safety layer scored lowest at 48/100, indicating areas for improvement.
Last analyzed on February 13, 2026 (commit 13146e6a). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings3
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| CRITICAL | Broad Browser Access to Sensitive Internal Resources and Data Exfiltration The skill provides functions (`browser_open`, `browser_navigate`, `browser_content`, `browser_screenshot`) that allow opening arbitrary URLs and retrieving their full content or screenshots. The examples demonstrate accessing sensitive internal resources like the Kubernetes Dashboard (via `kubectl proxy` on `localhost:8001`), Grafana, and ArgoCD. An attacker could craft a prompt to instruct the LLM to navigate to a malicious or sensitive internal URL, retrieve its content (e.g., `browser_content()`), and potentially exfiltrate highly sensitive information (e.g., cluster state, metrics, application configurations, user data) back to the LLM, which could then be leaked. The access to `localhost:8001` effectively grants the browser access to the Kubernetes API with the permissions of the user running `kubectl proxy`, representing a significant privilege escalation risk. Implement strict URL allow-listing for `browser_open` and `browser_navigate` to restrict access only to known, safe internal UIs. Ensure the browser environment is heavily sandboxed and isolated from the host system and network. Implement data redaction or content filtering for `browser_content()` output to prevent sensitive information from being returned to the LLM. Consider requiring explicit user confirmation for accessing sensitive URLs or retrieving their content. | LLM | SKILL.md:30 | |
| HIGH | Risk of Credential Harvesting and Token Leakage through Form Filling and Custom Headers The skill provides functions (`browser_open_with_headers`, `browser_fill`, `browser_type`) that allow the LLM to inject arbitrary headers (including `Authorization` tokens) and fill out web forms with user-provided or LLM-generated text. The examples explicitly show passing `Bearer` tokens and filling `username`/`password` fields. An attacker could craft a prompt to instruct the LLM to navigate to a phishing site, input sensitive credentials (e.g., from user input or other context) into a malicious form, or send sensitive `Authorization` tokens to an attacker-controlled endpoint, leading to credential harvesting or token leakage. Implement strict validation and sanitization of all inputs to `browser_open_with_headers`, `browser_fill`, and `browser_type`. Avoid allowing the LLM to directly construct or inject sensitive data like API keys or passwords into these functions without explicit user confirmation or secure secret management. Consider using a secure credential store instead of passing tokens directly in prompts. Implement warnings or require explicit user consent when sensitive data is about to be sent or entered into forms. | LLM | SKILL.md:35 | |
| MEDIUM | Reliance on External Browser Provider with API Key The skill's setup instructions indicate the use of external browser providers like `browserbase` or `browseruse`, requiring an API key (`BROWSERBASE_API_KEY`). This introduces a supply chain risk as the security of the browser automation relies on the security and integrity of these third-party services. A compromise of the external provider could lead to unauthorized access to the browser environment, data exfiltration, or other malicious activities. Clearly document the security implications of using external browser providers. Advise users to use dedicated, least-privilege API keys. Implement robust monitoring and auditing of API key usage. Consider offering an option for a self-hosted, sandboxed browser environment to reduce reliance on external services for highly sensitive operations. | LLM | SKILL.md:20 |
Scan History
Embed Code
[](https://skillshield.io/report/a50f954707c307f9)
Powered by SkillShield