BrowserStack MCP server - FAQs

The BrowserStack MCP server exposes a rich set of tools that allow AI agents, like co-pilots, to manage and execute tests or other actions on the BrowserStack Test Platform using natural language commands directly from your IDE.

It’s important to note that prompts are entered in your AI assistant (e.g., GitHub Copilot), not in the MCP server. The LLM within your AI assistant interprets the prompt, identifies the appropriate MCP tool to invoke, and converts your command into a valid input for the MCP tool call.

Yes. MCP servers are LLM-agnostic. The BrowserStack MCP server is designed to be compatible with various AI tools and Large Language Models (LLMs) that support the open Model Context Protocol.

No. The MCP server does not send any information to an LLM except for usage data related to BrowserStack AI agents. No customer data is ever used for training.

The MCP server simply acts as a secure bridge between your AI assistant and BrowserStack’s capabilities. When you enter a prompt, your AI assistant processes it, determines which MCP tool to invoke, and prepares the required input parameters. The MCP server is activated only when the tool is called, and it then handles the communication and actions on the BrowserStack Test Platform via secure API calls.

No Personally Identifiable Information (PII) or user prompts are stored or used when interacting with the MCP server on BrowserStack’s end. Only minimal details necessary for functionality—such as user ID, group ID, and timestamp—are stored in logs related to MCP tool calls. This data is never used for training.

BrowserStack is SOC 2 Type 2 compliant, which means it has been independently audited for security, availability, and confidentiality. The platform utilizes multiple layers of security to protect data:

• Data Destruction: Remote mobile and desktop browsers are wiped of all browsing data, caches, and passwords after every session. Real devices are restored to factory settings.
• Pristine Machines: Every test runs on a fresh, tamper-proof virtual machine or real device that is isolated from other sessions.
• Encryption: Data is encrypted both at rest and in transit.

Yes. BrowserStack’s SOC 2 compliance and security audits cover the monitoring of unusual system activity and user access levels to mitigate insider threats. While specific details on internal data classification and tagging are not publicly available, the overall security posture is designed to prevent unauthorized data access and movement.

The MCP server uses standard authentication methods integrated with each user’s BrowserStack account credentials. Role-based access can be managed centrally from your organization’s admin dashboard.

• Local MCP Server: This setup uses your BrowserStack username and access key, which should be configured as environment variables.
• Remote MCP Server: This setup uses OAuth, which securely delegates authentication to BrowserStack without needing to pass credentials directly.

This approach ensures the principle of least privilege by granting access based on the user’s existing BrowserStack permissions.

Both Local and Remote MCP servers authenticate directly against BrowserStack’s authentication system, but the mechanism differs:

• Local MCP Server: Uses your BrowserStack username and access key for API key-based authentication. Credentials can be provided as environment variables (recommended) or stored in the MCP config file.
• Remote MCP Server: Uses OAuth to authenticate securely with BrowserStack’s system. This standards-based approach eliminates manual credential handling and reduces the risk of exposure.

In both cases, authentication is managed centrally by BrowserStack and inherits its enterprise-grade security policies, including SOC 2 Type II compliance and encryption of data in transit.

Access is tied directly to the user’s existing BrowserStack account permissions. The MCP server can only perform actions that the authenticated user is already authorized to perform within the platform, ensuring a least-privilege model.

This is not applicable to the MCP server because BrowserStack tools do not get access to user prompts in their current state. Instead, the AI assistant (e.g., Copilot) interprets the user’s prompt and converts it into a structured MCP tool call with strict input/output validation. Only valid input parameters defined for an MCP tool are accepted, ensuring strong protection against malformed inputs or prompt injection attempts.

Injection attacks are not applicable in the MCP server architecture because users interact with their AI assistant first. The assistant interprets the natural language prompt, selects the appropriate MCP tool, and generates a structured input.

The MCP server then:

• Accepts only schema-bound tool inputs.
• Rejects any malformed input.
• Relies on BrowserStack APIs, which enforce their own strict validation.

This design ensures that only secure, validated API calls are executed.

BrowserStack has undergone rigorous security reviews and is SOC 2 Type 2 compliant. This certification, along with active bug bounty and vulnerability disclosure programs, demonstrates a strong commitment to security.

Yes. As part of its SOC 2 compliance and security policies, BrowserStack monitors for unusual system activity and logs user access and interactions for audit trails. Additionally, all MCP tool call interactions in a session are logged. We do not log or access the prompts users type into their AI assistant; only the resulting MCP tool calls are logged.

Yes. BrowserStack’s security policies apply to test history and log data, which are stored in a secure, encrypted database. Access to these logs is highly restricted and requires a highly encrypted access mechanism.

Yes. No data is stored at rest on the client side. All data in transit between the MCP server and BrowserStack is encrypted using HTTPS with TLS v1.2 or higher.

Yes. BrowserStack mandates the use of HTTPS/TLS for all communication. This is a core part of its security policy to ensure data integrity and privacy.

The MCP server returns structured error codes and messages from BrowserStack’s APIs. Failures, such as invalid input, authentication errors, or network timeouts, are gracefully surfaced back to the AI assistant for user visibility.

No known vulnerabilities exist at this time. The MCP server runs locally on the user’s system and communicates exclusively through BrowserStack’s secure APIs, which significantly reduces the potential attack surface.

If you prefer not to store credentials locally in plain text, you have a few options:

• Use the Remote MCP Server: This option doesn’t require storing credentials locally at all. It uses OAuth for secure authentication.
• Use a Secret Manager or Vault: You can securely store your credentials in a vault (e.g., Azure Key Vault, 1Password) and have your IDE fetch them as needed. The credentials can then be passed securely to your MCP configuration.

BrowserStack access keys do not expire by default, but you can rotate them at any time. You can reset your access key from your BrowserStack account settings to comply with your organization’s internal key rotation policies. For more details, see Manage Access Keys.