Hard20 minAI Engineering
UpdatedAug 6, 2026
Edit

MCP: Tool Permission Boundaries

Question Variations

  • "Why is an MCP tool description not an authorization boundary?"
  • "Which actions require human confirmation?"
  • "Design MCP tools for customer-data access and refunds so prompt compromise cannot issue an unsafe refund."

Why This Is Asked

This tests whether a candidate distinguishes an LLM’s tool selection from actual authority. Interviewers assess least-privilege tool design, server-side authorization, confirmation for consequential actions, and auditability.

Key Concepts

  • Least privilege: Expose narrow tools with scoped credentials.
  • Authorization: Enforce identity and policy at the tool server, not in model instructions.
  • Confirmation: Require user approval for consequential actions.
  • Audit: Log inputs, actor, policy decision, and result without exposing secrets.

Question Variations

  • “Why is an MCP tool description not an authorization boundary?”
  • “Which actions require human confirmation?”
  • “Design MCP tools for customer-data access and refunds so prompt compromise cannot issue an unsafe refund.”

Answers by Technology

+ Add Variant
System DesignImprove this answer ✏️

Expected Answer

I would design MCP tools as narrow capabilities, not a general API wrapper. The server authenticates the user, authorizes every argument, and uses scoped credentials; the model only proposes a call. Reads are filtered to the caller’s scope, while refunds require explicit confirmation, amount limits, and an audit record. Tool descriptions aid selection but never grant permission.

Why It Matters

Prompt compromise must not become account compromise.

Common Mistakes

  • Trusting model instructions: They are not access control.
  • Using broad service tokens: One tool call gains excessive power.

Follow-up Questions

  • What needs confirmation? (Answer: Consequential external actions.)
  • Where is policy enforced? (Answer: At the tool server.)