MCP Server

The SikkerKey MCP server connects MCP-compatible AI clients to the SikkerKey management plane. It lets an AI assistant help administer projects, secret metadata, policies, machines, alerts, audit activity, and other vault operations through a dedicated AI-agent identity.

#How it works

The MCP server runs locally as a child process of your AI client and communicates with it over standard input and output. When the AI invokes a SikkerKey tool, the server signs the corresponding SikkerKey API request with the selected AI agent identity.

• Local identity. The AI agent's Ed25519 private key is generated and stored on your computer. Only the public key is registered with SikkerKey.

• Signed requests. Every request covers the HTTP method, path, timestamp, one-time nonce, and request-body hash. A modified or replayed request fails verification.

• Scoped authorization. Management scopes control vault-wide operations. An access role controls the applications, projects, secret types, machine operations, and policy capabilities the agent can reach.

• Live creator bound. The agent's effective access can never exceed the current access of the person who created it. If that person's access is reduced or removed, the agent's permissions shrink on the next request.

• Full attribution. Every successful change is recorded in the Audit Log under the AI agent's identity.

#Requirements

• A SikkerKey vault

• Permission to provision an AI agent in the vault

• An MCP-compatible AI client

• A supported desktop or server platform

The packaged server supports Linux on x64 and arm64, macOS on x64 and Apple silicon, and Windows on x64. It works with any MCP client that can launch a server over stdio.

Clients with generated configuration

• Claude Code

• Claude Desktop

• Cursor

• Codex

#Install the server

Install the command globally with npm:

npm install -g sikkerkey-mcp

You can also run a command without a global installation:

npx sikkerkey-mcp <subcommand>

#Set up an AI agent

Register the identity

sikkerkey-mcp install <bootstrap-token>

Add an optional local display name during registration:

sikkerkey-mcp install <bootstrap-token> -name="Operations assistant"

Registration generates an Ed25519 key pair locally and stores the identity under:

~/.sikkerkey/agents/<agent-id>/

The agent directory, identity file, and private key are created with restricted permissions. The agent remains pending until you approve it from the dashboard.

Generate client configuration

sikkerkey-mcp config claude-code
sikkerkey-mcp config claude-desktop
sikkerkey-mcp config cursor
sikkerkey-mcp config codex

Each command prints a ready-to-paste configuration block and the location used by that client. The generated configuration launches sikkerkey-mcp serve and selects the agent with SIKKERKEY_AGENT_ID.

#Verify the connection

After restarting the AI client, ask it to use whoami. This call is always available and reports:

• The AI agent ID and name

• Approval and enabled status

• Granted management scopes

• The access role and reachable applications and projects

• Per-project capabilities

• The 20 most recent audit entries attributed to the agent

Use whoami at the beginning of a sensitive session or after changing the creator's role, the agent's scopes, or its access role.

#What the tools can manage

You can describe the outcome you want in normal language. The AI client selects the appropriate tool and action, while SikkerKey independently checks the agent's current authorization for every request.

#Management scopes and project access

An AI agent receives two complementary permission sets.

Management scopes

Management scopes control vault-wide areas such as machines, AI agents, enrollment, audit, alerts, webhooks, the IP allowlist, Trash, and support. Read and write scopes can be granted separately where the feature supports them.

Access role

The access role controls the project plane. It decides which applications and standalone projects appear to the agent and what it may do in each project, including permitted secret types, machine attachment and grants, policies, and canaries.

SikkerKey intersects both permission sets with the creating user's current access on every request. The agent cannot use MCP tools to replace its own management scopes or access role.

#How stored secret values are handled

The MCP surface separates secret administration from runtime secret retrieval.

• Metadata reads. Listing a secret, opening its detail, or viewing its version history returns identifiers, names, types, field names, notes, versions, and timestamps—not stored values.

• Create and update. When you deliberately supply a value for creation or replacement, that value passes through the AI client into the signed write request and is encrypted by SikkerKey. The response returns metadata and does not echo the value.

• Server-generated rotation. Rotation and managed-secret creation can generate the new value inside SikkerKey. The AI receives the new version and schedule metadata, not the generated plaintext.

• Runtime retrieval. Applications read secrets through an official SDK or the CLI using a separate machine identity. An AI-agent identity cannot authenticate as a machine.

One-time credentials

Some management actions return newly generated credentials once so you can complete their setup. These include enrollment tokens, a new webhook signing secret, and the token and passphrase for a temporary secret share. Store or deliver them at creation time; later list and detail actions do not reveal them.

A temporary secret share is intended for a human recipient. Opening its link consumes the one-time reveal, so the AI should deliver the share details rather than opening the link.

#Audit, approval, and revocation

SikkerKey records each management action with the AI agent's ID and name. You can review the activity from the dashboard Audit Log or through read_audit. Alert rules and webhooks can notify you when selected agent actions occur.

Your AI client controls its own confirmation prompts before it sends a tool call. Configure that client to require confirmation for changes that deserve human review, particularly permanent deletion, access changes, machine revocation, policy changes, IP allowlist changes, and externally delivered messages.

Disable or revoke an agent

• Disable. Immediately refuses the agent's signed requests while preserving its scopes and access role for later re-enablement.

• Revoke. Deletes the server-side AI-agent identity and makes the local key pair unusable for future requests.

Both take effect on the next request. Manage the server-side lifecycle from the dashboard. After revocation, remove the local identity slot:

sikkerkey-mcp revoke <agent-id>

#Use more than one AI agent

A computer can store several AI-agent identities. List the registered local identities with:

sikkerkey-mcp whoami

Generated client configuration creates a separate server entry for each identity. If you configure the server manually, set SIKKERKEY_AGENT_ID to the exact agent that client should use:

{
  "mcpServers": {
    "sikkerkey": {
      "command": "sikkerkey-mcp",
      "args": ["serve"],
      "env": {
        "SIKKERKEY_AGENT_ID": "agent_..."
      }
    }
  }
}

When exactly one identity is installed, the server selects it automatically. When several exist and no agent ID is configured, startup stops and asks you to choose rather than selecting one implicitly.

#Environment variables

#Command reference

#Source code and license

The SikkerKey MCP server is fully open source under the MIT License. Review the authentication, identity storage, protocol handling, tool schemas, and request behavior through the SikkerKeyOfficial GitHub organization.