MCP principles

The Model Context Protocol is how agents reach real systems. It is also the largest attack surface in an AI-first stack. Three non-negotiables.

The three primitives

PrimitiveWhat it isRisk
ResourcesRead-only data the agent pulls.Low; data exposure.
ToolsExecutable actions with side effects.High; can mutate state.
PromptsReusable templates the host renders.None directly; can leak via injection.

Resources are what the agent sees. Tools are what the agent does.

1. Least-privilege binding

The agent has exactly the permissions its current task needs.

  • Read-only and mutation servers are physically separate.
  • Credentials scoped to the smallest possible role.
  • No "god" servers. A single MCP server wrapping a full AWS account is not a tool, it is a vulnerability.

2. Human-in-the-loop for high-stakes actions

Destructive or production-affecting actions require explicit human approval through a consent UI. Categories that always need HITL:

  • Production deploys.
  • Database migrations and DELETE-class queries.
  • Anything touching money.
  • External communication (email, SMS, non-internal Slack).
  • PII column access.

The MCP server encodes this with requiresConfirmation: true. Never rely on the prompt to remember to ask.

3. Centralised auditing

Every invocation logged: identity, parameters, response, timestamp, duration. Real-time queryable by security. Alert on:

  • Tools invoked outside normal hours.
  • Parameters matching sensitive patterns.
  • Failure spikes suggesting probing.
  • New tool combinations the agent has not used before.

Four-tier layout

  1. Tier 1 · Context. Read-only, low-risk. Repo search, docs, dashboards. Attached by default.
  2. Tier 2 · Internal write. Create tickets, update wiki, internal Slack. HITL recommended.
  3. Tier 3 · Production read. Strict auditing.
  4. Tier 4 · Production write. Attached only for the specific task. HITL required every invocation.

Tool naming

Verb plus qualifier. The blast radius is visible before reading the description.

  • read_customer_by_id, not get_customer.
  • delete_draft_invoice, not delete_invoice.
  • deploy_to_staging, not deploy.
  • send_test_email, not send_email.

What to do with this

mcp operationalises all of this. It produces the config and the policy. It does not stand up servers for you.