MCP Governance Least Privilege: A Reference Design 2026

The LPML Governance Rubric

Use this rubric to assess how well any existing or planned MCP deployment satisfies least-privilege governance. Score each dimension from 0 (none) to 3 (fully implemented). A total score of 21 out of 24 is the LPML baseline target; anything below 14 is a high-risk configuration.

Dimension	0 — None	1 — Partial	2 — Adequate	3 — Full
Tool Inventory	No list of registered tools	Ad-hoc list, not versioned	Versioned list, no scopes	Versioned list with explicit scopes per tool
Default Posture	Allow-all (any tool callable)	Block-list (some tools blocked)	Allow-list with gaps	Deny-by-default; tools absent from list are blocked
Scope Granularity	No scopes; all tools equal	Binary read/write only	READ/WRITE/EXECUTE/NETWORK defined	Full 5-scope vocabulary with constraint fields per tool
Audit Coverage	No audit trail	Post-execution logs only	Pre+post records, no hash	Pre+post with input/output hashes and trace ID
Audit Integrity	Mutable logs	Append-only sink	Append-only + offsite copy	Append-only + hash chain + Object Lock or equivalent
Rollback Coverage	No rollback hooks	Some tools have hooks, unclassified	All tools classified (R/P/I), some hooks missing	All tools classified; REVERSIBLE and PARTIAL have tested hooks; IRREVERSIBLE require ESCALATE
Human-in-Loop	No escalation path	Ad-hoc manual interruption	ESCALATE scope defined; no tooling	ESCALATE scope triggers structured approval flow with timeout and default action
Session Isolation	All sessions share the same context	Sessions have IDs but share scopes	Sessions have independent scope floors	Sessions have scope floors, call-rate limits, and anomaly detection per session

Interpreting Your Score

Scores 0-7: The deployment has essentially no governance layer. Every tool call is a trust decision made entirely by the model. An adversarial prompt, a confused agent loop, or a simple model error can cause side effects with no audit trail and no recovery path. Fix Tool Inventory and Default Posture first — those two dimensions eliminate the worst-case scenarios at lowest implementation cost.

Scores 8-14: You have some controls but significant gaps. The most dangerous gap at this tier is usually Rollback Coverage — if WRITE-scoped tools have no rollback hooks, a bad session is permanently destructive. Audit Integrity is the second priority.

Scores 15-20: Good baseline. The remaining gaps are typically Scope Granularity (constraint fields not defined per tool) and Session Isolation (call-rate limits missing). These are operational hardening, not architectural gaps.

Score 21-24: LPML baseline reached. The next investment is in anomaly detection — statistical models over the audit trail that flag sessions with unusual call patterns before they complete, rather than after.

Implementation Pattern: The Governance Wrapper

The governance layer is a wrapper, not a rewrite. You do not modify the MCP tool handlers themselves. Instead, you insert the governance layer between the protocol dispatch and the handler invocation. In TypeScript, the pattern looks like this in pseudocode (using plain text to avoid backtick issues):

// Governance wrapper — inserts between MCP dispatch and tool handler
async function governedDispatch(
  toolName: string,
  input: unknown,
  sessionCtx: SessionContext,
  toolRegistry: AllowList,
  auditSink: AuditSink,
  rollbackRegistry: RollbackRegistry
): Promise<ToolResult> {

  // 1. Check tool is in allow-list
  const toolConfig = toolRegistry.get(toolName);
  if (!toolConfig) {
    await auditSink.writeBlock(toolName, sessionCtx, input, 'BLOCKED_NOT_IN_ALLOWLIST');
    throw new GovernanceError('TOOL_NOT_ALLOWED', toolName);
  }

  // 2. Resolve scopes for this call
  const resolution = scopeResolver.resolve(toolConfig, input, sessionCtx);

  // 3. Write pre-record
  const traceId = crypto.randomUUID();
  await auditSink.writePre({
    traceId,
    sessionId: sessionCtx.id,
    toolName,
    resolvedScopes: resolution.scopes,
    disposition: resolution.disposition,
    inputHash: sha256(JSON.stringify(input)),
    inputSummary: JSON.stringify(input).slice(0, 256),
    tsPre: new Date().toISOString(),
  });

  // 4. Handle escalation
  if (resolution.disposition === 'ESCALATE') {
    await escalationFlow.request(traceId, toolName, input, sessionCtx);
    // escalationFlow.request resolves when approved or throws on denial/timeout
  }

  // 5. Execute tool
  const tsStart = Date.now();
  let outcome: ToolOutcome;
  let result: ToolResult;
  try {
    result = await toolRegistry.getHandler(toolName)(input);
    outcome = { status: 'SUCCESS', error: null };
  } catch (err) {
    outcome = { status: 'ERROR', error: errorCode(err) };
    result = null;
  }

  // 6. Register rollback artifact if REVERSIBLE
  let rollbackId: string | null = null;
  const rollbackStatus = rollbackRegistry.statusFor(toolName);
  if (rollbackStatus === 'REVERSIBLE' && outcome.status === 'SUCCESS') {
    rollbackId = await rollbackRegistry.saveArtifact(toolName, input, result, traceId);
  }

  // 7. Write post-record
  await auditSink.writePost({
    traceId,
    outcome: outcome.status,
    errorCode: outcome.error,
    outputHash: result ? sha256(JSON.stringify(result)) : null,
    durationMs: Date.now() - tsStart,
    tsPost: new Date().toISOString(),
    rollbackId,
  });

  if (outcome.status !== 'SUCCESS') throw new ToolExecutionError(outcome.error);
  return result;
}

Three things to notice. First, the pre-record is written before the tool executes — if the process crashes between pre and post, the missing post-record is the audit signal. Second, the rollback artifact is saved only on SUCCESS; a failed WRITE does not create a rollback artifact because there is nothing to reverse. Third, the entire governance overhead (list lookup, scope resolution, two audit writes) adds roughly 3-8ms per call depending on audit sink latency — acceptable for any non-streaming tool call.

Handling ESCALATE Tools in Practice

ESCALATE is the scope that trips up most teams when they first implement LPML. The naive implementation blocks execution entirely until a human approves, which works for low-frequency high-stakes operations (production deploys, bulk data deletes) but breaks conversational agent flows where the user expects continuous progress.

Two patterns work well:

Synchronous approval with timeout and default: The governance layer sends an approval request (webhook, Slack message, email) with a configurable timeout (recommend 5 minutes). If no response arrives before the timeout, apply a configured default action: ALLOW (optimistic) or BLOCK (conservative). Log the default-action trigger as a distinct audit event. Use ALLOW defaults only for tools with REVERSIBLE rollback status; use BLOCK defaults for PARTIAL or IRREVERSIBLE tools.

Deferred execution queue: Instead of blocking the agent, move the ESCALATE call to a named queue and return a pending-token to the model. The agent continues other work. When the human approves, the queued call executes and its result is injected back into the agent’s next context. This is more complex to implement but eliminates user-visible latency for approval flows. It requires the agent to understand that some tool results are deferred — which is achievable via system prompt instruction.

Either way, the approval UI needs to show the input_summary from the pre-audit record, not just the tool name. “Approve: write_file” is not useful. “Approve: write_file to /workspace/outputs/config/database.json (1.2KB, overwrites existing file)” is actionable.

Connecting LPML to the Broader MCP Ecosystem

As of June 2026, the MCP specification (spec.modelcontextprotocol.io) includes a capabilities object in the server manifest, but it describes what the server supports (tools, resources, prompts) rather than per-tool authorization scopes. The LPML allow-list is a governance overlay that sits on top of — and does not conflict with — the canonical MCP capabilities declaration.

If you are running multiple MCP servers in a single agent setup (common with Claude Code, Continue.dev, or custom orchestration), each server gets its own allow-list. The session context that flows through the scope resolver includes the server identity, so you can define different scope floors for the filesystem MCP server versus the database MCP server within the same agent session.

For teams using the Anthropic Python SDK or TypeScript SDK with tool-use, the governed dispatch function wraps the tool execution callbacks passed to client.beta.tools.messages.create or the equivalent streaming API. The MCP server itself does not need modification; the governance wrapper handles everything at the dispatch layer.

Check the WOWHOW tools directory for MCP-compatible developer utilities, and the product catalog for full agentic workflow starter kits that include governance scaffolding. If you are building audit trail infrastructure, the Pro Vault tier includes TypeScript templates for append-only log sinks with hash-chain support.

Common Mistakes When Rolling Out LPML

Starting with scopes too broad. Teams often create READ and WRITE as the only two scopes, then wonder why the governance layer does not prevent a “read” tool from making network calls. The full 5-scope vocabulary exists because EXECUTE and NETWORK are qualitatively different risk categories from READ and WRITE. Define all five from day one, even if most tools only use one or two.

Not testing rollback hooks before enabling REVERSIBLE status. A rollback hook that has never been executed in a test environment is a liability, not an asset. The audit trail will show rollback_id for every successful WRITE call, and an operator will trust those records during an incident. If the hook does not actually work, the trust is false. Test rollback hooks in a staging environment, log the test run in the audit trail under a dedicated test session, and only promote a tool to REVERSIBLE status after a successful staged rollback.

Treating the allow-list as code rather than configuration. If the allow-list lives in the same file as the tool handlers and requires a deployment to change, your incident response time is measured in deployment cycles. Keep the allow-list in a hot-reloadable config artifact. When an anomaly is detected, blocking a tool by setting blocked: true in the allow-list should take effect within seconds, not minutes.

Ignoring call-rate limits until they are needed. The call-history escalation rule (rate-limit WRITE tools after N calls per window) is the most effective defense against runaway agent loops. It is also the easiest to skip during initial implementation because “no agent has ever looped like that in our tests.” Production agents encounter edge cases that test agents do not. Wire the rate-limit rule before going to production, even with a generous default (50 calls per hour is still a meaningful bound).

Governance Rubric in Action: A Worked Example

Consider a code-review agent that has access to four tools: read_file, write_comment, run_tests, and push_to_branch. Scoring each against the LPML rubric:

Tool	Scopes	Rollback Status	Constraint Fields	Requires ESCALATE
read_file	READ	N/A (no side effects)	path_constraint: ^/repo/, max_bytes: 2MB	No
write_comment	READ, WRITE, NETWORK	REVERSIBLE (delete API available)	domain_allowlist: api.github.com	No (comment is reversible)
run_tests	EXECUTE	PARTIAL (test output may modify coverage files)	command_allowlist: npm test, pytest, timeout: 300s	No (read-only intent, bounded EXECUTE)
push_to_branch	READ, WRITE, NETWORK, ESCALATE	PARTIAL (can revert commit, cannot un-trigger CI)	branch_constraint: ^review/ (never main)	Yes (branch push, PARTIAL rollback)

This configuration scores 22 out of 24 on the LPML rubric. The two points missing are in Audit Integrity (hash-chain not yet implemented) and Session Isolation (call-rate limits not set for run_tests). Both are next-sprint items, not blockers for shipping the governance layer.

The most important decision in this table: push_to_branch requires ESCALATE. The agent cannot push to any branch without human confirmation. The branch constraint (^review/) is a defense-in-depth measure — even if ESCALATE somehow fails, the tool cannot push to main. Two independent controls for the highest-risk operation in the set.

Anomaly Detection as the Next Layer

LPML as described is a static-plus-dynamic controls framework. It does not include statistical anomaly detection over the audit trail — that is deliberately left as a separate concern. But the audit schema was designed with anomaly detection in mind. Every record includes session_id, tool_name, duration_ms, and ts_pre, which gives you the minimum fields for basic statistical profiling: call frequency per tool per session, average duration drift, and unexpected tool sequencing.

A simple anomaly rule that pays dividends: flag any session where write_file is called more than 3 times within 30 seconds of read_file being called on a file path matching .*credentials.* or .*.env$. That sequence — reading a credentials file then writing multiple files rapidly — is not a pattern any legitimate code-review agent produces. It is, however, exactly what a prompt-injected agent might produce if it is executing exfiltration logic. The audit trail makes that pattern detectable in near-real-time.

Wire your anomaly rules to the ESCALATE flow, not to an alert-and-ignore system. When an anomaly fires, the session should pause and route to human review, exactly as a high-risk tool call does. The governance layer you built for ESCALATE tools handles anomaly-triggered pauses with no additional infrastructure.

Your governance layer is only as strong as the assumptions baked into your allow-list. Review and update it every time you add a new tool, change a tool’s implementation, or observe an unexpected call pattern in the audit trail. The allow-list is a living document, not a one-time setup.

People Also Ask

What is the LPML least-privilege MCP governance layer?

LPML (Least-Privilege MCP Layer) is an architectural pattern that wraps MCP tool dispatch with four controls: a static allow-list that blocks tools absent from the list, a per-call scope resolver that narrows permissions at runtime, a tamper-evident pre/post audit trail keyed on SHA-256 hashes, and rollback hooks classified as REVERSIBLE, PARTIAL, or IRREVERSIBLE. No changes to tool handlers are required.

How do you implement a deny-by-default MCP allow-list?

Define a versioned JSON or YAML file listing every permitted tool by name with its capability scopes (READ, WRITE, EXECUTE, NETWORK, ESCALATE). Any tool name absent from the file is blocked at the governance wrapper before the MCP server sees the request. Set blocked: true on tools that are declared but not yet enabled, so the governance record stays complete during review cycles.

What is ESCALATE scope in MCP governance and when should you require it?

ESCALATE is a scope that requires human approval before a tool call executes. Require it on any WRITE-scoped or EXECUTE-scoped tool whose rollback status is IRREVERSIBLE or PARTIAL — meaning the side effect cannot be fully undone. Production deployments, bulk data deletes, and branch pushes to protected refs are the common cases. The approval UI must show the full input_summary, not just the tool name.

How does the LPML audit trail detect tampering or incomplete operations?

Each tool call writes a pre-record (with input_hash, resolved scopes, and disposition) before execution and a post-record (with output_hash and duration_ms) after. Both share a trace_id. A missing post-record for any pre-record is itself the tamper signal — it means the process crashed or was interrupted mid-call. Hash-chaining each entry’s hash as the next entry’s prev_hash detects insertion or deletion.

What governance score indicates a high-risk MCP deployment?

The LPML rubric scores eight dimensions (Tool Inventory, Default Posture, Scope Granularity, Audit Coverage, Audit Integrity, Rollback Coverage, Human-in-Loop, Session Isolation) from 0 to 3 each, for a 24-point maximum. A total below 14 is high-risk: it means at least one of Default Posture or Audit Coverage is at zero, leaving WRITE-scoped tool calls with no independent record and no recovery path. Fix those two dimensions first before addressing the others.