Gene Library Courses Download Pricing Contact Sign in
cyberark-secrets-manager logo
security Official Website

CyberArk Secrets Manager MCP – Secure Secret Access

CyberArk Secrets Manager MCP server gives MCP-compatible AI tools controlled access to CyberArk Secrets Manager data. It is designed for development workflows where an agent helps find hard-coded secrets, create secrets and workloads, grant workload access, and generate code for retrieving secrets securely.

#secrets-management#identity#devsecops

Overview

CyberArk Secrets Manager MCP server is the CyberArk-documented Model Context Protocol server for connecting MCP-compatible clients, such as VS Code Copilot, Cursor, and Claude Code, to CyberArk Secrets Manager. It gives AI models a structured way to read and update Secrets Manager data during development workflows.

The server is intended for developer assistance rather than autonomous production access. CyberArk documents it for development environments only and explicitly states that it should not be used in production. A typical use case is scanning source code for hard-coded secrets, creating corresponding Secrets Manager secrets, creating workloads, granting workload access, and producing SDK or curl examples for retrieving those secrets.

What the MCP server enables

The server exposes tools for the authentication flow and Secrets Manager operations. Documented commands include get_auth_url, authenticate, create_branch, list_secrets, create_secret, create_workload, grant_secret_permission, list_hosts, list_all_resources, whoami, and generate_fetch_code.

These tools let an AI assistant help developers migrate hard-coded secrets into CyberArk Secrets Manager, create Secrets Manager branches and variables, create workloads, grant read or execute permissions to workloads, and generate code examples in Ruby, Go, Java, or curl. Access is limited by the authenticated Secrets Manager user's permissions.

When to use it

Use this MCP server when a developer wants an AI assistant to help remove hard-coded secrets from a codebase and replace them with calls to CyberArk Secrets Manager. It is also useful for exploring which secrets, workloads, and resources a dedicated development user can access, or for generating starter code that retrieves a secret from CyberArk-managed storage.

Connection and authentication

CyberArk documents a Docker-based stdio setup. The MCP server package is downloaded from CyberArk Marketplace, loaded into Docker with docker load, and run as a local container connected to the AI tool. Required configuration includes CONJUR_API_URL, OAUTH_APPLICATION_ID, OAUTH_CLIENT_ID, OAUTH_ISSUER_URI, and OAUTH_REDIRECT_URI. The redirect URI must be http://localhost:8080/callback, and port 8080 must be mapped for the authentication flow.

Authentication uses an Idira Identity OAuth2 client and service account plus a dedicated Secrets Manager user account. CyberArk recommends creating a least-privileged dedicated user so audit trails are clear and permissions are limited to specific branches.

Key considerations

The server uses the authenticated user's full permissions. It does not create a separate permission boundary between the AI agent and that user, so the AI agent can access secrets and credentials available to the account. Use a dedicated least-privileged account, avoid admin accounts, review AI-generated changes before applying them, and keep this integration restricted to development environments.

Supported Transports

stdio

Command: docker

Args:

  • run
  • --rm
  • -i
  • -p
  • 8080:8080
  • -e
  • CONJUR_API_URL=${CONJUR_API_URL}
  • -e
  • OAUTH_APPLICATION_ID=${OAUTH_APPLICATION_ID}
  • -e
  • OAUTH_CLIENT_ID=${OAUTH_CLIENT_ID}
  • -e
  • OAUTH_ISSUER_URI=${OAUTH_ISSUER_URI}
  • -e
  • OAUTH_REDIRECT_URI=http://localhost:8080/callback
  • localhost/cyberark/mcp-server:0.1.0-beta

Frequently Asked Questions

When should an AI agent use CyberArk Secrets Manager MCP server?
Use it in development when an AI assistant needs to help identify hard-coded secrets, create corresponding CyberArk Secrets Manager secrets, create workloads, grant workload access, and generate code for retrieving secrets securely. CyberArk documents the server for development environments only and does not support using it in production.
What does this MCP server add to an AI agent's capabilities?
It gives the agent live tool access to CyberArk Secrets Manager operations through MCP. The agent can start OAuth authentication, list accessible secrets and workloads, create branches and secrets, create workloads, grant workload permissions, show the authenticated user, and generate secret-fetching code examples.
What can the AI agent access or manage through this server?
The agent can access Secrets Manager data and resources available to the authenticated dedicated user. Documented tools include listing secrets and hosts, creating branches, creating secrets, creating workloads, granting read or execute permissions to workloads, listing all accessible resources, and generating Ruby, Go, Java, or curl code for fetching secrets.
How is authentication configured for this MCP server?
Authentication requires an Idira Identity OAuth2 client, a service account, and a dedicated CyberArk Secrets Manager user. The Docker container is configured with the tenant API URL, OAuth application ID, OAuth client ID, OAuth issuer URI, and the fixed redirect URI `http://localhost:8080/callback`. The AI user starts the flow with `get_auth_url` and completes it with `authenticate` or `done`.
Which transport should be used for this MCP server?
Use the documented local stdio transport through Docker. CyberArk's examples configure MCP clients to run a Docker container with `--rm`, `-i`, port `8080:8080`, and the required OAuth and Secrets Manager environment variables. No hosted Streamable HTTP or SSE endpoint is documented for this server.