MCP à moindre privilège : concevoir des flux d'écriture sûrs pour les équipes
When AI assistants can create, update, and delete your project data, reducing risk is critical. This guide covers patterns and prompt templates that enforce confirmation and minimize accidental changes.
The Least-Privilege Principle
The least-privilege principle states that users (and AI assistants) should have only the minimum permissions necessary to perform their tasks. For MCP integrations, this means:
- Read First: Always read current state before making changes
- Confirm Before Write: Require explicit approval for any write operation
- Preview Changes: Show what will change before executing
- Audit Everything: Log all actions with context
- Limit Scope: Only access what's necessary for the task
Pattern 1: Read-First
Always read the current state before making any changes. This ensures you're working with accurate data and can detect conflicts.
How It Works
- AI calls a read tool first (e.g.,
get_task,list_tasks) - AI analyzes the current state
- AI proposes changes based on actual data
- User reviews the proposal
- Only then does AI call write tools (if approved)
Example: Updating Task Status
❌ Unsafe Prompt:
"Mark the login feature task as done"
✅ Safe Prompt (Read-First):
"Show me the login feature task, then update its status to done if I confirm"
What happens:
- AI calls
list_tasksto find the task - AI calls
get_taskto read current status - AI shows: "Current status: In Progress → New status: Done"
- AI asks for confirmation
- Only calls
update_taskafter approval
Pattern 2: Confirm-Before-Write
Never let AI make changes without explicit confirmation. Use confirmation tokens or explicit approval requests.
Confirmation Token Pattern
Require a specific word or phrase before executing:
- "Type CONFIRM to proceed"
- "Reply YES to create"
- "Say 'create task' to continue"
Prompt Template: Create Task with Confirmation
Copy-Paste Template:
"I want to create a task: [task description].
Show me exactly what task you'll create (title, description, project, due date)
and wait for me to type CONFIRM before creating it.
If I don't type CONFIRM, don't create anything."Prompt Template: Update Task with Confirmation
Copy-Paste Template:
"I want to update the [task name] task: [changes].
First, show me the current task details, then show me what will change.
Only update if I type CONFIRM.
If I don't confirm, don't make any changes."Pattern 3: Dry-Run Previews
Show what would happen without actually making changes. This lets users verify the logic before execution.
Dry-Run Pattern
- AI analyzes the request
- AI determines what tools would be called
- AI shows a preview: "I would create/update/delete..."
- AI explains the reasoning
- User reviews and approves or modifies
- Only then does AI execute
Example: Batch Task Creation
Prompt:
"I have these action items from a meeting: [list]. Create tasks for each, but show me all the tasks you would create first. Don't create anything until I approve the list."
AI Response (Dry-Run):
I would create these 5 tasks:
- Follow up with Acme Corp (Due: next week)
- Review API design doc (Due: tomorrow)
- Update project timeline (Due: Friday)
- Schedule team meeting (Due: this week)
- Prepare demo presentation (Due: next Monday)
Type APPROVE to create these tasks, or tell me what to change.
Pattern 4: Audit-Friendly Comments
When making changes, always add comments that explain why the change was made. This creates an audit trail.
Comment Format
Include context in comments:
- Source: "Created via MCP: Weekly planning workflow"
- Reason: "Updated by AI assistant: Status change requested by user"
- Context: "MCP update: User requested priority change during standup"
Prompt Template: Write with Audit Comment
Copy-Paste Template:
"When you create/update/delete tasks, always add a comment
explaining why. Format: 'MCP: [reason] - [context]'.
For example: 'MCP: Created via weekly planning workflow - User requested follow-up task'."Complete Prompt Templates
Here are ready-to-use prompt templates for common write operations:
Template: Safe Task Creation
"I want to create a task: [description].
Rules:
1. Show me exactly what you'll create (title, description, project, due date, assignee)
2. Wait for me to type CONFIRM before calling create_task
3. If I don't type CONFIRM, don't create anything
4. After creating, add a comment: 'MCP: Created via [workflow name]'"
Example usage:
"I want to create a task: Follow up with Acme Corp about the proposal, due next week.
[Follow the rules above]"Template: Safe Task Update
"I want to update the [task name] task: [changes].
Rules:
1. First, call get_task to read the current task
2. Show me: Current value → New value for each field
3. Wait for me to type CONFIRM before calling update_task
4. If I don't type CONFIRM, don't update anything
5. After updating, add a comment explaining the change"
Example usage:
"I want to update the login feature task: change status to done and add completion notes.
[Follow the rules above]"Template: Safe Task Deletion
"I want to delete the [task name] task.
Rules:
1. First, call get_task to show me the task details
2. Warn me that deletion is permanent
3. Wait for me to type DELETE CONFIRM (both words) before calling delete_task
4. If I don't type DELETE CONFIRM, don't delete anything"
Example usage:
"I want to delete the duplicate task 'Test login'.
[Follow the rules above]"Template: Safe Batch Operations
"I want to [operation] multiple tasks: [list/description].
Rules:
1. First, call list_tasks to find matching tasks
2. Show me the list of tasks that would be affected
3. Show me what changes you would make to each
4. Wait for me to type CONFIRM ALL before making any changes
5. If I don't type CONFIRM ALL, don't make any changes"
Example usage:
"I want to update all tasks in the Q1 project: mark overdue tasks as blocked.
[Follow the rules above]"Examples for Each Write Operation
create_task Example
Safe Prompt:
"Create a task to review the API design doc next week. Show me what you'll create first, then only create it if I type CONFIRM."
AI Behavior:
- Shows preview: "I'll create: Title: Review API design doc, Due: [next week], Project: [suggested]"
- Waits for "CONFIRM"
- Only calls
create_taskafter confirmation - Adds audit comment: "MCP: Created via user request"
update_task Example
Safe Prompt:
"Update the dashboard task status to in progress. First show me the current task, then show what will change, then wait for CONFIRM."
AI Behavior:
- Calls
get_taskto read current state - Shows: "Current: Status = Open, New: Status = In Progress"
- Waits for "CONFIRM"
- Only calls
update_taskafter confirmation - Adds audit comment: "MCP: Status updated to In Progress"
delete_task Example
Safe Prompt:
"Delete the duplicate 'Test login' task. Show me the task first, warn me it's permanent, then wait for DELETE CONFIRM."
AI Behavior:
- Calls
get_taskto show task details - Warns: "⚠️ This will permanently delete the task. This cannot be undone."
- Waits for "DELETE CONFIRM" (both words required)
- Only calls
delete_taskafter exact confirmation
Best Practices Summary
Safe Write Workflow Checklist
- ✅ Always read before writing (get_task before update_task)
- ✅ Require explicit confirmation (CONFIRM token)
- ✅ Show previews before executing (dry-run mode)
- ✅ Add audit comments explaining changes
- ✅ Use stronger confirmation for destructive operations (DELETE CONFIRM)
- ✅ Never batch write operations without showing the full list first
- ✅ Warn users about permanent actions (deletions)
- ✅ Provide clear instructions in your prompts
Additional Resources
MCP Security Guide
Complete security best practices for MCP
Preventing Accidental Writes
More safety patterns and troubleshooting
API Key Management
Secure API key practices
Task Management MCP
Safe task management workflows
Design Safe MCP Workflows
Use these patterns to reduce risk and prevent accidental changes
Aucune carte bancaire requise