Security teams should inspect the skill code itself, not just install hooks or package manifests. In MCP tooling, the risky behavior may live in a callable skill that runs later on the developer’s machine. Review scope should include credential-store access, wildcard data collection, and any path that returns results to a remote server or external tool channel.
Why This Matters for Security Teams
MCP packages that ship browser-testing skills are not just installer artifacts. They can include callable logic that later runs inside a developer environment with access to browser state, local files, sessions, and sometimes credential stores. That makes code review the security control, not package trust alone. Security teams should treat these skills as executable automation with real reach, especially when they can exfiltrate results through a remote server or another tool channel. NHIMG research on the AI Agents: The New Attack Surface report shows why this matters: 80% of organisations say their AI agents have already acted beyond intended scope.
The practical risk is that a benign-looking browser test helper can become a data collection pipeline, a secret harvester, or a relay for sensitive page content. That is why the review must focus on the skill body, its execution triggers, and any code that reads from browser storage, local paths, environment variables, or developer tokens. Current guidance suggests aligning this review with agentic application controls in the OWASP Agentic AI Top 10 and with the access control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams encounter the abuse only after a developer machine has already exported data the package was never meant to touch.
How It Works in Practice
Reviewing these MCP packages starts with treating the skill as the real payload. Manifest checks can confirm package metadata, but they do not reveal whether the browser-testing routine reads cookies, extracts form values, snapshots pages, or forwards captured output elsewhere. Security reviewers should inspect the callable skill path, its dependencies, and any helper that can access local browser profiles, credential stores, API tokens, or internal dashboards. The operational question is simple: what can this code observe, what can it change, and where can it send the result?
A practical review workflow usually includes:
- Tracing every browser automation entry point, especially scripts that run after install or on user command.
- Searching for data collection patterns such as wildcard scraping, full-page capture, clipboard reads, and profile enumeration.
- Checking for outbound exfiltration paths, including remote HTTP posts, MCP tool responses, telemetry, and log sinks.
- Verifying whether secrets are accessed directly or indirectly through browser session state, local storage, or developer shells.
- Restricting execution to least-privilege environments and separate test profiles whenever possible.
NHIMG analysis of the Analysis of Claude Code Security reinforces a useful lesson: agentic tooling becomes dangerous when the code path is allowed to operate with more context than the review assumed. Pair package inspection with runtime policy review, using browser isolation, per-task credentials, and signed provenance where available. These controls tend to break down when the skill runs in a developer’s default profile because browser state and session tokens are already present.
Common Variations and Edge Cases
Tighter review often increases developer friction, requiring organisations to balance faster adoption against stronger assurance. That tradeoff is especially visible with browser-testing skills, where teams want low-touch setup but still need to control what the skill can read and export. Best practice is evolving, and there is no universal standard for every MCP package that includes automation helpers.
One edge case is a skill that never writes to disk but still leaks data through structured tool output. Another is a package that looks harmless until a test target redirects the browser to a page containing secrets, internal tickets, or admin consoles. A third is a skill that appears local but silently forwards result summaries to a remote service for “analysis.” Security teams should review those output channels as seriously as network calls. The LiteLLM PyPI package breach is a reminder that package trust and runtime trust are not the same thing, and the Cisco DevHub NHI breach shows how quickly third-party access can become exposure when visibility is weak. Review should expand further when packages are allowed in shared developer images, CI runners, or environments with reused browser profiles, because those conditions collapse the boundary between test automation and credential access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Covers tool misuse and unsafe agent actions in browser-testing skills. |
| CSA MAESTRO | M3 | Addresses governance for autonomous tool execution and data movement. |
| NIST AI RMF | GOVERN | Applies governance and accountability to agentic automation in dev environments. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Relevant to secret exposure through packages and local execution contexts. |
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege access review for developer tooling and automation. |
Assign ownership, review scope, and escalation rules for browser skills that can access sensitive data.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities in cloud environments?
- How should security teams handle risks from AI browser extensions?
- How should security teams contain MCP supply chain risk in developer environments?
