Docs/MCP governance

Govern any MCP server.

Point HiveKey at an MCP server — your CRM, database, or deploy pipeline — and its tools get the same scope, guards, and audit log as everything else. Read-only by default. Writes are turned on per tool, per role, on purpose.

How it works

The agent never talks to your MCP server directly. It calls a namespaced tool on the HiveKey gateway; HiveKey evaluates scope and guards, proxies the call to your upstream server, records the verdict, and returns the result.

Agent

calls crm.read

HiveKey gateway

scope › guard › log

MCP server

your upstream tool

Namespaced

Each server's tools live under a prefix so names never collide across servers.

Sandboxed

Egress is locked down; upstream credentials are encrypted at rest, never exposed to the agent.

Logged

Every proxied call — allow or deny — lands in the same audit trail as native actions.

Register an MCP server

Declare the upstream endpoint and the credential HiveKey should use to reach it. The credential stays in HiveKey's vault — agents never see it.

shell · curl

curl https://api.hivekey.ai/v1/mcp/servers \
  -H "Authorization: Bearer hk_live_…" \
  -d '{"namespace":"crm",
       "endpoint":"https://mcp.internal.acme.com",
       "credential_ref":"vault://acme-crm-key",
       "default_access":"read-only"}'

✓ Discovered 7 tools · namespaced as crm.*

Namespace its tools

HiveKey discovers the server's tools and prefixes them with your namespace. A tool the upstream calls deleteRecord becomes crm.delete — addressable in scope and guards like any native action.

mcp.config.yamlyaml

namespace: crm
default_access: read-only       # writes off until granted
tools:
  crm.read:     { maps: getRecord,  access: read }
  crm.search:   { maps: query,      access: read }
  crm.update:   { maps: putRecord,  access: write }
  crm.delete:   { maps: deleteRecord, access: write }

Per-tool, per-role permissions

Grant each tool to each role independently. The matrix below is how a crm server might be governed across three roles — read is broad, writes are narrow, destructive calls held for review.

Tool	support-agent	ops-agent	intern-agent
crm.read	allow	allow	allow
crm.update	deny	allow	deny
crm.delete	deny	review	deny
deploy.staging	deny	allow	review
deploy.production	deny	review	deny

Read-only defaults

When you register a server with default_access: read-only, every write-classified tool is denied until you explicitly grant it. New tools discovered on a later sync inherit the same safe default.

Response · agent attempts a write403 Forbidden

{
  "action": "crm.delete",
  "verdict": "deny",
  "reason": "tool is write-classified and not
    granted to role 'support-agent'",
  "namespace": "crm",
  "default_access": "read-only",
  "logged": true
}

Safe by construction

A misbehaving or compromised agent can only do what its role grants on your server — and you can prove exactly what it tried.

← Back

API reference

System status

Need help? Talk to our team.