Prompt a model connected to the Vault MCP server

This topic provides example prompts for helping you manage HashiCorp Vault after installing the Vault model context protocol (MCP) server. Refer to Deploy the Vault MCP server for instructions on how to deploy the server.

Beta feature

Beta functionality is stable but possibly incomplete and subject to change. We strongly discourage using beta features in production deployments of Vault.

Overview

To trigger the MCP server tools, ask your LLM questions about Vault secrets management, PKI certificate operations, or system administration tasks. The LLM will use the Vault MCP server to perform these operations directly against your Vault instance. Note that for your LLM to use the server, your questions must pertain to specific Vault operations like managing secrets, configuring PKI, or administering mounts.

Requirements

Verify that you have deployed the Vault MCP server and configured your client. Requirements include:

A running HashiCorp Vault instance
Valid Vault authentication token with appropriate permissions
Vault MCP server deployed and accessible
MCP client configured (Claude for Desktop, VS Code, etc.)

Refer to Deploy the Vault MCP server for instructions.

Prompt your MCP client

Your model may still decide to use other resources to formulate responses, but you can use the following guidelines to help you create prompts that are more likely to be routed through the server:

Include specific Vault terminology like "secret engine", "mount path", "PKI role", or "certificate issuance"
Specify exact paths and mount names when working with secrets (e.g., /secret/myapp/config)
Use clear action words like "create", "read", "write", "delete", "list", or "issue"
Mention specific secret engine types like "KV v2", "PKI", or "key-value store"
Reference Vault-specific concepts like TTL, certificate authorities, or namespace

Examples

You can use the following set of prompts as a guide to help you write your own Vault operations. The following responses are returned from the server using ChatGPT 4.1 in GitHub Copilot on VS Code. Your responses may vary.

Manage key-value secrets

In the following example, the server manages secrets in a key-value store:

Prompt

I need to store database credentials for my application. 
Create a secret at secret/myapp/database with username "dbuser" 
and password "secure123"

Server workflow

The server performs the following operations:

Check mount existence: Verifies that the secret/ mount exists
Write secret: Creates the secret with the specified key-value pairs

API calls

{
  "mount": "secret",
  "path": "myapp/database", 
  "key": "username",
  "value": "dbuser"
}

{
  "mount": "secret", 
  "path": "myapp/database",
  "key": "password", 
  "value": "secure123"
}

Sample response

Successfully stored database credentials in Vault:

**Secret Path**: `secret/myapp/database`
**Keys Stored**: 
- username: dbuser
- password: [hidden]

The secret has been written to your Vault KV v2 store. You can retrieve 
these credentials using the path `secret/myapp/database` in your application 
or by reading the secret directly from Vault.

**Security Note**: Ensure your application has appropriate Vault policies 
to read from this path while following the principle of least privilege.

Set up PKI certificate authority

The following prompt creates a complete PKI infrastructure for SSL/TLS certificates:

I need to set up a PKI certificate authority for my internal 
services. Create a root CA for "example.com" and configure 
a role that can issue certificates for subdomains.

PKI setup workflow

The server performs multiple coordinated operations:

Enable PKI mount: Creates a new PKI secrets engine
Create root issuer: Generates the root certificate authority
Create PKI role: Configures certificate issuance policies
Issue certificate: Generates a certificate for validation

PKI API sequence

{
  "path": "pki_root",
  "description": "Root CA for example.com internal services",
  "max_ttl": "87600h"
}

{
  "mount": "pki_root",
  "type": "internal", 
  "common_name": "example.com Root CA",
  "issuer_name": "example-root-ca",
  "ttl": "87600h"
}

{
  "mount": "pki_root",
  "role_name": "subdomain-role",
  "allowed_domains": "example.com",
  "allow_subdomains": true,
  "allow_bare_domains": false,
  "max_ttl": "8760h"
}

PKI setup response

Successfully configured PKI infrastructure for example.com:

## Root Certificate Authority
- **Mount Path**: `pki_root/`
- **Issuer Name**: `example-root-ca` 
- **Common Name**: `example.com Root CA`
- **Validity Period**: 10 years (87600h)

## Certificate Role Configuration
- **Role Name**: `subdomain-role`
- **Allowed Domains**: `example.com`
- **Subdomain Support**: ✅ Enabled
- **Max Certificate TTL**: 1 year (8760h)
- **Usage Flags**: Server & Client Authentication

## Next Steps
You can now issue certificates using:
vault write pki_root/issue/subdomain-role \
  common_name="api.example.com" \
  ttl="720h"

## Certificate Validation
The PKI infrastructure is ready to issue certificates for:
- `*.example.com` (subdomains)
- Custom TTL up to 1 year
- Both server and client authentication use cases

List and audit secrets

The following prompt performs security auditing across Vault:

I need to audit all secrets in my Vault. Show me what 
mounts exist and list the secrets in the main KV store.

Audit workflow

List all mounts: Discovers available secrets engines
List secrets in KV: Enumerates stored secrets
Security analysis: Provides audit recommendations

Audit API calls

{}

{
  "mount": "secret", 
  "path": ""
}

Audit response

# Vault Security Audit Report

## Available Mounts
| Mount Path | Type     | Description               |
|------------|----------|---------------------------|
| `secret/`. | kv-v2    | Key-Value secrets engine  |
| `pki_root/`| pki.     | PKI Certificate Authority |
| `sys/`     | system   | Vault system backend.     |
| `identity/`| identity | Identity secrets engine   |

## Secrets Inventory (secret/ mount)
secret/
├── myapp/
│   ├── database
│   ├── api-keys  
│   └── certificates
├── shared/
│   └── service-accounts
└── infrastructure/
    ├── monitoring
    └── backup-configs

## Security Recommendations
- **Access Review**: Verify policies for each secret path
- **Rotation Schedule**: Implement regular secret rotation
- **Audit Logging**: Enable detailed audit logs for compliance
- **Least Privilege**: Ensure applications have minimal required access

**Total Secrets Found**: 7 secret paths across 3 applications
**Mount Health**: All mounts operational ✅

Issue SSL certificates for applications

The following prompt demonstrates certificate lifecycle management:

Issue an SSL certificate for my web application at 
"api.internal.example.com" valid for 30 days using 
the existing PKI role.

Certificate issuance workflow

Validate role: Confirms the PKI role exists and policies
Issue certificate: Generates new SSL certificate
Return artifacts: Provides certificate, private key, and chain

Certificate API call

{
  "mount": "pki_root",
  "role_name": "subdomain-role", 
  "common_name": "api.internal.example.com",
  "ttl": "720h",
  "format": "pem"
}

Certificate response

Successfully issued SSL certificate for api.internal.example.com:

## Certificate Details
- **Common Name**: `api.internal.example.com`
- **Serial Number**: `39:d4:f7:2c:8a:1b:5e:9f`
- **Validity Period**: 30 days (720h)
- **Key Algorithm**: RSA 2048-bit
- **Signature**: SHA256-RSA

## Certificate Files
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAOT7Wq...
[Certificate content]
-----END CERTIFICATE-----

## Private Key  
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQ...
[Private key content - handle securely]  
-----END PRIVATE KEY-----

## Certificate Chain
-----BEGIN CERTIFICATE-----
[Intermediate CA certificate]
-----END CERTIFICATE-----

## Installation Instructions
1. Save certificate to: `/etc/ssl/certs/api.internal.example.com.crt`
2. Save private key to: `/etc/ssl/private/api.internal.example.com.key` 
3. Set secure permissions: `chmod 600 /etc/ssl/private/*.key`
4. Update web server configuration to use new certificate
5. Restart web server to apply changes

**Security**: Store private key securely and never share it. 
Certificate expires in 30 days - set up renewal automation.

Delete and cleanup secrets

The following prompt demonstrates secure cleanup operations:

I need to clean up old secrets. Delete the database 
credentials from secret/legacy/old-app and remove 
the entire legacy mount if it's empty.

Cleanup workflow

Delete specific secret: Removes the targeted secret path
List remaining secrets: Checks if mount is empty
Conditional cleanup: Removes mount if no secrets remain

Cleanup API calls

{
  "mount": "secret",
  "path": "legacy/old-app"
}

{
  "mount": "secret", 
  "path": "legacy/"
}

Cleanup response

Cleanup operations completed successfully:

## Deleted Resources
- ✅ **Secret Removed**: `secret/legacy/old-app`
  - All versions and metadata permanently deleted
  - Secret contained 3 keys (username, password, connection_string)

## Mount Analysis  
- **Path**: `secret/legacy/`
- **Status**: Empty (no remaining secrets)
- **Recommendation**: Mount can be safely removed if no longer needed

## Security Notes
- **Audit Trail**: Deletion logged in Vault audit logs
- **Recovery**: No recovery possible - ensure backups if needed
- **Access Policies**: Review and clean up associated Vault policies

Would you like me to remove the empty legacy path structure 
or keep it for future use?

Best practices for Vault MCP prompts

Effective prompt structure

Be Specific: Use exact mount paths and secret names
Include Context: Mention the purpose (app credentials, certificates, etc.)
Specify Requirements: TTL values, certificate parameters, security policies
Request Validation: Ask for confirmation of operations before execution

Security considerations

Principle of Least Privilege: Request minimal necessary permissions
Audit Trail: Ensure operations are logged and traceable
Secret Lifecycle: Consider rotation, expiration, and cleanup
Access Patterns: Design secrets structure for application access patterns

Common use cases

Application Secrets: Database credentials, API keys, service tokens
PKI Management: Certificate authorities, SSL certificates, key rotation
Infrastructure Automation: Terraform secrets, CI/CD credentials
Compliance: Audit trails, access reviews, secret inventory